Bug 1941346

Summary: gnupg2 can't find YubiKey after 33 to 34 upgrade
Product: [Fedora] Fedora Reporter: David Zarzycki <dave>
Component: gnupg2Assignee: Red Hat Crypto Team <crypto-team>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: andrew, bcl, crypto-team, dave, jjelen, randy, tm
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-07 20:34:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Zarzycki 2021-03-21 18:59:43 UTC
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.

Comment 1 David Zarzycki 2021-03-22 11:34:37 UTC
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.

Comment 2 Jakub Jelen 2021-04-06 08:32:22 UTC
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

Comment 3 Jakub Jelen 2021-10-19 14:31:21 UTC
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

Comment 4 David Zarzycki 2021-11-01 10:57:14 UTC
I have a workaround and I won't be able to test Fedora 35 for a while now. Thanks for checking.

Comment 5 Andrew Barchuk 2021-11-08 21:46:02 UTC
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.

Comment 6 Andrew Barchuk 2021-11-08 21:51:23 UTC
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]

Comment 7 Jakub Jelen 2021-11-09 08:13:54 UTC
You should try pcsc-shared option in the ~/.gnupg/scdaemon.conf

Comment 8 Andrew Barchuk 2021-11-09 20:46:45 UTC
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.

Comment 9 Jakub Jelen 2021-11-10 12:08:23 UTC
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.

Comment 10 Andrew Barchuk 2021-11-10 21:32:26 UTC
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?

Comment 11 Jakub Jelen 2021-11-11 07:56:16 UTC
> 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.

Comment 12 David Zarzycki 2022-01-18 12:01:51 UTC
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.

Comment 13 Jakub Jelen 2022-01-24 13:36:14 UTC
Wondering what happened there. pcscd should be enabled and started by default (unless you disabled it previously).

Comment 14 Ben Cotton 2022-05-12 15:03:06 UTC
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.

Comment 15 Ben Cotton 2022-06-07 20:34:11 UTC
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.