It's a bug I introduced when fixing T7309.
Fixed in rGaa36f6ae8bae: gpg: Fix key generation with existing key from card.

IIUC, simpler solution would be modifying m4/socklen.m4 adding Solaris variant specific code.
Tweaking _XOPEN_SOURCE requires the change of Autoconf (if done correctly), which would be larger surgery.

Here are changes for gcry_md_open and its friends.

My idea in https://dev.gnupg.org/T7338#195529 doesn't work well when a function call is done multiple times.
Assuming SUCCESS, and marking all non-compliant places in the code works, and it would be good because libgcrypt so far maintains non-compliant path with rejection.

Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.

It seems that the internal API (as of 2024-12-06) is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.

A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.

New external API is by GCRYCTL_FIPS_SERVICE_INDICATOR and/or the new macro gcry_get_fips_service_indicator.
This change is pushed by rCf51f4e98930e: fips: Introduce GCRYCTL_FIPS_SERVICE_INDICATOR and the macro.

New internal API is introduced with T7340 by the commit rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

Change is pushed by rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

Closed, since this was documentation for the workaround, four years ago.

Put it under lower priority, as it's basically programming error.

OK, it's done. closed.

Here is my proposal to avoid unsynched state for data.

diff --git a/src/client.c b/src/client.c
index 410f940..0989984 100644
--- a/src/client.c
+++ b/src/client.c
@@ -250,6 +250,7 @@ assuan_transact (assuan_context_t ctx,
   int off;
   char *line;
   int linelen;
+  gpg_error_t last_err = 0;

Done for 2.5.0.

Done in 2.5.0.

Fixed in 2.5.0.

Fixed in 2.5.0.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.4.6.

Fixed in 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.

For this ticket, I reviewed the code around my SOS changes.
Because I'd like to focus the point of retaining binary representation when doing import->export,
I created another thicket: T7426

Actually, it's a bug when importing a key. It's not-intended-side-effect of the change in rG0a5a854510fd: gpg: Fix false negatives in Ed25519 signature verification..
Fixed in rG70c49ce02401: gpg: Fix modifying signature data by pk_verify for Ed25519.

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.

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.