I expect that the user can change the expiry date to 01.10.2024 but nothing else.

In T6882#191854, @werner wrote:

While testing this I noticed that only the last adsk or trusted key is listed. Thus several assurances of this options are not properly represented. See T7313

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

No we are at 4 seconds.

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

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.