Package: gnupg
Version: 2.4.7-14
Severity: normal

Dear Maintainer,

I upgraded gnupg from 2.2.46-6 to 2.4.7-13 and all operations with a hardware security module (Yubikey 5) now fail.

It may be that there is a user configuration or dependency change that needs satisfying but I can't find any documentation to that effect:

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

Other tools such as yubioath-desktop and ykman can interact with the device fine:

$ ykman list
YubiKey 5 NFC (5.2.7) [OTP+FIDO+CCID] Serial:

Other packages:

ii pcscd 2.3.3-1 amd64 Middleware to access a smart card using PC/SC (daemon side)
ii scdaemon 2.4.7-14 amd64 GNU privacy guard - smart card support

Running processes:

root 2143 0.0 0.0 487728 8232 ? Sl 10:24 0:00 /usr/sbin/pcscd
andy 4308 0.0 0.0 164448 4320 ? SLl 10:25 0:00 scdaemon --multi-server
root 4334 0.0 0.0 164448 4256 ? SLl 10:25 0:00 scdaemon --multi-server

Although other aspects of gnupg may operate fine, for me this is a serious issue and I will need to downgrade to the previous upstream release in order to continue operating as a Debian contributor because my private key resides on my HSM!

I appreciate that there has been a lot of work behind getting this new upstream release into Debian so thank you and I hope this bug report helps. Let me know if you need anything else from me.

Andrew


-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.19-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gnupg depends on:
ii dirmngr 2.4.7-14
ii gnupg-l10n 2.4.7-14
ii gpg 2.4.7-14
ii gpg-agent 2.4.7-14
ii gpgsm 2.4.7-14

Versions of packages gnupg recommends:
ii gnupg-utils 2.4.7-14
ii gpg-wks-client 2.4.7-14
ii gpgv 2.4.7-14

Versions of packages gnupg suggests:
pn gpg-wks-server <none>
pn parcimonie <none>
pn xloadimage <none>

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-12 Andrew Bower <andrew@bower.uk> wrote:

Package: gnupg
Version: 2.4.7-14
Severity: normal

I upgraded gnupg from 2.2.46-6 to 2.4.7-13 and all operations with a hardware security module (Yubikey 5) now fail.

It may be that there is a user configuration or dependency change that needs satisfying but I can't find any documentation to that effect:

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

Other tools such as yubioath-desktop and ykman can interact with the device fine:

$ ykman list
YubiKey 5 NFC (5.2.7) [OTP+FIDO+CCID] Serial:

Other packages:

ii pcscd 2.3.3-1 amd64 Middleware to access a smart card using PC/SC (daemon side)
ii scdaemon 2.4.7-14 amd64 GNU privacy guard - smart card support

Running processes:

root 2143 0.0 0.0 487728 8232 ? Sl 10:24 0:00 /usr/sbin/pcscd
andy 4308 0.0 0.0 164448 4320 ? SLl 10:25 0:00 scdaemon --multi-server
root 4334 0.0 0.0 164448 4256 ? SLl 10:25 0:00 scdaemon --multi-server

Although other aspects of gnupg may operate fine, for me this is a
serious issue and I will need to downgrade to the previous upstream
release in order to continue operating as a Debian contributor because
my private key resides on my HSM!

I appreciate that there has been a lot of work behind getting this new upstream release into Debian so thank you and I hope this bug report
helps. Let me know if you need anything else from me.

Hello Andrew,

afaiui with gnupg 2.4 you have to either use gnupg's built-in ccid driver *instead* of pcdsd (i.e. stop pcscd from grabbing the device) or
configure gnupg to *not* use the built-in ccid driver:
scdaemon.1:
--disable-ccid
The integrated CCID driver for CCID compliant devices can be
available when libusb was detected at build time, and it is used
to access the smartcard reader. If access via PC/SC driver is
needed, please configure this option to disable CCID driver sup‐
port (if any). In GnuPG 2.2, there was a fallback mechanism from
CCID driver to PC/SC driver. The fallback mechanism worked, be‐
cause scdaemon in GnuPG 2.2 only supported a single token/reader.
To support of multiple tokens/readers at the same time, fallback
mechanism was removed.

(This would be disable-ccid in ~/.gnupg/scdaemon.conf.)

Over at Ubuntu LP https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/2061708 Julian Andres Klode recommends to choose the built-in ccid driver.

Yubikey otoh suggests pcdsd https://support.yubico.com/hc/en-us/articles/4819584884124-Resolving-GPG-s-CCID-conflicts

Archlinux has a little bit of info here: https://wiki.archlinux.org/title/GnuPG#Smartcards

cu Andreas

https://dev.gnupg.org/T6871

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Andreas,

On Sat, Apr 12, 2025 at 01:43:47PM +0200, Andreas Metzler wrote:

On 2025-04-12 Andrew Bower <andrew@bower.uk> wrote:
afaiui with gnupg 2.4 you have to either use gnupg's built-in ccid driver *instead* of pcdsd (i.e. stop pcscd from grabbing the device) or
configure gnupg to *not* use the built-in ccid driver:
scdaemon.1:
--disable-ccid
The integrated CCID driver for CCID compliant devices can be
available when libusb was detected at build time, and it is used
to access the smartcard reader. If access via PC/SC driver is
needed, please configure this option to disable CCID driver sup‐
port (if any). In GnuPG 2.2, there was a fallback mechanism from
CCID driver to PC/SC driver. The fallback mechanism worked, be‐
cause scdaemon in GnuPG 2.2 only supported a single token/reader.
To support of multiple tokens/readers at the same time, fallback
mechanism was removed.

(This would be disable-ccid in ~/.gnupg/scdaemon.conf.)

Thank you, this works!

I'm happy for this to be resolved as an invalid bug but would it be
worth extending the NEWS entry to cover this issue?

--
Signing with gnupg/2.4.7-14 and a hardware security module :-)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEMKYZL6LI55lncG11uqgO2W94h+kFAmf6V44ACgkQuqgO2W94 h+mmtRAAkI2HumyM0YrcKEalrX0GV+SgQYaEjD6kWahWxNjCNGTQy0KdvDmfgiaD lHtLDCzRMncU1qXE5UWQSbL0JEUB2Fxj6MoMq0n0A2kEqgiCmknN0h8nZLQx2qlY TlWpSVro2k+omniiOP9Ts4HyoHNRsI2aIHU/GO2K5IYFhZdFs80JZeh+Jxjm22yb V1ld/Grrd6hbwLHGarc8Xj9fCVXVWDvLS5+1aBWxI/+GYrPO2gPvcfbGgR/1thVs pcIETs0IThGG3wLBUhslmzEyEs6Occ05MVU/3mK9cb4cnwJTn4OIwmLTmDxmumpY C5QSHNkEqKhLAYrL+i+LIYzNTMEhuRNMtjTb1UpiPHzkWxNkRffdtyyWUaxI/h+a eExIN96hKwXzKSX1NgHddv21e57ebmto19tz7pmwgWEFXlhRcwteejrPdCoiAKVW OSC3QdBy5g5MLPpbjpzpxPlW9KyV2rGkqUahQW3H6fj5w2ox4EBBgd92d44iYK80 RUWduhNUlG5DJxlzOYsWy7fbkC8m3fkVRPLqZpchdz/vUuZ+UuUbGDyuTX9FqyUx 5XBVQqz4yxwP157kBHqsqtJ5Dkfou/3thjh+4faNtqHSebTuQp7JP3eHLu8b4Ziz CX1yE04uZHd/dp3h9dP0y5GdBpNLcl7kQtgf+gfpyJzYnGBqcI4=
=TVGi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-12 Andrew Bower <andrew@bower.uk> wrote:

Hi Andreas,

On Sat, Apr 12, 2025 at 01:43:47PM +0200, Andreas Metzler wrote:

On 2025-04-12 Andrew Bower <andrew@bower.uk> wrote:
afaiui with gnupg 2.4 you have to either use gnupg's built-in ccid driver *instead* of pcdsd (i.e. stop pcscd from grabbing the device) or
configure gnupg to *not* use the built-in ccid driver:
scdaemon.1:
--disable-ccid
The integrated CCID driver for CCID compliant devices can be
available when libusb was detected at build time, and it is used
to access the smartcard reader. If access via PC/SC driver is
needed, please configure this option to disable CCID driver sup‐
port (if any). In GnuPG 2.2, there was a fallback mechanism from
CCID driver to PC/SC driver. The fallback mechanism worked, be‐
cause scdaemon in GnuPG 2.2 only supported a single token/reader.
To support of multiple tokens/readers at the same time, fallback
mechanism was removed.

(This would be disable-ccid in ~/.gnupg/scdaemon.conf.)

Thank you, this works!

Thanks for the quick response.

I'm happy for this to be resolved as an invalid bug but would it be
worth extending the NEWS entry to cover this issue?

yes, definitely.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)