Forum: help-en

Monitor Forum | Start New Thread Start New Thread
RE: Kleopatra only returns one key from keyserver [ Reply ]
By: Bernhard Reiter on 2022-02-25 11:01
[forum:8296]
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

RE: Kleopatra only returns one key from keyserver [ Reply ]
By: T Ribbrock on 2022-02-25 10:11
[forum:8295]
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... ;-)

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

RE: Kleopatra only returns one key from keyserver [ Reply ]
By: Bernhard Reiter on 2022-02-25 10:03
[forum:8294]
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


Kleopatra only returns one key from keyserver [ Reply ]
By: T Ribbrock on 2022-02-25 09:35
[forum:8293]
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!