gnupg-2.3: scdaemon disables PC/SC fallback if CCID is enabled, breaks smartcards

[lemmi]

Is this a new report?

Yes

System Info

Void 5.15.52_1 x86_64 AuthenticAMD uptodate hold rrrmFFFFFFFFFFFFFFF

Package(s) Affected

gnupg-2.3.7_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

https://dev.gnupg.org/T5409#145581

Expected behaviour

Current setups that (need) to use pcscd for smartcard access (like yubikeys) should work.

Actual behaviour

scdaemon disabled the fallback to the PC/SC driver when the internal CCID driver is used.

Solutions I can see so far:

1. Users need to echo disable-ccid >> ~/.gnupg/scdaemon.conf
2. Build gnupg with --disable-ccid-driver
3. gnupg package ships udev rules that allow users to access the smartcard with the internal CCID and users disable pcscd

Apparently debian ships udev rules, though I have not tested them.

\\ noted:
just as a note those udev rules should probably target both the plugdev group and the uaccess tag (for elogind)

Tough I can confirm that manually changing the permissions on the usb device and disabling pcscd works.

I think we should prefer 3 over 2 over 1.

Steps to reproduce

1. have pcscd running to access smartcards
2. updage gnupg
3. gpgconf --kill all
4. gpg --card-status

   gpg: selecting card failed: No such device
   gpg: OpenPGP card not available: No such device
   

@jcgruenhage

[jcgruenhage]

Thanks for the report. I'll be packaging up the udev rules later and look into why this didn't break for me with my yubikey.

[0x5c]

The problem is much worse than it seems at first. The internal CCID driver is not what's new; it's quite old and there's traces of it breaking pcscd all over the web from before gnupg 2.3 (2021-04-07). Here's some bug reports and blog posts from 2019;

• Yubikey 5 only initialized properly after restarting pcscd LudovicRousseau/PCSC#65
• https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925312

What's new is that gnupg 2.3 dropped the automatic fallback to pcscd when the internal driver fails (https://dev.gnupg.org/T4673). That fallback was what we all used since void and (most) distros never shipped any udev rules that would allow the built-in driver to work.

I think that option 1 would be fine, but would imo require at minimum a README.void file.

But it's unclear to me if option 3 is realistic at all, seeing how there's no official or otherwise recognised set of udev rules, and the Debian ones are so barebones that they don't even include any Yubico devices from after the Yubikey 4, like my Yubikey 5. We'd have to maintain a set of rules and that seems like a major task.
I'd say option 2 might be best.

Regarding my previous comment on plugdev/uaccess, it seems it might not be relevant since rules like the ones Debian ships appear to use a completely different permission mechanism that I don't quite comprehend. Maybe it's some weirder logind stuff that might not work here, or Debian-specific things.

[jcgruenhage]

@0x5c I think the situation isn't as bad as you make it out to be: I'm running GnuPG 2.3.7 on Void, and I'm using a Yubikey 5 without any of those workarounds just fine. I think what masked this issue for me is having ykpers installed, which ships udev rules for current yubikeys as well. My current plan for now would be:

• split out the yubikey udev rules from ykpers into a separate package, add dependency on that to gnupg. This should be good enough for most users, and it's an easy enough fix that I can push out today.
• investigate the situation with the Debian udev rules. From the thread linked above, it seems like NixOS had success with using those udev rules, and I'll investigate how other distros (especially Fedora and it's derivates) are handing this. I'd assume that we can package some set of udev rules to make this just work for nearly everybody.
• I'll add some documentation for this on docs.voidlinux.org, if there's anything still left to do for users, but I kinda doubt it.

[lemmi]

Quick update:
I might have just screwed up and forgot to disable pcscd while trying the internal CCID driver. pcscd was blocking the card, so obviously scdaemon couldn't access it.
Still, this issue needs user intervention. Either they need to stop using pcscd or disable the gnupg CCID driver.

[0x5c]

NixOS does not appear to be using those rules, at least not in the gnupg package https://github.com/NixOS/nixpkgs/tree/master/pkgs%2Ftools%2Fsecurity%2Fgnupg

EDIT: found the actual package they plonked the rules in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/hardware/gpgsmartcards.nix

[0x5c]

Still, this issue needs user intervention. Either they need to stop using pcscd or disable the gnupg CCID driver.

From what I understand pcscd has to not be running, is that right? In that case it remains a problem for anyone who has to use pcsc for other reasons

I also suspect that the rules debian ships depend on logind

[lemmi]

To be clear, I did not add any 3rd party udev rules. I just tried again with pcscd disabled. In terms of udev rules, it's just a matter of identifying what other package ships the correct rules.

From what I understand pcscd has to not be running, is that right? In that case it remains a problem for anyone who has to use pcsc for other reasons

They can disable the CCID driver.

Either way this probably warrants a install message as @jcgruenhage suggested, possibly linking to the updated documentation.

[jcgruenhage]

Right, the people using pcscd need to set ccid to disabled in the scdaemon config.