Thanks again for your update.

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Thanks a lot for your cooperation.

TL;DR: can reproduce, needs fixing

Maybe we shouldn't exclude expired or revoked keys from the list so that people can still choose them. Of course, those keys wouldn't be accepted to be used for encryption, but it would help people to find out why the keys are not acceptable.

My email to gnupg-devel@gnupg.org was accepted and is visible in the archives https://lists.gnupg.org/pipermail/gnupg-devel/2022-May/035063.html
Cool

Thanks. Should be applied.

In T5950#158024, @werner wrote:

Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.

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.

Full build.log:

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:

Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

it was noted that this also affects other ML hosted there like those of freie-software.org

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:

Thank you, @gniibe. That's what I was missing: installing libsqlite3-dev made the difference.

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

Thanks for creating this ticket. I'll reply.

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

Yes, I saw that in the logs and installed those packages. Now I have sqlite and sqlite3 in /usr/bin, but that doesn't seem to have changed anything.

the link's target doesn't exist

Yes, of course I did that. The error output I included followed the sequence

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.

JW-D with Gpg4win-4 we have support for multiple readers and also a dropdown menu for selecting reader ports. This should resolve this issue.

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.

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