The fix should probably be backported to gnupg 2.2 and 2.4.

I confirm the fix. Using gnupg master the unit test ran 544 times without any failures or suspiciously long run time.

Good catch, @ikloecker !
I located the bug in GnuPG, and the fix is: rG71840b57f486: common: Fix a race condition in creating socketdir.

In the second case, gpg emits a FAILURE gpg-exit 33554433 status at the end. I think this makes gpgme consider the operation failed. I think this is a bug in gpg because gpg does not emit a FAILURE status if a wrong symmetric passphrase is entered.

In the first case, gpg emits a CANCELED_BY_USER status. This makes gpgme abort the operation. We may have to wait/watch for BEGIN_DECRYPTION / END_DECRYPTION.

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'm still seeing the same problems both with current master and 2.2

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.

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

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

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.

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

Replacing gpgrt_spawn_actions_set_environ by gpgrt_spawn_actions_set_envchange is not good, as it's exported and already used.

This is a super old bug report, this is likely fixed with a new version of Kleopatra, so I am closing this. If this happen again in the future, feel free to reopen this bug report.

This is no longer possible. The sign/encrypt button is disabled and an info box is displayed.

No reply for a very long time, so I am closing this ticket. This is likely fixed now. Feel free to reopen if this happen again.

No reply for a very long time, let's close this.

gpg4win 4 has been released with unicode support. Closing.

works for VS-Desktop-3.2.94.2-Beta (Beta for VSD 3.2.4)

I knew that we'd need something like D604 when I saw rM409e31458227, but then I forgot about it. :/

should be fixed with D604

We won't fix that for 2.2.

works, the Root-CA of the above example is only shown once any more. Gpg4win-Beta-50

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

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

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.

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.

Here is my attempt:

Please write at least a short description and give it a priority

Pretty brief description :-(

It is reproducible bug even with master branch.

on gpg4win-Beta-50 things look much, much better.

I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.

We won't do that for Windows.

Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3

I guess this is now fixed for all branches.