With the (admitted, alpha) ebuild for gnuppg 1.9.10 it's no longer possible to retrieve (or send) any keys via keyservers as the gpgkeys_* apps are missing. This is probably related to bug 27467 and bug 27608 except that this time it looks like the stuff is borked upstream, at least judging from the following posting to the gnupg-users mailinglist: http://lists.gnupg.org/pipermail/gnupg-users/2004-September/023236.html If there's really no code for the keyserver stuff in the tarball I guess this can't be fixed on side of Gentoo. But I guess its useful in combination with bug 37109 to know what is actually borked in 1.9.10. Reproducible: Always Steps to Reproduce: gpg --refresh-keys --keyserver hkp://pgpkeys.mit.edu Actual Results: Secure memory is not locked into core gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: refreshing 570 keys from hkp://pgpkeys.mit.edu gpg: unable to execute program "gpgkeys_hkp": No such file or directory gpg: no handler for keyserver scheme "hkp" gpg: keyserver refresh failed: Keyserver error Expected Results: A fresh keyring.
I noticed that a tarball for 1.9.11 is out and tried that one, but no success. But after quite some searching I finally found this quote by Werner Koch on the gnupg-devel list: | Ah right, the keyserver stuff. This has not yet been ported from 1.3 | to 1.9 - thus only the internal HKP code will work. | | GPA uses the external keyserver access modules directly so you need to | install them from 1.3. The default location is | /usr/local/lib/gnupg/. http://marc.theaimsgroup.com/?l=gnupg-devel&m=107331528004726&w=2
ok - closing this while upstream gets its coding mind into gear.
*** Bug 65483 has been marked as a duplicate of this bug. ***
