Description of problem: If Fedora is installed with Finnish language support and Gnome is used in Finnish this error occurs. If English is also installed then using English this error does not occur. Version-Release number of selected component (if applicable): 1.2.4? How reproducible: well Steps to Reproduce: 1.gpg --gen-keys 2.enter information until comment, then it crashes 3. Actual results: Expected results: Additional info:
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
I also experience gnupg crashes on FC4 (i386) when trying to add a key to my ring.
fc4 test-run: [root@epia .gnupg]# gpg --gen-key gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024 bits. ELG-E 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 <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh>" Real name: root Name must be at least 5 characters long Real name: root_ Email address: root Not a valid email address Email address: root@localhost Comment: root You selected this USER-ID: "root_ (root) <root@localhost>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++++++++++++..+++++.++++++++++.+++++.++++++++++.++++++++++.+++++.....+++++++++++++++.+++++.++++++++++.++++++++++.++++++++++++++++++++....++++++++++.+++++..............................+++++ Segmentation fault
I couldn't reproduce this in the default locale (en_US.UTF-8). Can you post your locale information (I also tried with nl_NL.UTF-8, but that also ran to completion)? I ask because this might be related to bug #149843, but it's apparently not the same bug because you're seeing the crash at a different point.
I think I've used fi_FI.UTF8-locale, since I am in Finland. No I quickly tried it again, first in english and then in Finnish, and now it seems to work. FC4 with all updates. Actually I might have used before some other than UTF-8, ie. ISO-8859-15 or something like that, don't know if that has any effect?
Did a spot-check with $LANG set to: fi_FI.UTF-8 fi_FI.ISO-8859-1 (the default for "fi_FI") fi_FI.ISO-8859-15 and I can't reproduce it, either. The encoding shouldn't have an effect because the gettext library converts strings from the encoding in which they're stored (which is recorded in the .mo file) to the one specified as part of the locale. I'm tempted to mark this one "can't fix" because I can't reproduce it.
Hi again, it seems that this bug is no longer appearing. But we tried this with two FC3-machines, and key-generation failed in the beginning, when the folder .gnupg is (supposed to) made. The fix is to manually create the foldel .gnupg, and then it works! Your "can't fix" seems to be good idea for this FC4 bug.
This is FC4. The folder is there. Debugging is not possible since gdb complains about the program not being tehre or whatever. The bug is still there: [root@epia ~]# ls -al .gnupg total 6 drwx------ 3 root root 1024 Sep 9 16:01 . drwxr-x--- 14 root root 4096 Sep 8 20:05 .. drwx------ 2 root root 1024 Jul 29 18:11 private-keys-v1.d [root@epia ~]# pwd /root [root@epia ~]# gpg --gen-key gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh>" Real name: root Name must be at least 5 characters long Real name: root! Email address: root@localhost Comment: root You selected this USER-ID: "root! (root) <root@localhost>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++.++++++++++++++++++++.++++++++++++++++++++.+++++.++++++++++++++++++++..++++++++++++++++++++.+++++++++++++++.+++++++++++++++++++++++++>+++++.+++++......+++++ Segmentation fault
Latest development gnupg, had to build it because it has a weird libwhatever dependency: [root@epia redhat]# rpm -Uvh /usr/src/redhat/RPMS/i386/gnupg-1.4.2-3.i386.rpm Preparing... ########################################### [100%] 1:gnupg ########################################### [100%] [root@epia redhat]# cd [root@epia ~]# gpg --gen-key gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh>" Real name: root! Email address: root@localhost Comment: root You selected this USER-ID: "root! (root) <root@localhost>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++.+++++++++++++++++++++++++++++++++++.+++++.+++++.++++++++++++++++++++++++++++++++++++++++.++++++++++++++++++++...+++++++++++++++++++++++++......>+++++.....................................+++++ Segmentation fault
(In reply to comment #7) > it seems that this bug is no longer appearing. But we tried this with two > FC3-machines, and key-generation failed in the beginning, when the folder .gnupg > is (supposed to) made. The fix is to manually create the foldel .gnupg, and then > it works! Your "can't fix" seems to be good idea for this FC4 bug. I (finally) pushed an update to the FC3 updates-testing repository which updates to 1.2.7, which should fix this. If you can, please install the package and follow up in bug #139209 if it for whatever reason still doesn't work. I'll probably move it to final updates early next week if I don't hear any reports of problems.
(In reply to comment #9) I'm still not able to reproduce this one, even on Raw Hide. Can you try these things to get more information: 1) Run gnupg under strace: strace -s256 -o gpg-strace.txt gpg --gen-key This may provide useful information about what exactly gnupg is attempting to do when it crashes, and hopefully I can compare that to the same output for a successful run and work from there. 2) a) Install the gpg-debuginfo package. b) Reset your shell session's process limits so that core dumps get saved ("ulimit -c unlimited" if you're using bash, "limit coredumpsize unlimited" if you're using tcsh) c) Run gpg again, get the core dump d) Run "gdb /usr/bin/gpg core" (for whatever filename the core dump gets), and give it the "bt" command to get a backtrace.
Created attachment 118638 [details] The requested strace, is from gnupg-1.4.2-3
No core dump is created when the other route is tried. (running 2.6.13)
This is pretty strange -- the segfault occurs while gpg is attempting to read random data from /dev/random, a step which doesn't encounter any errors on any system with which I've tried to reproduce this. Just so that we can rule it out, can you run memtest on the system to verify that there's nothing odd going in with memory on your system? The first CD of the FC install set should offer a "memtest" option which will do this. If that doesn't turn up anything, can you re-run gpg under valgrind like so: valgrind --tool=memcheck gpg --gen-key
Memory should be OK. The box runs for ages without problems (except the VIA Rhine driver and crond audit issues). My kernel has netdev-random patches so the network contributes to the entropy pool. Also audio-entropyd is running to help fill the pool. Do you know the amount of entropy left when the crash occurs? (or an easy way to find out) Maybe it is a concurrent access issue? (just an idea)
You're using a different kernel? The application is crashing reading from a device, so the kernel can't be ruled out as a possible distinguisher. Can you reproduce this using either the FC4 or Raw Hide kernels?
[root@epia random]# valgrind --tool=memcheck gpg --gen-key valgrind: padding mmap((nil), 134512640) failed during startup. valgrind: is there a hard virtual memory limit set? [root@epia random]# vi /etc/security/limits.conf [root@epia random]# ulimit -v 9999999999999999 [root@epia random]# valgrind --tool=memcheck gpg --gen-key ==21856== Memcheck, a memory error detector for x86-linux. ==21856== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==21856== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==21856== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==21856== For more details, rerun with: -v ==21856== gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh>" Real name: root! Email address: root@localhost Comment: root You selected this USER-ID: "root! (root) <root@localhost>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. .++++++++++.+++++...+++++.++++++++++.++++++++++++++++++++++++++++++++++++++++.+++++++++++++++++++++++++++++++++++++++++++++.+++++++++++++++>+++++.+++++>+++++...<+++++>..+++++...........................>+++++..................<+++++....+++++ Segmentation fault [root@epia random]# I.e.: no difference?
Currently I am testing for the VIA-Rhien bug (see http://bugzilla.kernel.org/show_bug.cgi?id=5030) but I could reboot into a FC4 kernel soon. (why is a vanilla kernel with slight patches not good enough?)
The kernel is different. The crash happens while the application is attempting to read from /dev/random, the write end of which is in the kernel. I'm trying to rule the difference in kernel versions out as a possible cause.
OK. I assume the latest FC4 kernel suffices? I will let you know the results. I could also try the memtest at that time because of teh reboot. Kernel compiles etc work OK, no sign of memory related issues there.
Created attachment 118756 [details] gpg 1.4.2-3 strace running Fedora Core (2.6.11-1.1369_FC4) single user
gpg complained about lack of entropy, need xx bytes. tapped spacebar randomly, crashed anyway. single user because of hurry.
I can't reproduce this bug on FC4 with all updates and the 1369 kernel, either. If memtest doesn't detect any problems, and there's no way to get a backtrace, I'm out of ideas.
Fedora Core 4 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.