Would have preferred to use mailing list but for some it only bounces. Anyway …
As I played around with my new YubiKey I noticed: Even when using disable-ccid in scdaemon.conf gpg keeps a lock on the key until I force it by gpg-card > reset > quit. Trying to use ykman directly causes an error in pcscd: Sep 29 23:55:19 main systemd[1]: Started PC/SC Smart Card Daemon. Sep 29 23:55:23 main pcscd[22447]: 00000000 ../PCSC/src/winscard.c:281:SCardConnect() Error Reader Exclusive Sep 29 23:55:23 main pcscd[22447]: 00003704 ../PCSC/src/winscard.c:281:SCardConnect() Error Reader Exclusive
This is reproduceable - it doesn’t matter if just a simple --card-status or a full --sign - the YubiKey stays locked.
This makes it quite complicated when using the same YubiKey both for PGP and PIV for ssh (git) as a commit signing locks the key and makes it unavailble for the push unless force unlocked.
I’m not sure if this is gpg fault or maybe something via pcscd - but given when using the internal scdaemon instead of pcscd this locks is also persistent until force unlocked by gpg-card > reset > quit. So I suspect this is some deeper in how gpg handles the private key of a smartcard.
As this is my first and only token and I just encountered this issue while playing around with git commits and signing and such I first suspected git to be the issue but was able to narrow it down to gpg.
Oh, I’m sorry to have forgotten to give that along.
This is on vanilly Arch using official repos. Here should be any relevant package.
The key itself is a YubiKey 5 NFC (keychain, usb-a) with firmware 5.7.4.
pacman -Qs gnupg
local/gnupg 2.4.8-1
Complete and free implementation of the OpenPGP standard
local/gpgme 2.0.1-1
C wrapper library for GnuPG
local/lib32-libgcrypt 1.11.2-1
General purpose cryptographic library based on the code from GnuPG (32-bit)
local/lib32-libgcrypt15 1.5.6-8
General purpose cryptographic library based on the code from GnuPG
local/libassuan 3.0.0-1
IPC library used by some GnuPG related software
local/libgcrypt 1.11.2-1
General purpose cryptographic library based on the code from GnuPG
local/libgcrypt15 1.5.6-6
General purpose cryptographic library based on the code from GnuPG
pacman -Qs pcsc
local/pcsclite 2.3.3-1
PC/SC Architecture smartcard middleware library
pacman -Qs yubi
local/yubico-c 1.13-7
Yubico YubiKey C library
local/yubico-c-client 2.15-6
Yubico YubiKey client C library
local/yubico-piv-tool 2.7.2-1
Command line tool for the YubiKey PIV application
local/yubikey-manager 1:5.8.0-1
Python library and command line tool for configuring a YubiKey
local/yubikey-personalization 1.20.0-4
Yubico YubiKey Personalization library and tool
For reproducability: I rm -rf ~/.gnupg to start from clean - run gpg --card-status once to reinitialize the .gnupg folder, then add disable-ccid to .gnupg/scdaemon.conf and do a gpgconf --kill all. After that I can access the key from both gnupg and ykman until I call any of gpg --sign which causes the lock. I’ve read about pcsc-shared - but its info says should be used only when knowing what you do - and I don’t so I’m not sure if this is the right optoin to use.
Overall it’s just more of an annoyance as fully breaking as in the end it still works and can be solved in pure software by gpg-card reset instead of having to replugg the key physical - but as the token and smartcards in general are supposed to be used in different ways not just “yeap, wanna do some pgp today - gonna lock that card for the session to it” - at least that’s my understanding of it and hence I’d like to investigate what’s going on and if it’s really gnupg actively not releasing some lock or if it’s maybe further down the stack in pcsclite or whatever yubico brings along. For now I haven’t encountered any other condition were the exclusive lock is not properly released other then gpg --sign.
Well, although I don’t doubt that pcsc-shared might help in my specific scenario the man page states to use it with caution. And according to the operations it’s correct that whatever application access the key do so exclusively. But keeping the lock after the operation is done is what seems wrong to me. Unfortunate I’m myself not able to figure out where this is caused and if it’s intentional /by design or if it’s a bug or maybe even a race condition. Maybe it’s caused somewhere else along the stack in pcscd or maybe even in the yubikey firmware itself. But to start somewhere I start here and question if gnupg releases the lock properly or keeps holding on to it - then gnupg would be “at fault” - or if gnupg tries to release the lock but it fails somewhere else - then I have a lead to follow.
If one could point me to the source and the flow what happens when I do git commit -S ... all tge way to the lock, the operation and the release of the lock I may be able to work my way tbrough it. But as for now I wasn’t even able to find the source for that chain to read through it myself.
I’ve dug deeper - and according to code analyze the “issue” is that the yubikey is “grabbed” lazy as part of the initialization that leads up to the crypto operation (in my case: signing) - but then it’s not actively released. Guess that’s true for other code paths for all kinds of crypto operations - or even just key generation or setting up the token.
There was card-timeout - but as its logic got removed its a no-op.
So, to me this looks like “gnupg does something not the way how “smartcards” like a yubikey are supposed to be used” - and hence I would file this as a bug report.
// edit
There’s already something similar: ⚓ T7041 Yubikey (PGP + PIV) --pcsc-shared: PIN requires every time with two replies I highly disagree with, both by “werner”:
“Do not use the pcscd but the integrated CCID driver.”
and
“You should use gpg-agent’s integrated ssh-agent. It is anyway much more convenient.”
This is not how pgp should be used with hardware tokens - and no, this is not “more convenient” but “binding users into the gnupg eco system” and actual contradicting to “a hardware token should be an addition - not binding you to its eco system”.
One could turn this on its head: As I use a YubiKey Yubico could go the same enforcement: binding me to use only thier tools instead of using thier key with gnupg.
Guess I’m gonna look into alternatives to gnupg which don’t enforce me into thier eco system. That’s quite a bummer for a “gnu” project … even if its just it the name.
btw: I also anaylized the issue to not be able to set mails to the mailing list - the mail server rejects me with “the server X is not allowed to send mails for domain Y” - excuse me? WHAT? my domain is correctly setup - that’s an issue on the gnupg side!
the more I’m hacking around gnupg’s quirk of lazy init and not unlocking the more I discover how broken pgp is
although I managed to get a proper signature via javax.smartcardio “git commit -S” fails although strace’d and the output of my wrapper is exact the same as what gnupg returns - and according to a pgp analyzer and gnupg itself the signature is valid - so even if git does some verification it should pass the same way as a gnupg signature does
what’s with all that mess? one implementation becoming the de-facto standard so closed either use it or don’t use the underlying broken standard at all
I somewhat regret spending 60€ + shipping just to lock myself in into gnupg while either locking myself out of existing configs or have to migrate them
yea - no - I rather use openssl and x509 - at least that works with open libs and is interoperable
guess this can be close as “a bug, but gnupg doesn’t care” (given by what I read from Werner about sequoia and “whish them to fail”