Short ID Collision

John Clizbe John at enigmail.net
Fri Jan 6 00:21:08 CET 2012


Dan McGee wrote:
> On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe <John at enigmail.net> wrote:
>> Jerry wrote:
>>>
>>> It would seem, and this is strictly my own opinion, that if the "old
>>> pksd" servers are dead then there is no logical reason to continue to
>>> support them. Just my 2¢.
>>
>> If only all software support decisions were that cut and dried. Oh well...
>>
>> David Shaw committed patches to the 1.4, 2.0, & 2.1 branches of GnuPG yesterday
>> afternoon (28-Dec). The change will be in the next release of each branch.
> 
> Just discovered keyservers are still totally crappy on this front.
> Check this out when using a subkey ID to try to fetch a key; the
> following is a request produced by GPGME gpgme_get_key() that returns
> no matches (note that this is a subkey ID):

I guess you don't know the degree that SKS from its outset stripped much of the
"crappy" from PKSD. The few flecks of fecal implementation were needed at the
time for interoperability -- a nasty practicality of which software writers on
the Internet have to be mindful.

As for being still totally crappy, the problem only came up in discussion about
a week ago. Do you expect us to pull a fix out of our behinds and have it
magically applied to all existing keyservers in a week? BTW, it's being
discussed on the GnuPG-* lists. NO ONE has opened an issue on SKS

>
<snip>
> 
> This is totally unacceptable in my opinion, why do we have such broken
> infrastructure that it cannot support a simple lookup like this?

I'm sorry, did you mean to attach a patch fixing this to this message?

Supply a patch, help test it, and shepherd it into a release, or you're just
being part of the problem, IMO.

Patches for SKS are accepted at sks-devel at nongnu.org. (subscribe first)

SKS source is available from:

    hg clone https://code.google.com/p/sks-keyserver/

(sub)Keys are indexed on short key ID. This was for historical compatibility
with PKSD, as this was the lookup mechanism in place at the time. The patch
allowing longer lookup IDs has _just_ been applied to Gnupg's git repository --
it's NOT even in the wild yet and you're screaming about SKS not making the
change yet.

For most of us, this work we do is an unpaid second job, pay us for support and
you can adopt your tone of it it being "Unacceptable IMO". Until then,
contribute or, IMNSHO, plug it.

You may wish to glance at http://sks-keyservers.net/status/.  The frst release
that could have this change in it would be 1.1.3. After almost four months, 14
(actually 12 -- two of those are my public facing development machines out of
five) out of almost 80 have converted. You may expect to see similar slow
adoption rates with this fix (and other things in 1.1.3).


-- 
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

                   Cowboy Haiku -- Reflections on Rodeo
So many Cowboys. / Round Wrangler butts drive me nuts. / Never enough rope.



More information about the Gnupg-users mailing list