Applied to 2.2 branch, too.

Pushed the change to master.

Pushed the fix.

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.

You need to install a package like sqlite-devel or libsqlite3-dev, so that you can have development header files and library (sqlite3*.h and libsqite3.so) and pkgconfig file (pkgconfig/sqlite3.pc).

the link's target doesn't exist

Please do make at first before invoking make check. It creates symbolic links for executables.

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.

GCC 11.3 and GCC 12.1 are out with the fix.

I pushed a workaround.

For my environment, it is not PC/SC-specific. It also occurs when CCID driver is used.

For bcdDevice 5.24, I can replicate the symptom, but only once. After second invocation of gpg --card-status, it works well.

Fixed in GnuPG 2.3.5.

Nitrokey Start uses Gnuk as its firmware. You need to upgrade its firmware to version 1.2.16 or newer.
Please note that when upgrading the firmware, your keys will be removed.

Background: I encountered a problem error message shows irrelevant; While it should say 'No such file or directly', it says 'Unknown Packet'.

Please describe what token is used. For my use cases with rGe8fb8e2b3e66: scd: Don't inhibit SSH authentication for larger data if it can., both of Gnuk (>= 1.2.16) and Yubikey (>= 5) work well.

it would be useful to add a test

Thank you for the report.

The fix was not right, because gpg-agent side are not changed. See T5953.

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

I located the problem. The test program use-exact-key invokes two gpg-es connecting by pipe (one gpg to generate a signature, another gpg to verify the signature). Those multiple gpg-es race accessing keyboxd.

Another test, it took 30 minutes to replicate.

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

Thank you. I can replicate the issue.

I pushed the change above. I also pushed another change with IOBUF_INPUT_TEMP.

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

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

Thank you for the bug report.

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)