Description of problem: I tried to download the public key for Ken Coar, and got a very confusing error message. I then logged in as a different user, and tried again, and it succeeded. The import filter is over-active, and appears to be refusing to import a key solely because an 8-digit identifier associated with the key happens to have a substring that matches the username associated with my own personal key. Version-Release number of selected component (if applicable): gnupg-1.4.18-1.fc20.x86_64 How reproducible: 100% for me, but not for all users Steps to Reproduce: 1. Create a personal gpg key associated with a short all-hex username. In my case, although my $USER of eblake is non-hex, my key happens to be associated with a secondary email address ebb9: gpg --fingerprint eblake 2. Try to download another public subkey where the associated master key has the same all-hex substring: gpg --recv-keys f46d6ac2 3. Try to inspect the key: gpg --fingerprint 0xf46d6ac2 4. As a work-around, import the subkey directly: gpg --fingerprint 0xf46d6ac2 5. Now try to inspect it: gpg --fingerprint 0xf46d6ac2 6. Log on as a different user: su -l dummy; echo $USER 7. Try again to download: gpg --recv-keys f46d6ac2 Actual results: 1. $ gpg --fingerprint eblake pub 2048R/2527436A 2010-04-16 Key fingerprint = 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A uid Eric Blake <eblake> uid Eric Blake (Free Software Programmer) <ebb9> uid [jpeg image of size 6874] sub 2048R/D2E4726C 2010-04-16 2. $ gpg --recv-keys f46d6ac2 gpg: requesting key F46D6AC2 from hkp server keys.gnupg.net gpg: key 4EBB96FF: rejected by import filter gpg: Total number processed: 1 3. $ gpg --fingerprint 0xf46d6ac2 gpg: error reading key: public key not found 4. $ gpg --recv-keys 4ebb96ff gpg: requesting key 4EBB96FF from hkp server keys.gnupg.net gpg: key 4EBB96FF: public key "Ken Coar (Open sourcerer) <coar>" imported gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 1 signed: 6 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 6 signed: 46 trust: 0-, 4q, 0n, 0m, 2f, 0u gpg: depth: 2 valid: 41 signed: 29 trust: 1-, 1q, 0n, 28m, 11f, 0u gpg: depth: 3 valid: 10 signed: 21 trust: 0-, 6q, 0n, 1m, 3f, 0u gpg: depth: 4 valid: 4 signed: 9 trust: 2-, 1q, 0n, 0m, 1f, 0u gpg: next trustdb check due at 2015-01-29 gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) 5. $ gpg --fingerprint 0xf46d6ac2 pub 4096R/4EBB96FF 1997-01-24 Key fingerprint = 4333 9E61 30A2 CA74 206F 8653 5ADF 9B5C 4EBB 96FF uid Ken Coar (Open sourcerer) <coar> uid Ken Coar (Open sourcerer, PHP hacker) <coar> uid Ken Coar (Open sourcerer, opinionist) <Ken> uid Ken Coar (Open sourcerer, Perl hacker) <ROUS> uid Ken Coar (Open methodology evangelist) <coar> uid Ken Coar (Opinionist [eddress retired]) <Ken.Coar> uid Ken Coar/Rodent of Unusual Size (Born 1960-04, Florida, USA) uid Ken Coar (Opinionist [eddress retired]) <Ken.Coar> uid Ken Coar (Open sourcerer, systems rationaliser) <coar> uid Ken Coar (Open sourcerer, systems rationaliser) <kcoar> uid Ken Coar (Open sourcerer, systems rationaliser) <genghisken> uid Ken Coar (Open sourcerer, opinionist, fallback eddress) <Ken.Coar> sub 2048R/5D5F76E9 1997-01-24 sub 1024D/31F752F3 2014-07-22 [expires: 2016-07-21] sub 4096R/F46D6AC2 2014-07-22 [expires: 2016-07-21] 6. echo $USER dummy 7. $ gpg --recv-keys f46d6ac2 gpg: requesting key F46D6AC2 from hkp server keys.gnupg.net gpg: key 4EBB96FF: public key "Ken Coar (Open sourcerer) <coar>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Expected results: At step 2, the input filter should not have prevented me from getting the key. I should not have had to resort to either step 4 (change my download request) or 7 (log on as a different user) Additional info:
Please file a bug with the upstream bug tracker at https://bugs.g10code.com/gnupg/index
done: https://bugs.g10code.com/gnupg/issue1680
Just a ping here - Looks like this is fixed upstream. Thanks!
If I'm reading upstream correctly, the fact that my username matched a hex substring was pure coincidence; the real issue is that ANY subkey request would fail, and the bug is that only primary keys can be downloaded. I'm retitling the bug accordingly.
I've backported the 2 patches from upstream needed to fix this.
gnupg-1.4.18-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnupg-1.4.18-4.fc21
gnupg-1.4.18-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/gnupg-1.4.18-4.fc20
Package gnupg-1.4.18-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnupg-1.4.18-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13250/gnupg-1.4.18-4.fc20 then log in and leave karma (feedback).
gnupg-1.4.18-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
gnupg-1.4.18-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.