Will be available in 2.2.45 and 2.5.2

Now we are at 4 seconds. Available in master and 2.2.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

show invalid dates in another color in the calendar sheets (a different red than that of Sundays?)

This issue is still valid in principle as of gpg4win-Beta-50 (and VSD Testversions for VSD 3.3).

Closing this ticket, as the test version is now obsolete and the new one much improved. I'll open a new one for the remaining issue with scdaemon when I have more information

I wonder if this has to do with T5960: Kleopatra: Encoding problems with GnuPG output on Windows as this is a recent regression. The Umlauts are ok in Gpg4win 4.3.1

This has been addressed with T6878: Kleopatra: Subkey expiry date improvements by showing the expiration date of the primary key if the subkey doesn't have an expiration date.

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

This has been fixed meanwhile. (I can confirm the fix with kmail2 6.2.1 (24.08.1))

Please send an excerpt from the scdaemon debug output to evaluate why you get somewhat strange looking data. Is this an experimental card? 0xa5 is a common test pattern.

Yes, for historical reasons (i.e. we haven't changed this) the width of the name and email columns always defaults to 260.

tested with gpg4win-Beta50:

FWIW, a related task is T7308

With that patch we are down to about 6 seconds.

works, gpg4win-Beta-50

With no scd-event script, it might improve the situation

This is covered by T7302

Will do.

Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.

The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Here is my attempt:

Something which has high priority but has not been touch can't have a super high priority.

Please write at least a short description and give it a priority

Pretty brief description :-(

done: https://invent.kde.org/pim/kleopatra/-/merge_requests/285

It is reproducible bug even with master branch.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

V5 keys should now work as good as V4 keys in Kleopatra. For testing create a "Curve 448" key and then try a few things. Everything should just work because it works for gpg. Kleopatra doesn't really do anything special for V5 keys.

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

Done. I don't think this needs to be tested extensively because it's just some UI texts that now show the Key ID (with 16 hex chars) instead of the short Key ID (8 hex chars). And for files including key material we also use the Key ID (of primary key and/or subkey) now for the filenames, e.g. when exporting a public/secret key/subkey.

The change will also be included in VSD 3.3.

The version check can now be extended to 2.2.45 <= gpg < 2.3.0.

werner: Can you also backport listing of "default-new-key-adsk" with gpgconf so that Kleopatra can check whether a default ADSK is set?

Fixed. Ready for testing.

Backported for VSD 3.3.