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.

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-----

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.

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.

Done.

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

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".