hkp query fails on some keyservers
Closed, ResolvedPublic

Description

Release: gpg (GnuPG) 1.4.3

Environment

win2k

Description

For a PGP Corp keyserver <server>,
gpg --search-keys --keyserver hkp://<server> <target> fails with "gpg: searching for "<target>" from hkp server <server>
gpg: key "<target>" not found on keyserver

using ldap://<server> succeeds
using 1.4.2 succeeds
using other keyserver (e.g. pgp.mit.edu) succeeds

Sniffer trace shows that hkp call is correctly built and a valid response with results is provided.

How To Repeat

Trace shows three commands:
gpg -v --search-keys --keyserver ldap://pgp.cisco.com "woody weaver" [succeeds]
gpg -v --search-keys --keyserver hkp://pgp.cisco.com "woody weaver" [fails]
gpg -v --search-keys --keyserver hkp://pgp.mit.edu "woody weaver" [succeeds]

Fix

Unknown

weaver added a subscriber: weaver.May 8 2006, 10:52 PM

dshaw added a subscriber: dshaw.May 8 2006, 11:16 PM

This is not a bug. We do not support that keyserver over
HKP, only LDAP. It is true we used to in 1.4.2 (and in fact
you can reenable such support in 1.4.3 by building with
--enable-old-keyserver-helpers), but this required GPG to
parse the HTML response which varied slightly between
different keyservers. As new keyserver types came online,
we had to detect their own flavor of that HTML and adapt to
it - utterly unscalable. Newer keyservers either use LDAP
or (like pgp.mit.edu) use a consistent machine-readable output.

Note that --enable-old-keyserver-helpers will not be
available in 1.4.4 or later.

dshaw added a comment.May 8 2006, 11:16 PM

From: "Woody Weaver -X \(wooweave - Links Technology at Cisco\)" <wooweave@cisco.com>
To: <bug-any@bugs.gnupg.org>, <gnupg-hackers@gnupg.org>,

<gnats-admin@trithemius.gnupg.org>

Cc:
Subject: RE: gnupg/651
Date: Mon, 8 May 2006 15:32:48 -0400

20

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dshaw@jabberwocky.com wrote:

Synopsis: hkp query fails on some keyservers

20

State-Changed-From-To: open->chatting
State-Changed-By: dshaw
State-Changed-When: Mon, 08 May 2006 21:16:53 +0200
State-Changed-Why:
This is not a bug. We do not support that keyserver over HKP, only
LDAP. It is true we used to in 1.4.2 (and in fact you can reenable
such support in 1.4.3 by building with
--enable-old-keyserver-helpers), but this required GPG to parse the
HTML response which varied slightly between different keyservers.=20
As new keyserver types came online, we had to detect their own
flavor of that HTML and adapt to it - utterly unscalable. Newer
keyservers
either use LDAP or (like pgp.mit.edu) use a consistent
machine-readable output. =20

Thanks for the rapid response. Indeed ldap:// is a (better)
solution.

However, I think there is perhaps a bug here. The response was 'key
not found'. A better response would be something along the lines of
'the keyserver didn't honor the mr option, and we were not able to
parse the response' (in three words, of course). The response 'key
not found' is not truthful, and may lead a user to believe that the
correspondent has no keys when the real situation is that the
keyserver is not compliant.

Other than that, I think your response was very complete and helpful,
and the ticket can be closed.

Note that --enable-old-keyserver-helpers will not be available in
1.4.4 or later.=20

20

20

20

  • Comment added by dshaw on Mon, 08 May 2006 21:16:53 +0200 ****

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBRF+c4B8dhVP8r+ydEQLHqACgh8utCL8A92K1YA4rNIkMfumKNJsAoJYr
deSLfuuTPJNNTq5jBUtrXof0

3D+An/

-----END PGP SIGNATURE-----

werner added a subscriber: werner.Oct 19 2006, 5:53 PM

David, what about issuing one special record in curl_mrindex_writer if we
swallow a HTML response? This would allow gpg to print a better error message.

dshaw added a comment.Oct 20 2006, 5:33 AM

The HTML response is only from the old pks keyservers, and there aren't any of
them left (the old keyservers were the ones that destroyed subkeys). Still,
I'll add something like this just to be sure.

dshaw closed this task as Resolved.Oct 20 2006, 5:40 AM
dshaw added a comment.Nov 6 2006, 4:17 AM

I'm going to have to revert this and reopen the bug for discussion. Even the
SKS servers return HTML for a genuine key-not-found response. It is
inappropriate for gpg to complain in that case

dshaw reopened this task as Open.Nov 6 2006, 4:17 AM
dshaw added a comment.Dec 3 2006, 4:16 AM

I'm going to close this now. GPG is doing as well as it can given the vagaries
of what HKP servers return. Unfortunately, there is no readily parsable
difference between "server failure", "key not found", or even "this isn't a
keyserver at all".

dshaw closed this task as Resolved.Dec 3 2006, 4:16 AM