Default is "yes". When Prompt: no is specified, it doesn't ask but fails.

The behavior has been changed by T5996, to ask card insertion for the consistency of the semantics of configuration.

With the change for T5996 applied, the semantics is clear. "Use-for-ssh" flag is a key not for "OpenPGP.3", but other keys (not only OpenPGP.[12], but also for normal keys.)

This feature is implemented in different way, by T5099.

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.