tags 659905 + upstream thanks Hi there!
On Wed, 15 Feb 2012 05:14:48 +0100, David Shaw wrote: > On Feb 14, 2012, at 12:37 PM, Luca Capello wrote: >> 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. So this is a (IMHO worse) variant of Asheesh's (Cc:ed) post entitled "Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)": <http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html> I find strange that when I ask for a key what is returned is actually a *master* key as well as all the possible *subkeys*. This obviously means that the possibility of a collision is bigger. > 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. Thank you for the explanation, but how gpg knows about the long key ID if I specify a short one? I do not see any difference WRT key IDs handling, except if, as I wrote above, gpg and the keyserver will return only *master* keys and not *subkeys* as well. Please note that this is the reason I have not closed this bug: feel free to do it if my reasoning above is flawed. Thx, bye, Gismo / Luca
pgpNdlrpRW2UM.pgp
Description: PGP signature
