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

I found fd resource leak in gpg-agent.

• gpg-connect-agent "scd killscd" /bye seems not release a file descriptor somewhare

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.

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

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

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.

With no scd-event script, it might improve the situation

The change of spawn functions (basically, it was factored out to libgpg-error) results more possibilities to have blocked scdaemon, since the implementation in libgpg-error introduced context switch points when it spawns a child process.

Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.

I don’t think I have any other client that would invoke SCD DEVINFO --watch.

Do you have scd-event script in your GNUPGHOME?

I see. the systemd race of having two gpg-agent processes. The second gpg-agent should eventually go away but than it is already too late.

I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).

You mean it is possible that the initialization function is called by several threads - or that two scdaemon's are running before they realize that one of them is in the way?

For POSIX, I found an issue of T7151.
If you are using multiple clients which invoke SCD DEVINFO --watch, the problem should be fixed.
If it's not the case, let us locate a bug (or two).

Fixed in rGfc30f7059650: scd: Fix DEVINFO to allow multiple clients.

I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).

Actually we have similar problems with the 2.4 branch - in particular on Windows. We can quite easy reproduce this when using Kleopatra. Thus the working hypothesis is a locking problem because Kleopatra uses several threads and the order of actions recently changed.

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.

Maybe we can support this directly in gpgme's assuan API.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

Thanks for your answer, @werner

Do not use the pcscd but the integrated CCID driver. This is actually the default form Unix. Or are you on Windows?

Hello all. I think I am affected by this problem (I get asked for the yubikey PIV pin every time I make a git commit).
Is there a known workaround?

Pushed the fix: rGbb57c808b2ad: scd:openpgp: Fix PIN pin2hash_if_kdf.

Applied to 2.4 branch.

@mwalle Thank you for your testing.
Applied to master.
After testing, I'll also apply to 2.4 branch.

FWIW, I've tested this patch and it works fine with both KDF as a constructed tag and as a primitive tag.

I'm considering applying the following patch. With this change, scdaemon will works well with a card implementation which consider F9 (wrongly) as primitive data object, as well as correct card implementation.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 26ac91ea2..09223ce33 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -410,6 +410,10 @@ get_cached_data (app_t app, int tag,
   size_t len;
   struct cache_s *c;
   int exmode;
+  int do_constructed = 0;
+
+  if ((tag < 0x0100 && (tag & 0x20)) || (tag >= 0x0100 && (tag & 0x2000)))
+    do_constructed = 1;