Description of problem: When GPG is first run it can't create keyring Version-Release number of selected component (if applicable): gnupg-1.2.6-1 How reproducible: Run gpg as a user without a ~/.gnupg directory Steps to Reproduce: 1. Remove ~/.gnupg directory 2. Run gpg to create keyring Actual results: Unable to create keyring Expected results: Creation of ~/.gnupg directory and keyring Additional info: Example of failure gpg: failed to create temporary file `/home/dragoon/.gnupg/.#lk0xf70059a8.rydia.hardsun.net.4339': No such file or directory gpg: keyblock resource `/home/dragoon/.gnupg/secring.gpg': general error gpg: failed to create temporary file `/home/dragoon/.gnupg/.#lk0xf7005cb8.rydia.hardsun.net.4339': No such file or directory gpg: keyblock resource `/home/dragoon/.gnupg/pubring.gpg': general error gpg: Go ahead and type your message ... Once .gnupg directory is created GPG creates keyring without problem.
Created attachment 106864 [details] Fix for homedir creation problem Here is a patch, which will be part of GnuPG 1.2.7 (and 1.4) to resolve this problem.
Note that 1.2.7 has been released which resolves this bug, as well as bug #138266 and bug #142206
As of 23rd Jan 2005 this is still an issue with a fully updated Fedora Core 3 system. The version of GPG is [ush@ars ~]$ rpm -q gnupg gnupg-1.2.6-1 [us@ars ~] yum search gnupg gnupg.i386 1.2.6-1 base Matched from: gnupg I assume that the correct thing for users to do is to: cd ~ mkdir .gnupg cp /usr/share/gnupg/options.skel .gnupg/gpg.conf chmod 700 .gnupg chmod 500 .gnupg/gpg.conf chown <user>.<user> .gnupg chown <user>.<user> .gnupg/gpg.conf It'd be nice to have some confirmation of this being the correct thing to do until version 1.2.7 is released as an update.
Thank you for the workaround, RHEL4 contain also 1.2.6: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150935
BTW, permissions are not proper in suggestion: -chmod 500 .gnupg/gpg.conf +chmod 600 .gnupg/gpg.conf
*** Bug 146167 has been marked as a duplicate of this bug. ***
Fedora Core 3 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 FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
At current version in FC5 is fixed.
marking fixed as per comment #8.