[Pkg-gnupg-maint] Bug#659905: gnupg: --recv-keys downloads the demanded keys plus another one

[Luca Capello]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20120215/11d0d101/attachment.pgp>