@gniibe: Now that we use the KEM API, how do we proceed with this ticket?

The actual project we had in mind for this was more or less canceled and thus I re-prioritize this task.

Reminder mostly to self: This is about the KDF parameters. In the light of PQC composite algorithms we may want to also prepare for PQC required stuff.

A brief update: This feature has not made it onto the roadmap of specific things to implement so far.

This might also be related to rGa7ec3792c5 (cf. T2982)

For command line, reported issues have been fixed; Confusions for wrong errors are gone, it correctly reports appropriate errors of:

• GPG_ERR_PIN_BLOCKED
• GPG_ERR_NO_RESET_CODE
• GPG_ERR_BAD_PIN

What is the status (or maybe better scope) of this ticket? Why was it set to the milestone 2.4.5?
I do not see any improvement in Kleopatra from Gpg4win 4.4 (with gpg 2.4.7) regarding the behavior when trying to unblock a card.

Fixed in 2.5.2.

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.