sks-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] problems with SKS 1.0.10 when searching by key ID from GnuPG

From: Daniel Kahn Gillmor
Subject: [Sks-devel] problems with SKS 1.0.10 when searching by key ID from GnuPG
Date: Fri, 20 Mar 2009 18:08:39 -0400
User-agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) 
Hi folks--


I'm getting gpg failures when searching by keyid.  For this example,
i'll just use my own key id:

 gpg --keyserver $foo --search D21739E9

for keyservers using HKP, gpg generates an HTTP request like this:

http://$foo:11371/pks/lookup?op=index&options=mr&search=0xD21739E9&exact=on

Upsettingly, gpg sometimes indicates success, and sometimes failure with
this exact same command, even if the keyserver name is the same, because
the DNS round-robins over keyservers running different versions of sks.

fwict, SKS 1.0.10 fails in response to this request, but 1.1.0 succeeds.
 All of the keyservers succeed in finding my key if i search by name.

What i've found is that keyservers reporting header Server:
sks_www/1.0.10 produce the following response:

> HTTP/1.0 500 OK
> Server: sks_www/1.0.10
> Content-type: text/html; charset=UTF-8
>
> <html><head><title>Error handling request</title></head>\r\n<body><h1>Error 
> handling request</h1>Error handling request: No keys found</body></html>


while keyservers running SKS 1.1.0 produce the expected response (HTTP
return code 200, Content-Type text/plain, body consisting of a summary
of my key information).

Here is a list of keyservers (pulled from my DNS's current responses for
keys.gnupg.net and pool.sks-keyservers.net) that are failing the above
request (and all running sks 1.0.10, fwict):

194.171.167.147 minsky.surfnet.nl.
129.128.98.22 pgp.srv.ualberta.ca.
193.174.13.74 pgpkeys.pca.dfn.de.
62.48.35.100 lorien.prato.linux.it.
202.191.99.51 keyserver.oeg.com.au.
213.239.212.133 minbari.maluska.de.
130.206.1.8 gozer.rediris.es.

If you control a keyserver running SKS 1.0.10 or earlier, could you try
searching by key ID against your keyserver?  If you are able to upgrade
it and try again, does that resolve the issue?

I don't know if people think this is serious enough to warrant changing
membership in the pool, but at some point, a bug will be found that
suggests that older versions should be rejected from the pool.  Should
the various keyserver pools have a mechanism to reject membership based
on version?  Or feature-based membership tests?  What is the right way
to handle this?

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to
[Prev in Thread] Current Thread [Next in Thread]