For the white high-contrast mode we use the normal (black) Breeze icons now. I think for Qt 5 that's all we can do with reasonable effort. For Qt 6/KF6 we have to revisit this anyway because a lot has changed (see T6932).

Selection with unpatched Qt:

I found the following in this file. This looks as if everything should stay as it is.

/* Note for Windows: Ignore the incompatible pointer type warning for
   my_read and my_write.  Mingw has been changed to use int for
   ssize_t on 32 bit systems while we use long.  For 64 bit we use
   int64_t while mingw uses __int64_t.  It does not matter at all
   because under Windows long and int are both 32 bit even on 64
   bit.  */

Looks good to me

Backported for VSD 3.3

@werner Shall this be backported?

The import option "only-pubkeys" works for me/Kleopatra.

Backported for VSD 3.3

@werner Shall this be backported to VSD 3.3? The changes look more dramatic than they are. I mostly reordered existing code.

The problems with colors in high contrast mode were addressed with T6073: Kleopatra: Fix issues with high contrast resp. inverted color scheme. I'm not sure what's left to do. Setting to Testing for getting feedback what's missing.

Backported for VSD 3.3

In T6073#173463, @ebo wrote:

On windows the main window looks ok with high contrast mode black. But with dark backgrounds some items in other windows are not readable:

I'm setting this back to Testing. In the meantime GpgME has been updated to a 1.24.0 beta version and includes the needed functionality.

I backported this trivial fix for VSD 3.3. Support for drag&drop of certificates from Kleopatra to other applications or the desktop was added for VSD 3.3 (T6893) and it shouldn't confuse the users.

Ready for testing. Backported for VSD 3.3.

Backported for VSD 3.3

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

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.

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).

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.

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).

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.

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.