Fixed for master. Let's first test this with kleopatra.

Done for 2.2. It is already in 2.4.

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

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