Description of problem: Version-Release number of selected component (if applicable): gnupg2-2.2.27-2.fc34.x86_64 How reproducible: gpg2 --card-status Alternatively: echo "getinfo reader_list" | /usr/libexec/scdaemon --multi-server --debug-level guru --debug-all Actual results: No readers found. Expected results: Show card info / reader list. Additional info: 1) The card can be found via `lsusb`. 2) Chromium can find it for FIDO purposes. 3) OpenSC can find it. 4) The USB description seems to have been renamed between 33 and 34? I think this breaks how `scdaemon` matches cards when multiple are connected at once. In short, this seems GPG specific.
I was able to do some triage today and found a workaround: 1) Disable pcscd. This daemon was enabled after the upgrade and it claimed the YubiKey exclusively which was blocking my scdaemon setup. 2) Add a udev file to make the YubiKeys read/write. Also, I couldn't figure out how to make scdaemon talk to pcscd, otherwise I would have do that instead.
You can also try to use "shared-access" in your gpg-agent.conf which should address the concurrent access to the yubikeys from opensc and gpg: https://src.fedoraproject.org/rpms/gnupg2/c/3aa13442
Do you still have issues with this? Recent builds in Fedora 35 disabled ccid driver inside of the scdaemon and it should use the pcscd out of the box: https://src.fedoraproject.org/rpms/gnupg2/c/1450ac3691930d70bdb97eed866023c31a51cec2?branch=rawhide
I have a workaround and I won't be able to test Fedora 35 for a while now. Thanks for checking.
I have hit this bug after upgrading from Fedora 34 to 35. My GPG version (gnupg2-2.3.3-1.fc35.x86_64) should include the ccid driver change. I don't have ~/.gnupg/gpg-agent.conf. GPG and pcscd are competing for exclusive access to the YubiKey (5 NFC). After the system is started GPG fails to obtain access to the device: $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device After I stop pcscd.service GPG takes ownership of the card and can use it. pcscd.service gets reactivated by the socket but doesn't take back ownership, in the syslog I see repeated errors: pcscd[4902]: 00015802 winscard.c:286:SCardConnect() Error Reader Exclusive I would be happy with debugging information to figure out why gpg-agent doesn't use pcscd as intended. I have hit this bug after upgrading from Fedora 34 to 35. My GPG version (gnupg2-2.3.3-1.fc35.x86_64) should include the ccid driver change. I don't have ~/.gnupg/gpg-agent.conf. In case it's relevant, I also have pcsc-lite-ccid-1.4.36-2.fc35.x86_64 installed. GPG and pcscd are competing for exclusive access to the YubiKey (5 NFC). After the system is started GPG fails to obtain access to the device: $ gpg --card-status gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device After I stop pcscd.service GPG takes ownership of the card and can use it. pcscd.service gets reactivated by the socket but doesn't take back ownership, in the syslog I see repeated errors: pcscd[4902]: 00015802 winscard.c:286:SCardConnect() Error Reader Exclusive I would be happy with debugging information to figure out why gpg-agent doesn't use pcscd as intended.
Other related versions: opensc-0.22.0-1.fc35.x86_64 pcsc-lite-1.9.4-1.fc35.x86_64 [I'm sorry for duplicating the previous message]
You should try pcsc-shared option in the ~/.gnupg/scdaemon.conf
Thanks for the response Jakub. pcsc-shared didn't do the trick for me. I no longer get "Error Reader Exclusive" from pcscd.service and GPG reports a slightly different error: $ gpg --card-status gpg: OpenPGP card not available: Card error This happens when I launch Firefox for example (another client of pcscd via OpenSC if I'm not mistaken). Right after booting I could access the YubiKey via GPG without issues.
Do you use opensc or just the gnupg? If you do not need opensc, just remove it. The opensc card detection probably selects PIV applet and the gnupg's scdaemon can not recover from this state.
OpenSC has been the cause of my issue indeed. After removing the package I no longer have issues when accessing the YubiKey with GPG. pcsc-shared is no longer necessary and pcscd.service no longer reports errors related to exclusive access. Thanks a lot for your help Jakub! I didn't install opensc myself and didn't use it directly. There were no hard dependencies on the package either. I'm not sure if it was pulled in as a dependency or installed with the base system. The latter seems more likely as the system is fairly fresh, I didn't have a chance to install many packages yet. In that case the problem is likely to affect more users rather than just me. Was this not an issue in 34 because GPG didn't talk to pcsc and hence didn't conflict with OpenSC?
> Was this not an issue in 34 because GPG didn't talk to pcsc and hence didn't conflict with OpenSC? Probably. But it also meant that the first of scdeamon or pcsc what started talking to the USB device hold an exclusive access to it and the other was unnusable too. This was an issue for quite some time already.
After upgrading to 35: 1) Uninstalling opensc didn't help and was the first thing I tried. 2) Enabling/starting pcscd seems to fix things.
Wondering what happened there. pcscd should be enabled and started by default (unless you disabled it previously).
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.