Mark for backport to VSD 3.3

Done. Not relevant for VSD 3.3 because there we use a much newer GpgME anyway.

On a fresh install Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta35) are now all available columns displayed by default:

Tested with version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta25)

Some logs after entering a wrong reset code (PUK) for an OpenPGP smart card.

404.228467	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: sendCommand "SCD PASSWD --reset OPENPGP.2" failed: "Falscher R?ckstellcode" (code: 322, source: SCD)
404.230320	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString gettext_use_utf8(-1) returns 1
404.230596	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString error: Falscher R?ckstellcode
404.231068	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString error (percent-encoded): "Falscher%20R%FCckstellcode"
404.231182	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.kleopatra: ChangePinCommand::slotResult(): "Falscher R?ckstellcode" ( 322 )
404.231315	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString gettext_use_utf8(-1) returns 1
404.231428	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString error: Falscher R?ckstellcode
404.231850	2024/05/27 15:56:17.987	8056	kleopatra.exe	org.kde.pim.libkleo: errorAsString error (percent-encoded): "Falscher%20R%FCckstellcode"

rere 2: I agree as long as the expired certs are order behind regular certs.

In Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta25) the button is not shown any more.
As it was already not shown in VSD 3.2.2, closing this for all workboards

Re 2.:

• I think expired user IDs should also be offered. Otherwise, people who forgot to extend the validity of their certificate won't find their certificate. Usability-wise it's better to offer the certificate and show a notice that the selected certificate has expired. I wouldn't differentiate between primary and additional user IDs.

In general, I question the usefulness of the tool tip for the certificate list. The information in the table is already very detailed and for more details there's the details view. Important information that's missing in the table shouldn't be hidden in the tool tip.

I guess we want to backport the above change for VSD 3.3.

First mock of new UI for PIV

Show S/MIME keys as coming from LDAP in certificate lookup: https://invent.kde.org/pim/kleopatra/-/merge_requests/237

As I wrote "That the first result is selected is a side effect of making the certificate list more accessible." and "When the lookup finished, then the certificate list gets focus so that the users can immediately interact with the result."

This also works for VSD 3.3 (because the required changes/patches are in gpg4win).

Done: https://invent.kde.org/pim/kleopatra/-/merge_requests/236

Fixed and backported for VSD 3.3.

I noticed a bug in the group config migration: T7181

The option "default-new-key-adsk" of gpg can now be read with Kleo::getCryptoConfigEntry, so that we can check if an ADSK is actually configured to decide whether it makes sense to offer the "Add ADSK" action.

Testing with various versions of kleopatra, I'm getting differing results:

Then I would propose to add additional text at the top of the tool tip for VSD versions only. Something along the lines of: "Please check with the approval document whether this function is compliant for your smart card model."
Would that be possible?

Kleopatra and likely also gpg have no way to know what products are listed in some approval document. And it would be very problematic to hard-code such a list in Kleopatra/gpg because it wouldn't be possible to update the list if new products are approved (which is very likely).

I have improved the heuristic for detecting light high-contrast themes. Upstreaming this is still open.

What makes a card compliant? is it just about supporting algorithms that are compliant?

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:

For VSD the key actions "Regenerate key" and "Generate key" should be hidden. (This is in the middle part of the view)

Backported for VSD 3.3

Yes. please.

@werner Shall this be backported?

Backported for VSD 3.3

Yes, please.

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

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.