Page MenuHome GnuPG
Create Task
Maniphest T4354

dirmngr should send "fingerprint=on" to keyservers
Closed, ResolvedPublic
Actions

Description

Currently
Some keyservers do not behave like others when it gets to listing keys with fingerprints.

dirmngr currently doesn't add "fingerprint=on", nor has it an options to set it manually for a request.

Expected
Most servers return a list including fingerprints, but some only respond with key-ids.

This can be reproduced using the following request:
/pks/lookup?op=vindex&options=mr&search=GPGTools%20Team

When "fingerprint=on" is added to the request, all tested keyservers return the fingerprints – which would be preferable.

Here are two keyservers to test, which are both part of the sks-keyservers.net pool:
"normal" behavior:        pgpkeys.uk (192.146.137.98)
sends key-id be default:  pgpkeys.hu (37.17.173.9)

Here is the required patch for dirmngr (patch by mento@gpgtools.org):

--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -1471,7 +1471,7 @@
 
     xfree (request);
     request = strconcat (hostport,
-                         "/pks/lookup?op=index&options=mr&search=",
+                         "/pks/lookup?op=index&options=mr&fingerprint=on&search=",
                          searchkey,
                          NULL);
     xfree (searchkey);

Thanks for considering adding this.

Details

Version
2.2.12

Event Timeline

steve created this task.Jan 30 2019, 11:07 AM
• werner edited projects, added Keyserver, dirmngr; removed Feature Request.Jan 30 2019, 3:22 PM
• werner added a subscriber: • werner.

According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

steve added a comment.Feb 1 2019, 10:32 AM

Hi Werner and thanks for looking into this.

We think one of them requires this option, because the behavior is different.

Please have a look at the following two request:

curl -D - -s 'pgpkeys.hu/pks/lookup?op=index&options=mr&search=NIIBE%20Yutaka'

HTTP/1.1 200 OK
Date: Thu, 31 Jan 2019 09:18:01 GMT
Content-Type: text/plain
Content-Length: 568
Connection: keep-alive
Via: 1.1 pgpkeys.hu:11371 (nginx)
X-Cache-Status: HIT
X-Handled-By: backend

info:1:8
pub:2071B08A33BD3F06:1:2048:1414544163::
uid:NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>:1477383257:1666884751:
pub:E3F25854128F0E79:17:1024:941616864::
pub:744D73FD71D5F43A:0:0:-62135596800::
pub:041E39AF71D5F43A:17:1024:1071456136::
uid:NIIBE Yutaka <gniibe@fsij.org>:1156834189:1229136136:
pub:E267B052364F028D:0:0:-62135596800::
pub:CD3700A54CA7BABE:0:0:-62135596800::
pub:00B45EBD4CA7BABE:1:2048:1287125193::
uid:NIIBE Yutaka <gniibe@fsij.org>:1290131210::
uid:NIIBE Yutaka <gniibe@debian.org>:1290130668::
pub:38B193094A994FE1:1:1024:783583692::

curl -D - -s 'pgpkeys.uk/pks/lookup?op=index&options=mr&search=NIIBE%20Yutaka'

HTTP/1.1 200 OK
Date: Thu, 31 Jan 2019 09:18:06 GMT
Content-Type: text/plain
Content-Length: 1074
Connection: keep-alive
Server: sks_www/1.1.6
X-HKP-Results-Count: 8
Access-Control-Allow-Origin: *
X-Cache-Status: HIT
Via: 1.1 pgpkeys.uk (nginx)

info:1:8
pub:249CB3771750745D5CDD323CE267B052364F028D:22:256:1439363448::
uid:NIIBE Yutaka <gniibe@fsij.org>:1439468758::
uid:NIIBE Yutaka <gniibe@debian.org>:1439468758::
pub:031EC2536E580D8EA286A9F22071B08A33BD3F06:1:2048:1414544163:1604045657:
uid:NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>:1477383257::
pub:E29732249E4A3FD9C125B62CCD3700A54CA7BABE:1:2048:1402901241::r
uid:NIIBE Yutaka <gniibe@fsij.org>:1407203759::
pub:272A7116B0F8684D569E2738744D73FD71D5F43A:1:1024:1402884831::r
uid:NIIBE Yutaka <gniibe@fsij.org>:1407200603::
pub:124124BD3B4862AF7A0A42F100B45EBD4CA7BABE:1:2048:1287125193::
uid:NIIBE Yutaka <gniibe@fsij.org>:1290131210::
uid:NIIBE Yutaka <gniibe@debian.org>:1290130668::
pub:75479757262628A19D753E98041E39AF71D5F43A:17:1024:1071456136:1229136136:
uid:NIIBE Yutaka <gniibe@fsij.org>:1156834189::
pub:B04F2AAD1AC5D6A93BD34771E3F25854128F0E79:17:1024:941616864:1004688864:
uid:Niibe Yutaka (GNU/Linux on SuperH Project) <gniibe@chroot.org>:941616864::
pub:38B193094A994FE1:1:1024:783583692::
uid:NIIBE Yutaka <gniibe@mri.co.jp>:783584132::
• werner added a subscriber: kristianf.Feb 4 2019, 5:45 PM

@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?

kristianf closed this task as Resolved.Feb 9 2019, 8:43 PM
kristianf claimed this task.

So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.

In any case, marking this resolved