Description of problem: Yubikey 5C NFC fails to be detected as smartcard for openpgp application. gnupg2-2.3.7-1.fc36 contains an upstream regression (https://dev.gnupg.org/T6070) causing some Yubikeys to no longer be readable by gnupg2/scdaemon/gpg-agent. Version-Release number of selected component (if applicable): gnupg2-2.3.7-1.fc36.x86_64 How reproducible: Always Steps to Reproduce: 1. gpg -d foo.gpg (where foo.gpg is encrypted with a cv25519 key residing on a Yubikey 5C NFC.) 2. pinentry prompts "Please insert the card with serial number:" 3. Insert Yubikey 5C NFC , select pinentry OK selection and press enter. Actual results: pinentry keeps on showing same prompt. Expected results: pinentry to proceed to prompt for Yubikey PIN. Additional info: gpg-agent log: gpg-agent[-]: scdaemon[-]: detected reader 'Yubico YubiKey OTP+FIDO+CCID 00 00' gpg-agent[-]: scdaemon[-]: DBG: Curve with OID not supported: 2b06010401da470f01 gpg-agent[-]: scdaemon[-]: error selecting additional app 'openpgp': Card error - skipped gpg-agent[-]: smartcard decryption failed: Operation cancelled ykman info: Device type: YubiKey 5C NFC Firmware version: 5.4.3 Form factor: Keychain (USB-C) Enabled USB interfaces: OTP, FIDO, CCID NFC transport is disabled. Applications USB NFC FIDO2 Enabled Disabled OTP Enabled Disabled FIDO U2F Enabled Disabled OATH Enabled Disabled YubiHSM Auth Disabled Disabled OpenPGP Enabled Disabled PIV Enabled Disabled lsbusb info: Bus NNN Device NNN: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Upstream bug: https://dev.gnupg.org/T6070 https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=f34b9147eb3070bce80d53febaa564164cd6c977
I came here to report this as an issue and found this open entry. The bug is consistent with the issue described upstream, namely, I have a non-working Curve25519-using Yubikey 5C that responds as if blank to gpg2 --card-status, yet other 'cards' such as a smartcard (OpenPGP Card V2.1) work fine. Downgrading the gnupg2/gnupg2-smime package resolves the issue. The main contribution I can make is that this issue impacted me on *ppc64le*, i.e. this is where I noticed it and downgraded packages. Unsurprisingly given the upstream report, which I didn't know about prior to landing here, this is not architecture specific.
Will there be a backport for https://dev.gnupg.org/rGf34b9147eb3070bce80d53febaa564164cd6c977 to 2.3.7 soon?
FEDORA-2022-c5fbdfc5ae has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c5fbdfc5ae
FEDORA-2022-c5fbdfc5ae has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-c5fbdfc5ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c5fbdfc5ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-c5fbdfc5ae has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.