Bug 1893131 - gpg + yubikey is broken in Fedora Silverblue
Summary: gpg + yubikey is broken in Fedora Silverblue
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: opensc
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1853347 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-30 09:51 UTC by Allison Karlitskaya
Modified: 2024-02-09 10:49 UTC (History)
29 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-25 16:54:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Allison Karlitskaya 2020-10-30 09:51:16 UTC
hi,

This is probably not a pcsc bug, but I'm not sure exactly where I should file it.  It's more of a system-integration level thing.

I upgraded my system from Fedora 32 Silverblue to Fedora 33 Silverblue today.  I use my yubikey to store GPG keys (which in turn I use as my SSH key).

From Fedora 32 Silverblue I had to overlay the pcsc-lite package, but after I did so, this command works fine:

  $ gpg --card-status

From Fedora 33, pcsc-lite is already installed, but the above command fails, saying it's unable to find any smartcards.

I did a bit of digging, and this is down to scdaemon getting a "sharing violation" error from pcscd.  Indeed, there are two processes connected to pcscd which were not connected to it in Fedora 32:  rngd (from rng-tools) and gsd-smartcard (from gnome-settings-daemon).

Killing rngd and gsd-smartcard allows me to use my yubikey again in Fedora 33 (ie: gpg --card-status is working).  These two processes were also running on Fedora 32, but didn't seem to be causing any problems there.  I don't know what changed.

Comment 1 Allison Karlitskaya 2020-10-30 12:42:03 UTC
I did some more investigation.  The thing that changed is that the package `opensc` is now installed by default.  It brings with it a pkcs11 module, and specifically, an entry in /usr/share/p11-kit/modules (opensc.module), which causes it to be found by gnome-settings-daemon and rngd.

In particular, on Fedora 33:

  $ p11-kit list

shows:

opensc: opensc-pkcs11.so
    library-description: OpenSC smartcard framework
    library-manufacturer: OpenSC Project
    library-version: 0.20
    token: OpenPGP card (User PIN)
        manufacturer: Yubico
        model: PKCS#15 emulated
        serial-number: 000611120611
        hardware-version: 3.4
        firmware-version: 3.4

whereas, I don't get this on Fedora 32.

Comment 2 Allison Karlitskaya 2020-10-30 13:39:22 UTC
Two possible workarounds:

 1: rpm-ostree override remove opensc

 2: or via configuration:

==> /etc/pkcs11/modules/opensc.module <==
disable-in: rngd gsd-smartcard

    but rngd hardcodes the opensc driver (./configure option), so you need to do this:

==> /etc/systemd/system/rngd.service.d/disable-pkcs11.conf <==
[Service]
ExecStart=
ExecStart=/sbin/rngd -xpkcs11 -f



Note: trying to write 'module:' to /etc/pkcs11/modules/opensc.module (as suggested by the pkcs11.conf manpage) will brick your system due to a p11-kit bug.  Anything using p11-kit will spin on startup (including systemd-resolved, preventing the system from booting).

Comment 3 Allison Karlitskaya 2020-10-30 13:40:44 UTC
A bit of background: I use a Yubikey Nano, which I leave permanently installed inside my USB port, so it's always present on startup.

Also: the above workarounds are obviously just workarounds.  We need to figure out a better way to allow p11-kit and scdaemon to coexist.

Comment 4 Jakub Jelen 2020-11-02 08:45:48 UTC
The root cause is the gpg's scdaemon insisting on the exclusive access to the scdaemon. There were some patches removing this from the scdaemon (probably one-liner, never upstreamed) or there is alternative scdaemon's using standard PKCS#11 [1], but I never managed to pursue either of the directions as I use my yubikey mostly for pkcs11 related stuff.

If you use your yubikey only for gpg, the easiest solution is really to remove opensc package.

[1] https://github.com/alonbl/gnupg-pkcs11-scd

Comment 5 DAKSH 2020-11-06 06:44:46 UTC
I have same issue after upgrading from F32 to F33 Unable to access yubikey.
I mainly use it for ssh login. 

gpg --card-edit --expert

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

Comment 6 info 2020-11-13 19:14:58 UTC
I am running Workstation not Silverblue, but the issue seems similar, if not identical.

I originally had Fedora 32, and all was well, but on upgrade to 33 this issue appeared. I can also confirm that a clean install of Fedora 33 has the same issue.

I should also note that this issue is only present if my Yubikey is inserted from when the computer is off. If I remove the Yubikey immediately after the login screen (I use the Yubikey to automatically fill the password field on the login screen) then the issue will not appear.

To get rid of the issue I have to restart pcscd:

sudo service pcscd restart

and then the issue will only return after a reboot.

Other info in case they are relevant:

My install is encrypted
My install is situated on an external bootable USB drive

If you need further info just ask.

Comment 7 Frederick Doe 2020-11-16 20:33:10 UTC
Yesterday I did a fresh install of Fedora 33 Workstation KDE. I was able to get my Yubikey 4 smartcard working with gpg2 by configuring this file
~/.gnupg/scdaemon.conf
to contain these lines:
pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid

and rebooting

Today I:
* Configured pam-u2f to require u2f for login, su, and sudo
* Installed firejail
* Uninstalled firejail

The Yubikey is no longer working with gpg2. gpg2 --card-status says that there is no smartcard attached.

I don't know if this is relevant or not, but launch Firefox with the Yubikey plugged in Firefox repeatedly asks me to unlock my PKCS#11 PIV card (which I don't think I've ever used)

Comment 8 Evan McClain 2020-11-22 03:35:12 UTC
It looks like pcsc-lite-libs doesn't include the symlink to libpcsclite.so, so I had to set `pcsc-driver /usr/lib64/libpcsclite.so.1` in my scdaemon.conf and that seems to work.

Comment 9 Michael Vorburger.ch 2020-11-22 19:28:02 UTC
Same problem here after upgrading a Fedora Workstation (not Silverblue) from 32 to 33. TL;DR:

> If you use your yubikey only for gpg, the easiest solution is really to remove opensc package.

    sudo dnf remove opensc

Confirming #c4 that ^^^ this (and then rebooting) indeed did the trick for me; all fine again now. Qs: What does opensc (from https://github.com/OpenSC/OpenSC, presumably?) do for us? Why was it added in Fedora 33? What are we losing if we manually uninstall the package (at its current version 0.20.0-7.fc33) after upgrading from 32 to 33? Everything I currently use it for still seems to work...

echo "pcsc-driver /usr/lib64/libpcsclite.so.1" >>~/.gnupg/scdaemon.conf from #c7 #c8 did not seem to do the trick (for me; YMMV).

sudo killall rngd gsd-smartcard (from #c0), and then plugging the YK out and plugging it back into the USB port, also did the trick, but of course isn’t permanent. Some further observations, just for the record:

[user@fedora32~]$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.23
    token: (...)

[user@fedora33~]$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.23
    token: (...)
opensc: opensc-pkcs11.so
    library-description: OpenSC smartcard framework
    library-manufacturer: OpenSC Project
    library-version: 0.20
    token: (...)

Note I had to use “p11-kit list-modules” instead of “p11-kit”, probably just a typo.


[user@fedora32~]$ systemctl status rngd
Initializing available sources
[hwrng ]: Initialized
[rdrand]: Enabling RDSEED rng support
[rdrand]: Initialized
[jitter]: Initializing AES buffer
[jitter]: Unable to obtain AES key, disabling AES in JITTER source
[jitter]: Enabling JITTER rng support
[jitter]: Initialized
[pkcs11]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory
[pkcs11]: Initialization Failed


[user@fedora33~]$ systemctl status rngd
(...)
[jitter]: Enabling JITTER rng support
[jitter]: Initialized
[pkcs11]: Slot manufacturer......: Yubico
[pkcs11]: Slot description.......: Yubico YubiKey FIDO+CCID 00 00
[pkcs11]: Slot token label.......: OpenPGP card (User PIN)
[pkcs11]: Slot token manufacturer: Yubico
[pkcs11]: Slot token model.......: PKCS#15 emulated
[pkcs11]: Slot token serial......: (...)
[pkcs11]: Initialized
[rtlsdr]: Initialization Failed


[user@fedora32~]$ systemctl status pcscd
systemd[1]: Started PC/SC Smart Card Daemon.
pcscd[36372]: 00000000 ifdhandler.c:150:CreateChannelByNameOrChannel() failed
pcscd[36372]: 00000051 readerfactory.c:1105:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0406:libudev:0:/dev/bus/usb/001/010)
pcscd[36372]: 00000002 readerfactory.c:376:RFAddReader() Yubico YubiKey FIDO+CCID init failed.

Same as this ^^^ on @fedora33 after uninstalling opensc (hadn't tried before).

Comment 10 DAKSH 2020-11-27 23:15:37 UTC
It has become pain in butt, I have to restart pcscd every half an hour or so. Everytime I shutdown or reboot, I have to restart pcscd.

Comment 11 Casey 2020-12-23 07:53:57 UTC
This isn't just a yubikey issue. I'm experiencing the same with my Nitrokey smartcard on Silverblue 33 and Fedora 33 toolbox containers.

Comment 12 Allison Karlitskaya 2021-09-24 09:09:46 UTC
For what it's worth, I have a reasonable workaround for at least my usecase (since I don't actually care about GPG anymore): using the PIV mode of the Yubikey directly for my SSH key.  That's working lovely, modulo Bug 1949436 (which is much easier to work around).

Comment 13 Ben Cotton 2021-11-04 13:42:31 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 14 Ben Cotton 2021-11-04 14:12:02 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Ben Cotton 2021-11-04 15:09:34 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Casey 2021-11-04 15:15:31 UTC
FWIW this issue was present in Fedora Silverblue 34 (upgraded from 33, and also it is still present in a fresh Silverblue 35 install.

To make gpg smartcards work one must always `sudo systemctl restart pcscd` every so often.

Can we change the version of this ticket?

Comment 17 Jakub Jelen 2021-11-05 08:55:34 UTC
Fedora 35 gnupg should already have disabled internal ccid driver. If you need to use yubikey for both (PIV) smart card functionality and gpg, you should add shared-access to your .gnupg/scdaemon.conf so it will not explode on the requirement for exclusive access to the device.

Comment 18 Bob Relyea 2021-11-10 17:37:29 UTC
*** Bug 1853347 has been marked as a duplicate of this bug. ***

Comment 19 Viktor 2022-01-16 16:01:56 UTC
(In reply to Jakub Jelen from comment #17)
> Fedora 35 gnupg should already have disabled internal ccid driver. If you
> need to use yubikey for both (PIV) smart card functionality and gpg, you
> should add shared-access to your .gnupg/scdaemon.conf so it will not explode
> on the requirement for exclusive access to the device.
For anyone arriving here having this problem on F35 WS (I have it using a Yubikey 5 NFC) "shared-access" is not a scdaemon option, instead use pcsc-shared in the same file. No other solutions that could be found through google (posted here: https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html for example) worked for me.

Comment 20 Tobias Florek 2022-02-16 10:28:22 UTC
I can't get it to work on Silverblue 35.

With `.gnupg/scdaemon.conf` as in

```
log-file /tmp/scdaemon.log
debug-level guru
debug-ccid-driver
disable-ccid
pcsc-shared
pcsc-driver /usr/lib64/libpcsclite.so.1
```

I get
```
2022-02-16 10:12:20 scdaemon[203447] pcsc_establish_context failed: no service (0x8010001d)
```

Interestingly `pcscd.service` does not get started.  Manually starting it does not do much, because it's configured to stop automatically.  The `pcscd.socket` unit is active.

Comment 21 aaron 2022-02-21 20:40:02 UTC
I just ran into this same problem after upgrading to Fedora 35. After some time, I realized that `gpg --card-status` worked fine if I was root - but would hang indefinitely as a normal user. After about an hour trying all of the standard Google suggestions of editing scdaemon.conf, adding concurrent options, etc. I also tried someones suggestion of adding a udev rule but was not successful. I finally stumbled across this page: https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. Adding the file https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules to the udev rules and rebooting fixed the issue.

Hope this saves someone an hour!

Comment 22 Joe Doss 2022-06-15 06:33:40 UTC
Ahhh! I just had to fight Yubikey + GPG + pcscd + scdaemon for over an hour. I was getting this:

$ gpg --card-status
gpg: selecting card failed: Service is not running
gpg: OpenPGP card not available: Service is not running

and I got got some odd NOT authorized on pcscd:

Jun 15 00:20:41 sw-0608 systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon.
Jun 15 00:20:41 sw-0608 pcscd[873786]: 00000000 auth.c:137:IsClientAuthorized() Process 872679 (user: 1000) is NOT authorized for action: access_pcsc
Jun 15 00:20:41 sw-0608 pcscd[873786]: 00000073 winscard_svc.c:335:ContextThread() Rejected unauthorized PC/SC client
Jun 15 00:21:42 sw-0608 systemd[1]: pcscd.service: Deactivated successfully.

Which lead me to find https://github.com/Yubico/libfido2/blob/main/udev/70-u2f.rules (the link that aaron from comment #21 posted is in an old archived repo). I installed those udev rules and rebooted. Then I ended up with 

$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

and then after futzing around with the ~/.gnupg/scdaemon.conf file I ended up back with
disable-ccid
pcsc-shared
pcsc-driver /usr/lib64/libpcsclite.so.1

which were the options I had commented out last week and things worked fine. Anyways, after running 

gpgconf --kill gpg-agent
gpg-connect-agent reloadagent /bye

and I am back in business with my Yubikey 5 NFC. Whatever changed in Fedora 33 w/r/t Yubikey + GPG + pcscd + scdaemon has been super frustrating. I pretty much lose an hour or two every 4 months to something related to this. Ugg!

I hope this helps someone or my future self when I run into issues again.

Comment 24 Dan O. 2022-11-03 17:28:14 UTC
This still affects Fedora 36 (not Silverblue). No combination of settings in ~/.gnupg/scdaemon.conf really stuck. gpg --card-status would work fine, then a minute later it'd give me a card error. The timing and relation to my activity on the computer seemed totally unrelated to anything, it would just break randomly.

The best I can tell from just a guess is that Firefox will use opensc, which then creates an exclusive lock on the card (may not be accurate). GnuPG can then no longer read from the card until pcscd is restarted, or the card is removed or inserted.

Since I'm using the card's PIV primarily in gpg mode, I just uninstalled opensc and restarted the computer and now gnupg consistently works. I don't like this resolution though since it disables functionality. Maybe there is something that can be set in /etc/opensc.conf, but I got tired of trying various setting combinations out.

Comment 25 Dan O. 2022-11-04 15:20:08 UTC
I finally got a consistent solution that doesn't remove any functionality: completely ditch opensc and replace it with Scute from GnuPG (https://gnupg.org/software/scute/index.html). Fedora doesn't package this, so it has to be installed from source. You'll probably also want to create a p11-kit module that uses it so that desktop applications can access your yubikey certificate store, which can be done by adding a /etc/pkcs11/modules/scute.module conf just containing 'module: /usr/local/lib/scute.so'. You can check out the p11-kit docs for additional settings you can use in the .module file.

I don't know how installing from source works in Silverblue, but it would be great if Fedora packaged Scute as an alternative to OpenSC for situations where you want to use a smart card with both GPG and other generic smart card usage.

Comment 26 Ben Cotton 2022-11-29 16:50:00 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
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 '35'.

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 35 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 27 kxra 2023-04-18 17:36:35 UTC
Not sure if this covers your use case, but it seems related and others may end up here from Google for a workaround: https://github.com/containers/toolbox/issues/568#issuecomment-1513554674

Comment 28 Ben Cotton 2023-04-25 16:40:57 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
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 '36'.

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. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 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 29 Ludek Smid 2023-05-25 16:54:35 UTC
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 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 Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 30 Krzysztof Raczkowski 2023-06-06 18:06:19 UTC
This bug is still active on Fedora 38. It should be re-opened.

Comment 31 Stephen Gallagher 2023-06-06 19:11:41 UTC
I can also confirm that the issue remains present on Fedora 38.

Note also that a non-ideal workaround exists: You can remove the `opensc` package from Silverblue et. al. and it will no longer conflict with pcsc-lite. Of course, this disables opensc-specific capabilities.

Comment 32 Krzysztof Raczkowski 2023-06-06 19:41:24 UTC
(In reply to Stephen Gallagher from comment #31)
> I can also confirm that the issue remains present on Fedora 38.
> 
> Note also that a non-ideal workaround exists: You can remove the `opensc`
> package from Silverblue et. al. and it will no longer conflict with
> pcsc-lite. Of course, this disables opensc-specific capabilities.

I removed opensc package to get yubikey working with gnupg. I need it for SSH key which I can also use on Android devices. But opensc is necessery to use S/MIME certificates in Thunderbird and Firefox. I would like to use it in the near future :-/
So, a workaround is not a solution of the problem. It's a temporary workaround.

Comment 33 Dan O. 2023-06-06 20:45:08 UTC
I mentioned earlier in this bug report (comment 25) that one could use 'scute' instead of opensc. I've been going this route since I made that post and it works great for allowing S/MIME access in Thunderbird and Firefox. Fedora still doesn't package scute though, so you have to get the source and compile it yourself. At least it's a workaround that seems to meet all needs.

Comment 34 Krzysztof Raczkowski 2023-06-07 06:43:47 UTC
(In reply to Dan O. from comment #33)
> I mentioned earlier in this bug report (comment 25) that one could use
> 'scute' instead of opensc. I've been going this route since I made that post
> and it works great for allowing S/MIME access in Thunderbird and Firefox.
> Fedora still doesn't package scute though, so you have to get the source and
> compile it yourself. At least it's a workaround that seems to meet all needs.

I've tried to switch to scute but with no success. Here's the steps I made:
1) removed opensc package
2) compiled scute library in podman environment
3) moved scute.so to my system to /usr/lib64
4) created /etc/pkcs11/modules/scute.module with the content: module: scute.so

But it didn't work. When I opened Firefox settings, I couldn't find my Yubikey. It was there with opensc installed.
What did I wrong?

If I get it working, there's no problem for me to create spec file to build rpm package.

Comment 35 Dan O. 2023-06-07 13:30:57 UTC
Mm, I wonder what the difference could be. I don't think my setup must be too different from yours.

When I open Firefox and go to Settings -> Security -> (Click "Security Devices..." button), under Security Modules and Devices I have a top-level entry called p11-kit-proxy. Under p11-kit-proxy I have a device called 'GnuPG Smart Card Daemon'. I take note of the 'Label' field in that screen. Going to 'View Certificates', I see several stored certificates under the 'Your Certificates' tab, the data in column 'Security Device' matches the 'GnuPG Smart Card Daemon' Label.

It seems unlikely, but are you missing the 'p11-kit-proxy' security module? I may have had to add that module directly by clicking 'Load' and finding 'p11-kit-proxy.so'. When I was working through this a while ago, I know I loaded and unloaded several modules by hand, trying things out, so I can't remember if this is there by default.

Comment 36 Dan O. 2023-06-07 13:33:22 UTC
Interestingly enough, even though the security device is called 'GnuPG Smart Card Daemon' and the manufacturer is listed as 'scdaemon', you can somewhat tell that this is being provided through scute: The FW Version is listed as 1.7 (my installed version of scute) and HW version is listed at 2.4 (my installed version of gpg)

Comment 37 Dan O. 2023-06-07 14:08:38 UTC
$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.24
    token: System Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.24
        flags:
               write-protected
               token-initialized
    token: Default Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.24
        flags:
               write-protected
               token-initialized
scute: /usr/local/lib/scute.so
    library-description: Cryptoki for GnuPG
    library-manufacturer: g10 Code GmbH
    library-version: 1.0

Comment 38 Krzysztof Raczkowski 2023-06-07 17:18:30 UTC
Second approach and scute works!!
I've changed two things:

4) created /etc/pkcs11/modules/scute.module with the content: module: /usr/lib64/scute.so
(full path)
5) sudo chown root: /usr/lib64/scute.so; sudo chcon -u system_u -t lib_t /usr/lib64/scute.so

Thanks Dan.O for your support!

Comment 39 Krzysztof Raczkowski 2023-06-28 16:10:50 UTC
Bump

Installing scute isn't the perfect solution. It works, but my logs are every second spammed with these messages:

Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:49 piglet firefox.desktop[10512]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:50 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:50 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:51 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:51 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)
Jun 28 18:07:52 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194: gpg-agent command 'SCD SERIALNO --all' failed: No such device
Jun 28 18:07:52 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers failed: no readers available (0x8010002e)


Any suggestions, how to fix it?

Comment 40 Beto Hydroxy Butyrate 2023-07-06 01:45:01 UTC
Broken for me also.
I am on SilverBlue, for less than a week so far.
Initially, it worked.
Then I rebooted, maybe did a few `rpm-ostree upgrade`s, and now it does not work.
I am not keen to try the `scute` approach, as it goes against the SilverBlue approach, I think.

`pass` fails.  It just opens `pinentry` and I am prompted to insert the YubiKey I have inserted.
 
```
toolbox% gpg-connect-agent              
> SCD SERIALNO --all
ERR 100663614 Service is not running <SCD>
```

```code
$ rpm-ostree status -v
State: idle
AutomaticUpdates: disabled
Deployments:
● fedora:fedora/38/x86_64/sericea (index: 0)
                  Version: 38.20230705.0 (2023-07-05T00:44:27Z)
                   Commit: fc15abf986d93720c2ba0f62f13a341c87bc097335c94750a3752fc8f05e06ca
                           ├─ repo-0 (2023-04-14T09:32:40Z)
                           ├─ repo-1 (2023-07-05T00:16:53Z)
                           └─ repo-2 (2023-07-05T00:19:08Z)
                   Staged: no
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Wed 05 Jul 2023 10:44:35 using RSA key ID 809A8D7CEB10B464
                           Good signature from "Fedora <fedora-38-primary>"

  fedora:fedora/38/x86_64/sericea (index: 1)
                  Version: 38.20230705.0 (2023-07-05T00:44:27Z)
                   Commit: fc15abf986d93720c2ba0f62f13a341c87bc097335c94750a3752fc8f05e06ca
                           ├─ repo-0 (2023-04-14T09:32:40Z)
                           ├─ repo-1 (2023-07-05T00:16:53Z)
                           └─ repo-2 (2023-07-05T00:19:08Z)
                StateRoot: fedora
             GPGSignature: 1 signature
                           Signature made Wed 05 Jul 2023 10:44:35 using RSA key ID 809A8D7CEB10B464
                           Good signature from "Fedora <fedora-38-primary>"
```

```random-shell-interactions
$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
    library-description: PKCS#11 Kit Trust Module
    library-manufacturer: PKCS#11 Kit
    library-version: 0.24
    token: System Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.24
        flags:
               write-protected
               token-initialized
    token: Default Trust
        manufacturer: PKCS#11 Kit
        model: p11-kit-trust
        serial-number: 1
        hardware-version: 0.24
        flags:
               write-protected
               token-initialized
opensc: opensc-pkcs11.so
    library-description: OpenSC smartcard framework
    library-manufacturer: OpenSC Project
    library-version: 0.23
```

Comment 41 Dan O. 2023-07-06 17:09:05 UTC
(In reply to Krzysztof Raczkowski from comment #39)
> Bump
> 
> Installing scute isn't the perfect solution. It works, but my logs are every
> second spammed with these messages:
> 
> Jun 28 18:07:49 piglet gpg-agent[3296]: scdaemon[3296]: pcsc_list_readers
> failed: no readers available (0x8010002e)
> Jun 28 18:07:49 piglet gsd-smartcard[3685]: scute: agent_simple_cmd:194:
> *** SNIP ***
> 
> 
> Any suggestions, how to fix it?

Odd, I haven't seen those errors before, but it looks like something is using the yubikey exclusively. I wonder if it has to do with gnupg settings?

.gnupg/scdaemon.conf:
disable-ccid

.gnupg/gpg-agent.conf:
enable-ssh-support
default-cache-ttl 60
max-cache-ttl 120
pinentry-program /usr/bin/pinentry-gnome3

None of those look like they'd influence that though. I'm not sure, sorry.

Beto: It looks as though your rpm-ostree upgrade removed scute from your system, as p11-kit is reporting that you have opensc instead of scute now. I'm not really familiar with how Silverblue allows for out-of-tree installations.

Comment 42 Krzysztof Raczkowski 2023-07-06 17:48:26 UTC
My mistake as I haven't noticed that this bug is opened for Silverblue. I use Fedora Workstation 38 but I think, the problem here is independent.

It's not that something is using the yubikey as I've got this on the system which has never seen yubikey yet:

lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)
lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)
lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)
lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)
lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)
lip 06 19:32:57 pooh gpg-agent[4885]: scdaemon[4885]: pcsc_list_readers failed: no readers available (0x8010002e)

It's from my second workstation named pooh. It's configured the same way as my first workstation (piglet) but at the moment I'm using my yubikey only on piglet.


I've managed to workaround these errors in log with these steps:

1) I've patched scute and changed log level from  DBG_CRIT to DBG_INFO in one place:
diff -uNr scute-1.7.0.orig/src/agent.c scute-1.7.0/src/agent.c
--- scute-1.7.0.orig/src/agent.c	2020-11-24 15:10:59.000000000 +0100
+++ scute-1.7.0/src/agent.c	2023-06-28 18:27:36.160268002 +0200
@@ -191,7 +191,7 @@
   err = assuan_transact (ctx, optstr, NULL, NULL, default_inq_cb,
 			NULL, NULL, NULL);
   if (err)
-    DEBUG (DBG_CRIT, "gpg-agent command '%s' failed: %s", optstr,
+    DEBUG (DBG_INFO, "gpg-agent command '%s' failed: %s", optstr,
 	  gpg_strerror (err));
   free (optstr);

2) I've changed logging configuration of scdaemon (last line):
# ~/.gnupg/scdaemon.conf
disable-ccid
reader-port Yubico Yubi
quiet
log-file /dev/null

3) I've changed logging configuration of pcscd daemon:
# /etc/default/pcscd
PCSCD_ARGS="--critical"

and restarted the daemone: sudo systemctl restart pcscd

Comment 43 Beto Hydroxy Butyrate 2023-07-20 09:03:07 UTC
(In reply to Dan O. from comment #41)

> Beto: It looks as though your rpm-ostree upgrade removed scute from your
> system, as p11-kit is reporting that you have opensc instead of scute now.
> I'm not really familiar with how Silverblue allows for out-of-tree
> installations.

Took a two week break from SilverBlue, hoping for a fix to trickle down.  Just did `rpm-ostree update` and rebooted.
Works again.  Not sure what changed.  I still have opensc.

Comment 44 Beto Hydroxy Butyrate 2023-07-31 06:32:19 UTC
Did another `rpm-ostree update; reboot` and again, stopped working.
Per the goog: 
```
gpgconf --kill gpg-agent
gpg-connect-agent updatestartuptty /bye
```

That fixed it.  No idea whats going on.  I was getting lots of 
```
apdu_open_reader: failed to open driver '/usr/lib64/libpcsclite.so.1': /usr/lib64/libpcsclite.so.1: cannot open shared object file: No such file or directory
```

Now that it works again, I find the unlock does not stick.  I have to unlock it for every `pass -c xxx` operation.

That significantly reduces usability.


Note You need to log in before you can comment on or make changes to this bug.