I found one reason for the intermittently failing concurrent initial keylisting. gpgsm sometimes uses the wrong socket file to (try to) connect to gpg-agent.

I don't think gpg/gpgsm tell gpgme "the keyblock used for decryption". They simply log all public keys used for encryption via STATUS_ENC_TO in the order the packets appear in the encrypted file.

I'm still seeing the same problems both with current master and 2.2

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.

In T7334#192524, @werner wrote:

For a subkey the user id of its primary should always been show.

Summarizing out-of-band discussion (please correct where i remember things wrong):

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.

In case of an unknown encryption subkey we could check if it's the ADSK of a known recipient and then display something like

Unknown ADSK for "Some key with ADSK <with-adsk@example.net>"

instead of

unknown recipient

Thinking about this some more, I don't think we can anything different from what's done in my patch:

Both subkeys belong to Alice from gpg's point of view

What is wrong in your opinion?

I can reproduce this with gnupg 2.2.45-beta27 (STABLE-BRANCH-2-2 69a8aefa) on openSUSE Tumbleweed.

We have this data already. The problem on kleopatra's side is that in the key cache, we add the ADSK subkey for each key that has it as an ADSK, causing a somewhat broken index and ultimately the problem seen here.

Is this R-flag part of the status logging, i.e. do we need to add handling for this in gpgme?

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

I suggest always updating modifications which are "exportable".

systemd based Linux?

With the change, T7169 is fixed (by side-effect).

Pushed the change: rE1860f6407f83: spawn: Add new function to modify environment.

I have reproduced this with libkleo from our gpg4win/24.05 branch and with gpg (GnuPG) 2.4.6-beta102 (HEAD of STABLE-BRANCH-2-4) and current master of gpgme and all GnuPG libraries. It took just 8 runs until a unittest failed.

gpgme logs for a failed test where the keylisting with gpgsm failed

Last time I used the Non-Sucking Service Manager to create a windows service.
This works fine when the program gracefully stops on a OS terminate signal.
But this is an additional dependency.