GCC 11.3 and GCC 12.1 are out with the fix.

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.

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.

I've applied the patch and can confirm that the segfault is fixed, but gpg still has severe problems communicating with the Yubikey over pcsc-lite.

Ours are even newer (5.4.3). Did you the Yubico tools to switch to curve443?
In any case, is it possible that you apply my fix and test again?

Your Yubikey's firmware version is 5.2.7 - let me see what versions we have in stock to test my fix.

I've taken the liberty to regenerate the valgrind report including libc and gnupg debugsyms. Maybe it'll help.

I am not sure about the crash but the unknown curve is
1.3.6.1.4.1.11591.15.1.2 which seems to be a GNU OID for curve448

It segfaults on SERIALNO. Here's what valgrind outputs:

What I would do in this case is to stop the gnupg daemon amd anything whiuch might start them and run scdaemon under valgrind.

Fixed in GnuPG 2.3.5.

Debian requires all builds to use software that we have local copies of in the archive, which appears to rule out the use of speedo (it fetches source over the internet during build). So i've modified debian packaging to annotate that the Windows builds need a different version of libgpg-error than that defined in configure.ac.

it would be useful to add a test

I'm seeing something just like this when attempting to install gnupg-2.3.6 on Ubuntu 22.04 LTS (running under WSL 2, if it matters).

Thanks for working on this, @gniibe! Maybe it would be useful to add a test to the test suite that tries to import and use a secret key of this particular structure.

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

Use our build system and things work. In particular you need to use the software versions as listed at versions.gnupg.org and available via the build-auch/getswdb.sh. Even better use the speedo build system for Windows. Everything else is not a supported build configuration.

Thank you for the report.

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

In T5950#157442, @ikloecker wrote:

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

Moreover, please make sure that there is no text in the field above the table (in the second figure) because this text is used to filter the displayed certificates.

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.

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

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.

After re-running myself a few times, I managed to hit it again. In tests/openpgp/report.xml, I see:

[...]
<testsuite name="&lt;keyboxd&gt;tests/openpgp/use-exact-key.scm" time="0" package="&lt;keyboxd&gt;tests/openpgp" id="0" timestamp="2022-04-25T16:18:27" hostname="unknown" tests="1" failures="0" errors="0" >
<properties/>
<testcase name="use-exact-key.scm" classname="&lt;keyboxd&gt;tests.openpgp" time="0" >
<failure message="Unknown error." />
</testcase>
<system-out>
Importing public key.
Checking that the most recent, valid signing subkey is used by default
    &gt; 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 &lt;
Checking that we can select a specific signing key
    &gt; 8BC90111 F5F77B83 1EA97479 &lt;
</system-out>
<system-err>
</system-err>
[...]

is there any update ? I having the same Issue here on Windows 11 Pro, Outlook Version 2203 (Microsoft 365) 64bit

Any idea? Any update?

Thanks. Will go into 2.3.6

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.

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

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)

Feedback from the lab is that they'd recommend returning a specific error code that indicates that the prime search failed and then relying on the caller to decide whether to loop or bubble up the error. I'm not sure who we would consider to be the "caller" of the relevant generation function in this case, though.

For the record, I am for the deletion as long as it is guarded by a safety check.

Here is my proposal patch:

diff --git a/random/random-drbg.c b/random/random-drbg.c
index 5a46fd92..f1cfe286 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -341,6 +341,9 @@ enum drbg_prefixes
  * Global variables
  ***************************************************************/