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.

Source (or origin as it's called in the API) exists as per-key and as per-user-ID property. For the user IDs it should probably be shown in the user ID table.

In fact, the ChangePassphraseCommand uses gpgme_op_passwd which "changes the passphrase of the private key". It doesn't know anything about smart cards.

I think we should simply disable this command for card keys. Card key operations like "Change PIN/passphrase" should be performed via the card key view.

Can you make a short video of this? On Linux/KDE Plasma, I'm not even able to select multiple lines in the certificate details window (or I'm trying the wrong thing).

I fully agree. I also think that the separate recipient tab are rather annoying, in particular, because I usually want to select the recipients before I write the text. Accessibility will also benefit if all inputs can be reached easily with the Tab key without the need to switch between different tabs.

Proper accessible error reporting will be done with the accessibility related tasks.

For the same reasons "Print Secret Keys..." is now also disabled for keys stored on smart cards. No other command seems to require access to the secret key data.

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

No sure, you could also consider the is_cardkey flag to mean that a secret key might be available. FWIW, GPA sets it internal secret key flag based on the type of listing done; thus I see no problem if you want to change the behaviour.

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

The Certificate Details window now has an Update button.

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.

This can be bypassed by entering the date manually, was reported by a customer and I have just confirmed this.

When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.

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.

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.

Its a nitrokey start. I gave it another spin just to make sure, and again when updating to openssh 9.0 and "gpg (GnuPG) 2.3.6-unknown", it fails (again with careful gpgconf --kill gpg-agent etc. Double checked the downloaded source code by arch's makepkg, appears to have that patch applied. Also tried adding -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com to the ssh command, which didn't help.

Looks like somebody is writing to the shared config after it has been destroyed already. Probably some global object that is destroyed by the runtime on shutdown.

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.