I do not want to do that for 2.2.45 (T7255) because we want to do that release RSN

Is there a mechanism which can be used for this? Of course this could be done using the usual autostart feature, or we turn the server into a Windows service (ask @alexk). Start the client along with kleopatra?

Thanks for opening a bug report. This is better for our workflow.

But the DEVINFO --watch is required to trigger this hang? Kleopatra does not use this but we see simlar hangs from time to time in the current version.

With the new patch you get this now:

[GNUPG:] KEY_CONSIDERED F40ADB902B24264AA42E50BF92EDB04BFF325CF3 1
[GNUPG:] ERROR add_adsk 53
gpg: key "F40ADB902B24264AA42E50BF92EDB04BFF325CF3!" not found: Unusable public key
gpg: Did you specify the fingerprint of a subkey?
[GNUPG:] FAILURE gpg-exit 33554433

Test on a dedicated Windows box (T 460, i5-6300U@2.40GHz, harddisk):

Overall effect of these changes tested on a small Windows VM is only 47 -> 26 seconds. Did also tests with --kbx-buffer-size but that does not make it better than the default, either.

Porting to 2.2 was straightforward - we won't give it an extra QA run.

We won't fix that for 2.2.

Using the shorter OID for v5 is on purpose; thus we need to fix the export.

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

Done for 2.2. It is already in 2.4.

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

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.

FWIW, a related task is T7308

With that patch we are down to about 6 seconds.

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.

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 :-(

I see only links to our own pages and to the emailselfdefense - which is a good resource.

Hmm, two years old - I doubt that it makes sense to continue here.

Priority lowered in the light of the the forthcoming gpgol.js

Should definitely work with gpg4win if it works with vsd.