Page MenuHome GnuPG

Searching for public keys with default setting for OpenPGP-Keyserver does not work (under some conditions)
Closed, DuplicatePublic

Description

New Installation Kleopatra Version Gpg4win-4.0.0 with the default values and updated version of Windows 10

Settings -> OpenPGP keyserver: "hkps://keyserver.ubuntu.com" (default URL and grey font)

When I click the "Lookup on Server" and enter "Thomasv" there are no results. When I enter or copy and paste "hkps://keyserver.ubuntu.com" -> "Settings" -> "OpenPGP keyserver" (default URL and black font), then I click the "Lookup on Server" and enter "Thomasv" there are results of "Thomasv". Import works also.

Old Installation Kleopatra Version Gpg4win-4.0.0 with the default values and older (not updated since 2022-01-12) Windows 10
When I click the "Lookup on Server" and enter "Thomasv" there are results for "Thomasv". Import works also.

Details

Version
Kleopatra Version Gpg4win-4.0.0

Event Timeline

bernhard renamed this task from Default Settings of OpenPGP-Keyserver does not work to Searching for public keys with default setting for OpenPGP-Keyserver does not work (under some conditions).Feb 18 2022, 2:31 PM
bernhard updated the task description. (Show Details)

We (@hakan-int and myself) saw the problematic behaviour in one setting. It was a VM where Gpg4win had been installed, deinstalled and reinstalled again. We still try to find out how to reliably recreate the situation and what is the difference between a working and a non-working case.

The user who made the first report about this issue, it could help: Forum Wald

Try with hkp:// - I assume that you are missing the new Lets Encrypt CA certificates

When I overwrite the default value "hkps://keyserver.ubuntu.com" with another value in "Settings" -> "Configure Kleopatra" once and click "Apply or OK" and delete this new value again, then Kleopatra does not insert the default value to the necessary place again.

The only default value which appears is "hkps://" and that is not correct. I solved the issue by changing the second line of the config file "dirmngr" (%APPDATA%/gnupg) from "keyserver hkps://" to "keyserver hkps://keyserver.ubuntu.com".

NOTE: Deleting or changing this line "keyserver hkps://keyserver.ubuntu.com" will fix it only for the current session.

The main problem is, that another program overwrites the changed value "keyserver hkps://keyserver.ubuntu.com" again with the old wrong value "hkps://".

Bernhard wrote me, it could be "gpgconf".

Actually all changes Kleopatra does go through gpgconf. Thus is is normal that gpgconf overwrites things.

@werner the main issue here, that Hakan has found a usability problem:

Kleo writes and displays wrong value when keyserver field is cleared

If the keyserver config value is getting deleted in Kleopatra by the user,
then Kleo writes

keyserver hkps://

to the dirmngr.conf file, but displays the default value hkps://keyserver.ubuntu.com. Now the configuration is broken (because of bad entry in the config file), search does not work and Kleo wrongly displays a value that is not used.

further analysis that gpgconf works as expected

@hakan-int can you test that if you stop Kleopatra (completely, please check with the task manager) and if you change the configuration file, things are fine afterwards?

@bernhard when I close Kleopatra and stop the its task by the task manager, then the value remains. But as long as I do not change the default value to an other value in "Settings" -> "Configure Kleopatra". As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again. I think, this is not the expected default value, is it?

@hakan-int :

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

(I hope only if you completely delete it, as it should keep any other value and write it to file.)

@hakan-int :

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

(I hope only if you completely delete it, as it should keep any other value and write it to file.)

Of course.

@ikloecker thanks for the hint (At first it looked like a different defect.)