There is no such concept of a primary keyblock for a subkey. Using the same subkey for several primary keys is non frequent but nevertheless seen use-case. Thus this behaviour is not ADSK specific. I would suggest to first search the keyblock used for decryption to get the name of another subkey - only if that is not found search the keyring for that subkey and thus the primary key and its user id.

FWIW, the cache has not been implemented in 2.4 (which will be used for the next gpg4win) and thus there is no need for a fix there.

Was fixed last Thursday with commit rG69a8aefa5bf77136b77383b94e34ba784c1cce89 for 2.2 and will soon make it to master.

It is not of the recipient's business to know which certificate also uses a subkey. For all the user needs to know that it is a subkey which belongs to a primary key. In this regard this is not different from a shared encryption subkey as used by many sites for role addresses. For a subkey the user id of its primary should always been show.

Yes. I think that Kleo does not yet fully support the R-flag indicating an ADSK.

systemd based Linux?

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.