Description of problem: https://src.fedoraproject.org/rpms/gnupg2/c/1450ac3691930d70bdb97eed866023c31a51cec2?branch=rawhide This change effectively adds a dependency to pscs-lite-ccid The built-in ccid support is often good enough. Version-Release number of selected component (if applicable): gnupg2-2.3.2-2.fc36.x86_64 How reproducible: update This version also seems to introduce an issue with "pass" failing because it uses "--batch" option. Commenting out "--batch" in /usr/bin/pass addresses that issue.
Ignore that last part about pass --batch not working, that seems to have been always an issue with pass. nothing new, i just never noticed it
Just in case i am unclear: Please build gnug2 with ccid support if possible. that works fine for most gpg smart cards AFAIK (it works for me: nitrokey) and it allows one to use that smartcard without installing pcsc-lite-ccid. With this change you will have to install pcsc-lite-ccid if you use a gpg smartcard redardless whether gnupg would be able to support it without pcsc-lite-ccid. I really want to avoid having to have to install pcsc-lite-ccid and have that long running privileged pscsd daemon forced on me.
It doesn't work fine *with* pcsc-lite-ccid installed and running. If you aren't running pcsc-lite-ccid, then you can't share your tokens with other applications, so our standard setup is with pcscd and pcsc-lite-ccid. You probably want upstream to be able to autodectect pcsc-lite-ccid running and use it if it is running before it goes directly to the token. Then we could probably enable both, but right now only one works at a time, which means our default would be with the standard daemon running.
(In reply to dac.override from comment #2) > Just in case i am unclear: > > Please build gnug2 with ccid support if possible. that works fine for most > gpg smart cards AFAIK (it works for me: nitrokey) and it allows one to use > that smartcard without installing pcsc-lite-ccid. The issue is that when gpg's scdaemon takes over the USB device, nothing else in the system can access it. It works the other way round too. If pcscd tries to access the device first, then gpg's scdaemon can not access it. The pcscd is a middle-man through which both of the users can go and coexist. I do not know why gnupg decided to bundle the ccid driver. Regardless I want to use gpg or not (and gpg is part of the minimal os I think), neither of the use cases work out of the box (or it is random which is even worse). It is a smaller issue for nitrokey, but even larger issue for yubikeys having both piv and openpgp applets on them. I introduced this change based on the following bug, which also provides a workaround for the original problem: https://bugzilla.redhat.com/show_bug.cgi?id=2005714#c1 I think it would be best to provide the opposite switch for users like you to "enable-ccid", but I am not sure if this is implemented in gnupg right now. I will have to check. > With this change you will have to install pcsc-lite-ccid if you use a gpg > smartcard redardless whether gnupg would be able to support it without > pcsc-lite-ccid. Right. That is the case if you would need to use a smart card functionality of the gpg. Otherwise it should not be needed. It should be in recommends at least. > I really want to avoid having to have to install pcsc-lite-ccid and have > that long running privileged pscsd daemon forced on me. The pcscd is not started automatically. There is only the systemd socket and pcscd has --auto-exit feature which exits when unused for some time. It is also pretty small daemon with pretty limited functionality. It can be probably locked down even more, but I did not look into that. Its hard to accommodate all the different use cases out of the box which include: * the ones who want to use gpg with ccid * the ones who want to use gpg with pcscd * the ones who want to use pkcs11 interface of smart cards/tokens and their combinations.
FEDORA-2021-4bf2879524 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4bf2879524
FEDORA-2021-4bf2879524 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-4bf2879524` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4bf2879524 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-4bf2879524 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.