On Feb 14, 2012, at 12:37 PM, Luca Capello wrote: > Package: gnupg > Version: 1.4.11-3 > Severity: normal > File: /usr/bin/gpg > Usertags: pca.it-communication > > Hi there! > > I was importing some keys after the FOSDEM 2012 Keysigning Party and > here a strange result: > ===== > $ gpg --recv-keys 171CAA4A 613F3AE4
This is actually a (somewhat obscure) historical implementation detail of GPG and the keyserver software. The issue is the key ID 171CAA4A, which seemingly exists twice on the keyserver. First, there is a key 171CAA4A, as expected. Then there is also a key 1C8BB5A7 which has a subkey that happens to have the key ID 171CAA4A as well. These are not the same key, but just look that way. This is fine inside OpenPGP, as internally it uses the long key ID, but it can be confusing when people use the short key IDs. Of course, that key ID only matches as the short key IDs. If you look at long key IDs, they do not match. For historical reasons, until recently, both GPG and the keyserver software only used the short key IDs for this sort of search (even if you specified the long key ID). That's no longer true with GPG 1.4.12, and the upcoming SKS release. Once you upgrade to GPG 1.4.12 and are talking to an updated SKS server, you should be able to do something like: gpg --recv-keys BC2914B4171CAA4A And only get one answer. David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
