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… ) - 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!