Re: Non-US

[Roland McGrath <roland@frob.com>]

> gpg: Please note that you don't have secure memory on this system
> 
> Doesn't the Hurd have mlock() ?

Nope.  In fact, libc doesn't even have stub functions for it!  D'oh!  (If
there had been stub functions in libc as there should be, instead of only
the linux syscalls, then I would have noticed long ago these were missing.)
But there's no reason we can't add it.  In fact, I'll do it now.  I think
Mach might have some bugs with wiring, so using it might turn out to be flaky.
You can find out.

> gpg: WARNING: program may create a core file!
> 
> setrlimit(RLIMIT_CORE, 0) doesn't seem to work. How is coring
> prevented on the Hurd?

To be more precise, setrlimit(RLIMIT_CORE, 0) does work (it stores the
value), but resource limits are not inherited across exec as they should
be, and furthermore the core dumping code doesn't actually check the limit
(but changing it to check for the case of 0 specially is easy enough).
However, dumping cores on the Hurd is preventing shockingly well by the
lack of an implementation of the code to actually write core files. :-)

> gpg: keyblock resource `/home/robbe/.gnupg': file open error
> gpg: keyblock resource `/home/robbe/.gnupg': file open error

You got me.  You're going to have to investigate further.  The first step
will be to find the person who made gpg write "file open error" without
telling you what the error was (errno code, i.e. use perror), and give them
a boot to the head.