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.