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.contex 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.

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 put "scd" tag and let me claim this ticket.

This symptom can be explained by the nPth bug of T7386.

The symptom of this bug was:

• there are multiple waiters for COND.
• COND is fired by npth_cond_broadcast, all waiters should be waken up, but only one wakes up by the old code of 1.7.
• other waiters keep waiting forever.

After I fixed the problem, I realized that the description of this ticket was not accurate, so, modified.

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

For the record, I add the info here too (was: just in xmpp).

Fixed in 1.51, by introducing gpgrt_spawn_actions_set_env_rev, which assumes utf-8 encoding.

Fixed in 1.51.

Fixed in 1.51.

@ebo @ikloecker Let me explain my thoughts. If you have time, please help me doing some tests in your environment.

This shell script running gpg-connect-agent should run successfully:

SCD SERIALNO serialno can move the first card in the list in scdaemon.

@ikloecker Using scdaemon with multiple cards, it is a connection which holds the card.

@ikloecker Thank you sharing the problem. I don't know much aboug NKS card.

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.

@ebo Thank you for your continuous testing.

@ikloecker : Thanks for investigating. Please note that gpg-agent is incompatible wrt LISTTRUSTED (2.2 vs 2.4). So, No data callback in IPC maybe expected with gpg-agent 2.4.

I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/

Thanks. Fixed in: rEd14c69a7f256: Avoid use of 'nullptr' for an identifier.

I found fd resource leak in gpg-agent.

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

For the second case, I think that gcry_kdf_defive should not be called with pw="". The result of FAILURE gpg-exit 33554433 comes from the log_error after failure of gcry_kdf_derive.

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

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

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

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

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

Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.