I'm wondering whether we are hit by undefined behavior. https://en.cppreference.com/w/cpp/algorithm/sort mentions some conditions that must be met for (un)defined behavior. Or it's a bug in gcc or gcc's STL. I added some debug logs to the comparison lambda. The first comparisons look fine but after a certain number of comparisons it crashes in the debug logging (when it tries to access the primary fingerprint).

The usability challenge does already exist today because Kleopatra allows to encrypt all files separately. Currently, all encrypted files are written to the same output folder. Which is highly problematic if some of the original files have identical names. Encrypting the individual files in-place would avoid the problem of name clashes.

It would be helpful if gpgconf --list-options gpg listed the default-new-key-adsk option so that Kleopatra knows whether the option is set.

The usability challenge here is what happens if the encryption does not work for some files in between:

Note that the origin stored for the key is for example required if a key is updated by fingerprint. In that case we don't known from which user ID to take the origin.

I updated the certificates of Werner, Andre and you and got as result "The certificates were updated.", i.e. plural, for both, keyserver and WKD. Singular could mean that only updates for one certificate were found.

That the first result is selected is a side effect of making the certificate list more accessible. When the lookup finished, then the certificate list gets focus so that the users can immediately interact with the result. When the list gets focus we unset and reset the current item which triggers the selection of the item. And that triggers an accessible event (so that the user knows than a list item was/is selected).

Looking only at the text used, you get exactly the same messages used for single certificate updates, "The certificate has been updated" or "The certificate was not found.", both in the singular.

Querying WKDs for keys not retrieved via WKD leaks information, i.e. a (fake) WKD could track who is looking for keys. KDE's privacy-by-default policy doesn't allow such a setting to be enabled by default. (In VSD you can enable it for certain customers who don't have a problem with this.)

Note for testing: To reduce the PUK counter to 0 you have to enter a wrong PUK for "Unlock Card". The wrong PUK must have at least 8 characters. Otherwise, gpg-agent will consider the PUK wrong without even asking the smart card so that the smart card doesn't get a chance to reject the PUK and decrease the PUK counter.

And "But "Update certificate" does still not query WKD (not even after restarting Kleopatra.)" seems to happen because the setting "Query certificate directories of providers for all user IDs" wasn't enabled.

Tested with Gpg4win-4.3.2-beta25:

When VSD33 has been updated to integrate the fix/commit then this can be closed (i.e. set to vsd-3.3.0) without manual test, in my opinion.

The (rather trivial) changes where reviewed by Sune. And it's not really a very important issue. Therefore, I'll set it directly to resolved.

Merged to VSD33.

Ok, follow up for the column is T7155.