KeePassXC startup interferes with YubiKey OpenPGP via PC/SC even when YubiKey is not configured for the database

[btomala]

Have you searched for an existing issue?

• Yes, I tried searching and reviewed the pinned issues

Brief Summary

Starting KeePassXC 2.7.12 on Fedora 44 interferes with GnuPG/scdaemon access to the OpenPGP application on a YubiKey 5C NFC (firmware 5.4.3).

The problem occurs immediately after starting KeePassXC, before opening any database. I do not use or configure YubiKey challenge-response for any KeePassXC database.

Before starting KeePassXC, gpg --card-status works normally. After starting KeePassXC, it fails with:

gpg: selecting card failed: Card error
gpg: OpenPGP card not available: Card error

scdaemon debug output at the failure contains:

DBG: PCSC_data: 00ca00c400
DBG: response: sw=6D00 datalen=0
DBG: chan_9 -> ERR 100663404 Card error <SCD>

Killing scdaemon immediately restores operation.

I confirmed that KeePassXC has a direct connection to pcscd. Most importantly, preventing KeePassXC from accessing /run/pcscd using bubblewrap completely prevents the problem:

bwrap --dev-bind / / --tmpfs /run/pcscd /usr/bin/keepassxc

With KeePassXC started this way, gpg --card-status continues to work normally.

This appears related to GnuPG T6218:
https://dev.gnupg.org/T6218

Possibly related KeePassXC issues:
#10077
#10710
#13205

Steps to Reproduce

1. Connect a YubiKey with the OpenPGP application configured.

2. Reset scdaemon:

   gpgconf --kill scdaemon
   

3. Verify that GnuPG can access the card:

   gpg --card-status
   

   This succeeds.

4. Start KeePassXC normally:

   /usr/bin/keepassxc
   

   It is not necessary to open a database.

5. Run:

   gpg --card-status
   

   It now fails with:

   gpg: selecting card failed: Card error
   gpg: OpenPGP card not available: Card error
   

6. Kill scdaemon:

   gpgconf --kill scdaemon
   

7. Run:

   gpg --card-status
   

   The card works again.

As an A/B test, repeat the procedure but start KeePassXC without access to the pcscd socket:

gpgconf --kill scdaemon
gpg --card-status

bwrap --dev-bind / / --tmpfs /run/pcscd /usr/bin/keepassxc

gpg --card-status

In this case gpg --card-status continues to work.

I have reproduced this behavior multiple times.

Expected Versus Actual Behavior

Expected behavior:

Starting KeePassXC, without opening a database and without having YubiKey challenge-response configured for a database, should not interfere with another application using the OpenPGP application on the YubiKey.

GnuPG/scdaemon should continue to be able to access the OpenPGP card after KeePassXC starts.

Actual behavior:

Simply starting KeePassXC is enough to trigger PC/SC activity involving the YubiKey.

After KeePassXC starts, an already-running GnuPG scdaemon can no longer communicate correctly with the OpenPGP application. The next operation fails with SW=6D00 and GnuPG reports "Card error".

Restarting scdaemon restores access to the card.

Preventing KeePassXC from accessing pcscd completely prevents the problem, which strongly indicates that KeePassXC's PC/SC access is the trigger.

KeePassXC Debug Information

Operating System

Linux

Linux Desktop Environment

Gnome

Linux Windowing System

Wayland

[btomala]

Additional GnuPG/scdaemon information:

GnuPG: 2.4.9
YubiKey: YubiKey 5C NFC
Firmware: 5.4.3

scdaemon.conf:

disable-application piv
card-timeout 300
disable-ccid
pcsc-shared

KeePassXC is directly linked against PC/SC:

libpcsclite.so.1 => /lib64/libpcsclite.so.1

During the failure, scdaemon reports:

DBG: PCSC_data: 00ca00c400
DBG: response: sw=6D00 datalen=0
DBG: chan_9 -> ERR 100663404 Card error <SCD>

[droidmonkey]

Two of the related issues you mentioned were caused by faulty udev rules. I cannot verify this issue nor can I offer any suggestions. Considering we are not doing anything exciting with PC/SC besides triggering when a card is connected/disconnected... I honestly think this is a bug in scdaemon. The fact that killing scdaemon fixes it leads me to that conclusion. We may just be a trigger point for their bug in this case.

Recommend a report over to them.