The Certificate Details window now has an Update button.

I don't think that it makes much sense to do an auto refresh (only) when the details are opened. If the automatic refresh is really important, then it needs to be performed in the background for all keys all of the time. If people want to encrypt a file, then they won't look at the certificate details for all recipients to make sure that all keys have been refreshed. They will expect that all keys are up-to-date without them having to care about this.

Please add a separate task for an automatic refresh.

In T5903#157763, @ikloecker wrote:

Please add a separate task for an automatic refresh.

There already is one: T1235

The changes have been backported to VSD. Note that they require today's changes in gpgme (just after the release of gpgme 1.22.0).

In T5903#174528, @ikloecker wrote:

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).

I do not think that this is a good solution. I don't know how you came to the conclusion that only user IDs which wre originally retrieved via WKD should be considered.

It is quite common to distribute keys which are in WKD also by other means nearly no keys in my keyring have origin WKD since they were retrieved through other means like auto-key-retrieve auto-key-import, manual import etc. With very few of our customers currently implementing WKD but considering this in the future. For my personal keyring and the keyrings of our current customers this change has little use.

My takeaway from our discussion on thursday was that:

In T5903#165865, @ikloecker wrote:

In T5951#165848, @aheinecke wrote:

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

I would suggest the following, if it is somehow possible. I think we have the API for this now that we can search for WKD keys without importing them. We should additionally check WKD, if the key from WKD has the same fingerprint, we update, if it has not, we show the user something like a search result. Give indication that a different key was found for these UserIDs and then let the user decide to import them?

But that instead of giving the user a choice we would inform the user that additional keys were retrieved. So basically what you originally did but just with an added explanation to avoid the confusing behavior which still exists with this change that when you hit update on a key, that key is not updated but a completely different key is imported.

Optionally, (configurable on the Directory Services page) Kleopatra now queries WKDs for all user IDs when updating an OpenPGP certificate.

Tested at first with GnuPG-VS-Desktop-3.2.0.0-beta178 from 2023-08-29

Debug output shows, that -- for a WKD retrieved key -- keyserver etc as well as WKD is queried.

Information for user looks like this:

I'll have to update the translation. What I don't like in the message is, that It says for keyserver that the key was unchanged although no key could be retrieved via AD. But we have T6299 for that.

With keys from unknown origin you get:

The config option is not included in the GnuPG-VS-Desktop-3.2.0.0-beta178 build, but it is in Gpg4win-4.2.1-beta31 from 2023-09-06.
But there it seems to have no effect. No WKD lookup occurs for keys of unknown origin.

Opening the configuration page show in debugview:

[5328] org.kde.pim.kleo_ui: Configuration groups order is not defined for  "keyboxd"
[5328] org.kde.pim.kleopatra: open_or_raise showing window
[5328] org.kde.pim.kleopatra: Module changed:  true  mod  DirectoryServicesConfigurationPage(0x535e900)
[5328] org.kde.pim.kleopatra: Client changed:   mod  DirectoryServicesConfigurationPage(0x535e900)
[5328] org.kde.pim.kleopatra: Using config entry dirmngr / keyserver
[5328] org.kde.pim.kleopatra: Module changed:  true  mod  DirectoryServicesConfigurationPage(0x535e900)
[5328] org.kde.pim.kleopatra: Module changed:  false  mod  DirectoryServicesConfigurationPage(0x535e900)
[5328] org.kde.pim.kleopatra: Client changed:   mod  DirectoryServicesConfigurationPage(0x535e900)

And when you then toggle the option "Query certificate directories of providers for all user IDs" plus hit "Apply":

[5328] org.kde.pim.kleopatra: Module changed:  true  mod  DirectoryServicesConfigurationPage(0x535e900)
[5328] org.kde.pim.kleopatra: Client changed:   mod  DirectoryServicesConfigurationPage(0x535e900)
[3920] Invalid parameter passed to C runtime function.

Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

Please re-run with gpg.qgpgme.debug=True in your qtlogging.ini to see for which email addresses WKD is queried.