Fixed in 2.5.0 and 2.4.6.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.4.6.

I believe this was fixed by T7386. Or it is now no hard lock up by T7402.
So, let me close this ticket.
If any new symptom, please add information into T7396.

I can say it's fixed in 2.4.7.

In select_application function, we can minimize the holding W-lock.

This may requires major changes for scdaemon.

For the cancelling operation, each card reader access should have an independent resource manager context.
Currently, a single pcsc.context is shared by all reader accesses.

Hard lockup should be avoided. In particular, following conditions should meet:

• gpgconf --kill scdaemon can kill scdaemon
• KEYINFO requests can be answered for other connections of scdaemon

As of 2024-11-18, my hypothesis is:

• there are some sort of race conditions between PC/SC + card reader (or its driver) + smartcard + scdaemon on Windows, at least at initial use after boot
• because of this, SCardConnect of PC/SC call wrongly fails (somehow confirmed by @ebo's experiments + @gniibe's speculation), or wrongly never returns (@gniibe's guess, side info: its slowness is observed in T7400).

@ebo Thank you for your testing.

@ikloecker indeed we try only for 5 seconds:

I think that the card reader is not connected and there is no Scardsvr at this time.
And the card reader connection to USB port results invoking Scardsvr. Then, "SCD SERIALNO --all" gets success.

For T6567 I changed the way that Kleopatra runs "gpgconf --launch gpg-agent". This change is not yet in Eva's test build. It seems my change is not good because running "gpgconf --launch gpg-agent" timed out after 5 seconds in 3 of 3 tests starting Kleopatra after a reboot of the VM. To check if "gpgconf --launch gpg-agent" really takes that long I measured the time in PowerShell after another reboot of the VM. The result is shocking.

Please note that a card insertion to a card reader and a card reader connection to PC are different things.
It may cause different results.

ebo: Thank you for your testing.

I found an issue in libassuan, which might be related possibly, it is described in T7399.
When the response is not consumed like the case in T7399, if repeatedly, it may fill up the buffer eventually.

I believe this is a case of non-consumption of client. on Gpg4win-Beta-75 + updated GnuPG.
Setup: I had two cards connected, one Yubikey and one Netkey3.0 card. I rebooted windows and started Kleopatra. Nothing else.

I put "scd" tag and let me claim this ticket.

FWIW, we should eventually get rid of the pipe + socket style connection model. It is just to complex with no real benefit.

After fixing two bugs, I changed the title to express the scope of this ticket.

I found a problem of possible duplicate registration of another APP, due to no serialization for CARD access.

The resource leak was fixed in: rG40707c8bff49: agent: Fix resource leak for PRIMARY_CTX.

This seems to have been resolved in 2.4.6 by T7151 or T7160. I don't really remember the details, but at least I don't see anything blocking system shutdown now.

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 somewhere

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.