A minimal fix would be:

Backported for VSD 3.3

I checked who eats the second valid signature after the first invalid one. It's gpg in batch mode.

In reply to Ingo:
Ok, I can live with that but I still would like this message to be improved.
Looking at it some more I noticed some other details which bother me:

It is trivial append a bogus signature and would thuns inhibit to check the expected signature.

The part after the colon in "The signature is invalid: Invalid Signature" is the error returned by gpg that's responsible for the invalid signature. It could potentially be some other reason. Of course, we can simply not show the error anymore. Obviously, this would remove some details, but maybe that's okay. People could still look at the audit protocol for further information.

sorry, imprecise phrasing … we want this to be used in practice, which includes making the creation of a combined signature file easier.

In T6867#187289, @ebo wrote:

After discussion we concluded that showing all signatures in one detached signature file is something we want soon.

I verified that I can still build libkleo and kleopatra for gpg4win/24.05 (Qt 5) and master (Qt 6).

After discussion we concluded that showing all signatures in one detached signature file is something we want soon.

After talking with Werner, I edited T7155 to include displaying the protocol column, too, because this is useful in combination with his wishes regarding the origin keyword which are:

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.