You should use gpg-agent's integrated ssh-agent. It is anyway much more convenient. I'll move this task to gnupg26, though.

Backported to 2.4 to go into 2.4.6

Was fixed in master with rG374195e741cf1c52daad6c07799d308c8a9f73e3 (bug tag was missing in the commit).

Fix backported to 2.4

Alright, finally supported by gpgme (fot 1.24) For testing you may use

Thus the rule is that all our Qt applications except for pinentry need to fist initialize gpgme to get the actually used GNUPGEHOME. gpgconf either takes this from the GNUPGHOME envvar or from its default or via its gpgconf.ctl file.
The latter can eventually be used to move the default homedir to %APPDATA%\gnupg-vsd so to allow using different versions of the gnupg engine.

Indeed, gpg fixes a long standing bug in that expired trusted-keys were not correctly handled. Thus this error message

If we fix this bug for 2.2 we need to have a configure way to revert to the old behaviour. That needs to be a kleopatra config. Or we just don't fix this bug for current vsd but only for gpg4win and the next generation vsd.

Solved for gnupg 2.2, 2.4 and 2.6. GPGME support still missing.

iirc, Kleopatra modifies the trustlist.txt on its own. The import case is handled by gpgsm which pops up boths dialogs.
Kleopatra should also not offer to add a root CA if gpg-agent's mark-trusted feature has been disabled.

Also done for gpgsm in gnupg26 (master)

The C comittee is getting more an more absurd by adding new keywords. Breaking software for fun and funding. Workaround should be easy: Don't use the C23 option.

What about the simplification below. Add more authors and sort-lines as you like. There is no legal necessary to show a full list of copyright holders. Authors are not a legal term in the context of software because software is not considered a piece or art. From the GNU coding standards related to the version/about output:

See T7255 instead.

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