Pushed the solution which doesn't require new flag for libassuan.

^-- I withdraw the solution (with error value) above.

Besides, if lower layer solution is preferred, Yubikey can support having the special BWT value 0xff when bmCommandStatus = 2 (Time extension) is returned to host. The CCID driver recognizes this special value to prompt a user the dialog window.

Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.

Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.

Pushed rGea97683d5820: scd: Support automatic card selection for READCERT with keygrip..
I think that it works for PIV card.

For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates

I did some research about scree lockers (xtrlock, slock, swaylock, etc.).

The order to solve:

This is an experimental patch to support "Use-for-ssh":

cmd_keyinfo should be also updated to access the field correctly.

Also, it is better for a user, not to be asked confirmation (even if "Confirm:" is specified), that is, skipping the confirmation, when it is going to prompt the insertion of a card.

I put another change for T5099. This feature can be used for any keys, no matter if it's on Yubikey or not, no matter if token supports touch confirmation or not.

Part 2 patch is pushed, with a bit of change.
A user needs to specify "Confirm" flag in the key file.

Part 1 patch is pushed.

For this particular issue of assuan_inquire, if it's needed, the point we should fix is:

Pushed the change (master and 1.10).

At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.

A concrete example use case in my mind is:

• (Usual display manager (authentication by password or no-password))
• session starts with "locked" state of screen
  • In the beginning, user needs to "unlock" the screen, by scdaemon authentication
• (optionally, if needed) our-own-screen-locker should detect device removal, then, automatically locks the screen
• our-own-screen-locker should detect idling user session, then, disabling the card, automatically locks the screen
• our-own-screen-locker does authentication by scdaemon when it unlocks the screen

Note that this doesn't work if pinentry is pinentry-gnome3. pinentry-qt works well, too, because it supports curses fallback.

I added the last line, to recover tty state:

With cmatrix command and pinentry-gtk2, I now do experiment with this script:

No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.

This is updated version of gpg-auth, which clears the authentication state before trying PKAUTH.
Access is controlled by ~/.ssh/authorized_keys.

This is the one for login authentication (which invokes scdaemon to authenticate, instead of connecting by socket).

For the second, I wonder if newer xlclang++ compiler works with 1.9.

Thank you for the bug report.

Pushed the change.

To detect these kinds of bugs, possibly, we can use new GCC option: -ftrivial-auto-var-init=0xFEFEFEFE.
https://gcc.gnu.org/gcc-12/changes.html#uninitialized

The bug was there when it was initially written. It was in 2003, which introduced PC/SC in rG1bcf8ef9dea1: Cleanups, fixes and PC/SC support

When compiling the package, I can see that all 4 are applied.

Thanks for your confirmation.

Thanks again for your update.

Could you please give us the build log with no --disable-asm?

I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thanks a lot for your cooperation.

Please do experiment again and give us the whole log of scdaemon.log for:

• insert Yubikey initially
• run gpg --card-status (success is expected)
• remove Yubikey
• insert Yubikey second time
• run gpg --card-status (failure is expected)

Umm... The problem is the last bogus octet from Yubikey. In the log, we see:

The change improve error handling for possible other errors by device: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thank you for the logs. It seems that scdaemon didn't detect the removal correctly.

Pushed the change. Also, it's backported to 1.10 branch.

Thanks for creating this ticket. I'll reply.

Pushed the changes for http.c.

libgcrypt 1.10 is out with the API change for Windows, and we don't see any report (yet).