Kleopatra only returns one key from keyserver

Gpg4win help-en
1

We have an offline network (no internet connection) in use where we have been using gpg4win on Windows 10 for a couple of years together with an SKS keyserver (quite a few years old, running on an old Debian) to administer the keys. Up until now, this has been working fine (which is the reason why I never posted before… :wink: ) - first, using the older GPGshell, more recently using Kleopatra.

However, when trying the latest version (gpg4win 4.0.0), Kleopatra no longer returns a full list of keys when doing “Lookup on server” - even when using a search term that is known to match multiple keys only one key is found. Also, the key is shown without e-mail address in the search results (but is complete after importing).

I’ve already tried the search using “gpg --search-keys STRING” from the command line on the same server, and gpg just returns the full list of keys with no errors. Also, if I set the debug-level to “all” in Kleopatra → GnuPG System → Network, I can see in the log that indeed all keys are returned from the server:

dirmngr[4292]: handler for fd 184 started
dirmngr[4292]: DBG: chan_0x000000b8 → # Home: C:\Users\USER\AppData\Roaming\gnupg
dirmngr[4292]: DBG: chan_0x0000042c ← OPTION audit-events=1
dirmngr[4292]: DBG: chan_0x0000042c → OK
dirmngr[4292]: DBG: chan_0x000000b8 → # Config: C:/Users/USER/AppData/Roaming/gnupg/dirmngr.conf
dirmngr[4292]: DBG: chan_0x000000b8 → OK Dirmngr 2.3.4 at your service
dirmngr[4292]: DBG: chan_0x0000042c ← LOOKUP SEARCHTERM
dirmngr[4292]: DBG: chan_0x0000042c → OK
dirmngr[4292]: DBG: chan_0x000000b8 ← GETINFO version
dirmngr[4292]: DBG: chan_0x000000b8 → D 2.3.4
dirmngr[4292]: DBG: chan_0x000000b8 → OK
dirmngr[4292]: DBG: chan_0x000000b8 ← KS_SEARCH – SEARCHTERM
dirmngr[4292]: detected interfaces: IPv4
dirmngr[4292]: DBG: chan_0x0000042c ← [eof]
dirmngr[4292]: handler for fd 1068 terminated
dirmngr[4292]: DBG: chan_0x000000b8 → S PROGRESS tick ? 0 0
dirmngr[4292]: DBG: chan_0x000000b8 → S SOURCE http://keyserver.localdomain.lan:11371
dirmngr[4292]: DBG: chan_0x000000b8 → D info:1:105%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D pub:XXXXXXXX:1:2048:1636970176::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D uid: NAME_1 NAME_1@SEARCHTERM.domain:1636970176::%0A
[…multiple entries…]
dirmngr[4292]: DBG: chan_0x000000b8 → D pub:XXXXXXXX:1:2048:1253005876::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D uid:NAME_N NAME_N@SEARCHTERM.domain:12530058
dirmngr[4292]: DBG: chan_0x000000b8 → D 76::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D pub:XXXXXXXX:1:2048:1251733444::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D uid:NAME_N+1 NAME_N+1@SEARCHTERM.domain:1251733444::%0A
[…multiple entries…]
dirmngr[4292]: DBG: chan_0x000000b8 → D pub:XXXXXXXX:17:1024:991030484::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D uid:NAME_N+M NAME_N+M@SEARCHTERM.domain:1196329149::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D uid:NAME_N+M NAME_N+M@OTHER.DOMAIN:1196329149::%0A
dirmngr[4292]: DBG: chan_0x000000b8 → D %0D%0A
dirmngr[4292]: DBG: chan_0x000000b8 → OK
dirmngr[4292]: DBG: chan_0x000000b8 ← BYE
dirmngr[4292]: DBG: chan_0x000000b8 → OK closing connection
dirmngr[4292]: handler for fd 184 terminated

To me, it looks almost as if Kleopatra fails to parse the data correctly. Also, I was not able to determine which entry Kleopatra actually returns - it’s always the same one for any given SEARCHTERM, but I can see no features that distinguishes that particular entry from the rest in the list.

I already tried searching, but so far, I haven’t seen any description of a similar problem anywhere, so I came here. Any hints on how to debug - or even solve - this would be highly appreciated!

2

Hi T,

can you confirm that it still works as expected with Gpg4win 3.1.16?
This would give us a hint about the differences.

Note that SKS servers are not that common recently, most public keyservers run Hockeypuck these days. So it could be a pecularity with SKS servers.

If you could find a reproducable case with one of the remain sks keyservers,
(see https://social.tchncs.de/@ber/107008659842900171)
where the command line does show something different than Kleopatra
it would be good for the developers to reproduce the problem more easily.

(You did search dev.gnupg.org for problem reports?)

Regards
Bernhard

3

Hi Bernhard,

thanks for the quick response! Yes, I can confirm that 3.1.16 was working fine (we had some internal DNS issues, but that had nothing to do with either Kleopatra or gpg in the end). And thanks for the hint with Hockeypuck, as we are looking into updating the server as well… :wink:

I will see whether I can find the time to fetch a Windows 10-machine with internet connection that I can install gpg4win on to try.

As for searching: I spent the better part of an hour trying various internet searches and I did encounter several issues from dev.gnupg.org, but none that matched so far. Might give it another, more specific whirl, though.

Regards,

Thomas

4

Hi Thomas,
if you can, use WKD in your company, it is much better than a keyserver usually.
(Unless you would want external keys in there, then it is hockeypuck, yes.)

If Gpg4win 3.1.16 works and 4.0.0 does not, can you use a modern GnuPG and install it over the one in 3.1.16 and see if this produces the defect? Otherwise, yes a report to dev.gnupg.org is probably the next step.

It can be the GnuPG version, but it also could be the gpgme Version used.

Regards
Bernhard

5

Small update, for the archives: for various reasons, I was not able to follow up on this at the time - but as we are now a few minor releases further, I tried the same thing with 4.0.3 for giggles. The result was that any search for a key (same SKS server as before) now results in an error message “The OpenPGP keyserver returned certificates without fingerprints. Those certificates are ignored …”

3.1.16 is still working fine with the same server - and when I import a key from that very same server on 3.1.16, it gets imported including fingerprint, so the server seems to return that information somehow (though I cannot directly see it in the logs).

[Side note: we did try to install hockeypuck in the meantime, but not successfully (multiple attempts trying to get a working installation following various options the manual resulted in failures) - but that’s a different story.]

6

Hi Thomas,

can you try (on a test installation) to install the modern GnuPG version over
the one in the working Gpg4win? And see about the differences?

You can then try to enable GPGME debugging to compare the cases, see https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html

The next goal has to be instructions how to reproduce a problem like this in public (easily, if possible).
Have you tried any of the remaining SKS servers operating?

Regards
Bernhard