Mailing List Archive: Problems Running under GNU/Hurd

Greetings!

I'm one of the Debian developers working on a complete OS distribution based
on the GNU Hurd. As you may know, Debian is in the process of switching
from using PGP for developer authentiction for our package uploades to GPG.
Consequently, this is a critical part of our system, and is one of the first
things we need to port to the Hurd so we can work natively in that
environment (rather than cross-compiling as we are doing now).

GPG compiles cleanly under the Hurd, and works perfectly in decryption mode.

Unfortunately, it hangs when encrypting/signing. The program opens the
"output" file (you can see the empty file in the file system) and then gets
stuck waiting indefinitely.

I have tracked the problem down to the "rndunix.c" module, and am looking
for additional information on this code. Does anyone have a reference on
the original author, how it is supposed to work, etc.?

I suspect the problem is either:
(1) Pipes under the Hurd may either be slightly broken, or may have
different behavior than under Linux/BSD.
(2) The rndunix module believes that a device is present for gathering
random bits, but this device is possibly only implemented as a stub in the
hurd for now and so the "gather_rnd" routine just waits indefinitely for a
response.

Any help would be appreciated.

Thanks,

-Brent

> -----Original Message-----
> From: Werner Koch [mailto:wk@isil.d.shuttle.de]
> Sent: Monday, February 22, 1999 11:45 AM
> To: G10/GnuPG Mailing List
> Subject: Re: 0.9.3: import (secret key) and delete-key problem
>
>
> Rich Wales <richw@webcom.com> writes:
>
> > gpg:[stdin]: key A6A59DB9: secret key not found: public
> key not found
>
> Silly bug:
>
> In g10/getkey.c lookup_sk():
>
> s/G10ERR_NO_PUBKEY/G10ERR_NO_SECKEY/
>
>
> --
> ceterum censeo RSA esse delendam
>

Brent Fulgham <bfulgham@xpsystems.com> writes:

> GPG compiles cleanly under the Hurd, and works perfectly in decryption mode.
>
> Unfortunately, it hangs when encrypting/signing. The program opens the
> "output" file (you can see the empty file in the file system) and then gets
> stuck waiting indefinitely.

I have not booted my Hurd system for some month now so I'm glad to
hear that it still compiles fine.

> I have tracked the problem down to the "rndunix.c" module, and am looking
> for additional information on this code. Does anyone have a reference on
> the original author, how it is supposed to work, etc.?

Yesterday I wrote a driver for the new EGD and that should be usable
for Hurd too - however I think it would be *much* easier to add
support for /dev/?random to the Hurd (I posted such a request a long
time agon on help-hurd. But I've heard nothing about any progress.

linux/drivers/char/random.c should be usable for Hurd - the only
problem is to identify parts where to add the hooks for gathering
random from Mach.

> (2) The rndunix module believes that a device is present for gathering
> random bits, but this device is possibly only implemented as a stub in the
> hurd for now and so the "gather_rnd" routine just waits indefinitely for a

I don't understand this. Did you try to run ./configure
--disable-dev-random? The next release will have better configuration
for the random gatherer (I think I can commit this to CVS today).

Werner

--
ceterum censeo RSA esse delendam