AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

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:

Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.

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.

I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.

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

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.

I think that it means that you only applied the last two patches.

Thanks again for your update.

I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html

Thanks for opening a ticket.

Thanks a lot for your cooperation.

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.

Contrary to your expectations, all gpg --card-status fail after yubikey insertion:

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)

In case you need any information, be sure to let me know. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?

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

I'm certain I've applied the patches correctly. This is my current patchset:

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.

I've uploaded the requested information with triple verbose and debug-all setting in the scdaemon.conf as scdaemon.log:

Applied to 2.2 branch, too.

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.

With the patch and after starting a new gpg-agent, gpg --card-status now works immediately.
But when I re-plug the yubikey, gpg reports gpg: OpenPGP card not available: Card error until either gpg-agent is restarted, or pcscd is restarted.
pcsc-lite in debug mode reports no errors, but one log is obviously much shorter as gpg fails early (I've attached both, same pcscd and gpg-agent instance).

I pushed a workaround.

FWIW, your comments about the autostart script do not match with the running processes. Obviously, the autostart script starts gpg-agent with different command line options than the running process. My conclusion is that the autostart script isn't used. Or maybe it is started, but gpg-agent immediately terminates because it notices that another instance is already running.

If you add an autostart script then you may have to add a corresponding shutdown script as well, e.g. a script running gpgconf --kill all. You cannot expect that daemons, that you start via an autostart script, magically know when they should terminate.

Thank you for the hints!

Thank you for the explanation. (It's not related to --supervised, I suppose.)

I see the following GPG-related commands running currently (with disable-scdaemon in config file):

The issues mentioned in the previous comment have been fixed.

I had a look at the file system watcher we use to react on changes in the GnuPG home directory. It doesn't watch the private keys living in private-keys-v1.d. Moreover, it does not handle the removal of files properly.

My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) (key Ed25519) works fine with OpenSSH using kex of sntrup761x25519-sha512@openssh.com.

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.

We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?

There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).

I confirmed that the patch above works with newer Gnuk (>= 1.2.16).

With newer Gnuk Token, following patch should work:

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 05e1f3977..439052f8c 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -5490,6 +5490,11 @@ do_auth (app_t app, ctrl_t ctrl, const char *keyidstr,
           exmode = 1;    /* Use extended length.  */
           le_value = app->app_local->keyattr[2].rsa.n_bits / 8;
         }
+      else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
+        {
+          exmode = -254; /* Command chaining with max. 254 bytes.  */
+          le_value = 0;
+        }
       else if (indatalen > 255)
         {
           if (!app->app_local->cardcap.ext_lc_le)

When we will find reproducible test case, please reopen.

And updated scd_validate2.py:

Wrote a pam module which interacts a user for auth:

I write a prototype in Python using pyassuan:

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

Thank you for your suggestion.

The problem was the error handling.
I didn't apply the patch directly, but improved the code paths.

Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.

Kleopatra now checks both keyserver options. Previously, Kleopatra checked only one of them depending on the version of gpg (< 2.3.0 vs. >= 2.3.0). Note that the automatic lookup is only done if the keyserver option specifies an LDAP server, i.e. if it starts with "ldap".

Lets downgrade the priority and keep it open in case we get reports from customers. The other option would be to replicate this here using our AD demo network. But that is a bit time consuming.