GPG2 Memory fault(coredump)

[John Talaga]

Hello all,

I have installed http://hpux.connect.org.uk/hppd/hpux/Users/gnupg-2.0.15/ along with the many dependencies (both build-time and run-time). The swinstall of gpg worked without issue.

Running the command gpg --list-keys for the first time, it creates the default files (keyring, config, trustdb) without problem.

The problem lies when I attempt to create a new key. Output follows:

$ gpg2 --gen-key
gpg (GnuPG) 2.0.15; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Warning: using insecure memory!
gpg: keyring `/test/gnupg/.gnupg/secring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: test
Name must be at least 5 characters long
Real name: testing
Email address: test@test.test
Comment: this is a test
You selected this USER-ID:
"testing (this is a test) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.


gpg: signal 11 caught ... exiting
Memory fault(coredump)



I am not sure what I can do to capture the coredump. Or what might be causing it to dump in the first place.

Is the "using insecure memory" warning related to the dump?

Any help is greatly appreciated.

Thank you for your continued assistance on these forums.

--John

[Steven Schweda]

> I am not sure what I can do to capture the
> coredump.

Don't you get a (big) "core" file? That'd be
the dump. It's normally analyzed using some
debugger or other, possibly depending on
which compiler was used to build the stuff.
Getting a traceback to see where the thing
exploded would be my first step in the debug
procedure.

I'm still back at GnuPG 1.4.x, I don't use it
much, and, when I do, it's typically on a VMS
system, so I know nothing, but, ...

> I have installed [...]

One advantage of building all this stuff from
the sources is some confidence that all the
pieces were built using the same tools. (And
one (big) advantage of GnuPG 1.x is its
smaller set of dependencies.) Perhaps
everything should work with any old
assortment of packages built anywhere anyhow,
but I feel better when it's all under my
control.

> Is the "using insecure memory" warning
> related to the dump?

I'd tend to doubt it, but did you read the
FAQ?

http://www.gnupg.org/faq.html#q6.1

[John Talaga]

Well that is the weird thing, I don't find a core file anywhere.

As for the "insecure memory" warning, I had read through the documentation and came to the conclusion that it wasn't a very big concern, but to promote troubleshooting, I changed perms on the gpg executable to 4755. That eliminated the memory warning, but did not change that the process core dumps, right at the point where prompts for a passphrase.


Any thoughts on the missing core file?

Thanks all for your continued assistance.

--John

[Steven Schweda]

> [...] right at the point where prompts for
> a passphrase.

That does suggest a problem with the no-echo
passphrase-reading code.

> Any thoughts on the missing core file?

ulimit?

[John Talaga]

Update on the missing core file.

ulimit -c was set to 4194303, which I thought was plenty large enough. However, I went ahead and set ulimit -c to unlimited, and still I am unable to find a core file from this crash.

Are there any thoughts as to why this core file is not being created?

Thanks again,

--John

[Steven Schweda]

> Are there any thoughts as to why this core
> file is not being created?

You mean _correct_ thoughts this time?

In 1.4.x, there seems to be some code to
inhibit "core" generation. Probably a
security thing.

g10/gpg.c:
[...]
may_coredump = disable_core_dumps();
[...]

g10/misc.c:
[...]
int
disable_core_dumps()
{
[...]

Other than editing the source, I don't see a
clean and handy way to bypass this. (Editing
config.h to avoid defining HAVE_SETRLIMIT
would seem to do it in 1.4.10, but no bets
for 2.x.)

Well, setrlimit() was tenuously related to
ulimit.

[Dennis Handly]

>Any thoughts on the missing core file?

You could use tusc to see what happens after the signal.
If you are on 11.31, coreadm(1m) can be used to send it elsewhere.

[Steven Schweda]

> You could use tusc to see what happens
> after the signal.

Use the source, Luke. In 1.4.10:
[...]
int
disable_core_dumps()
{
#if defined( HAVE_DOSISH_SYSTEM) || defined( __VMS)
return 0;
#else
#ifdef HAVE_SETRLIMIT
struct rlimit limit;

limit.rlim_cur = 0;
limit.rlim_max = 0;
if( !setrlimit( RLIMIT_CORE, &limit ) )
return 0;
if( errno != EINVAL && errno != ENOSYS )
log_fatal(_("can't disable core dumps: %s\n"), strerror(errno) );
#endif
return 1;
#endif
}
[...]

Can coreadm(1m) overcome that code?

Another argument for building stuff like this
from the sources is the ability to fiddle
with stuff like this.

Sadly, my quick attempt to build some of the
prerequisite libraries on my 11.31 IA64
system using GCC 4.3.3 ran into more problems
than I expected. There's much to be said for
sticking with the (simpler) 1.x family,
especially if it does all you need done.

[Dennis Handly]

>Steven: Use the source, Luke. In 1.4.10:

And tusc would show that call. :-)

It sure is strange that wait(2) claims there is a corefile. I suppose it is too much to expect that it check the setrlimit value for exactly 0 and then not say "(coredump)".

[John Talaga]

Hello all,

An update. I found a 1.4.9 depot that works without issue.

I might have some missing run-time dependency or something with the 2.0.15 version, but the good news is 1.4.9 is working fine.

Thanks for all of your suggestions.

--John