GPG hangs when using a Yubikey

cdecker

8/4/24, 2:10 PM

I am trying to debug why all of the sudden my Yubikey is taking very long to access. The Yubikey holds a GPG private key, that is then used for GPG and SSH. It was working just fine for several months and now it is taking several seconds just to complete a decryption or signature:

$ echo hi | time gpg --clearsign
...
gpg --clearsign  0.00s user 0.00s system 0% cpu 21.660 total

This used to be instantaneous. Seeing a rather round and reproducible delay I went hunting for the potential causes, and I have traced the issue through gpg-agent down to the scdaemon that is used to communicate with the actual smart card. Turning on logging on the scdaemon gives me this:

2023-08-04 16:02:01 scdaemon[197085] DBG: chan_7 <- SERIALNO
2023-08-04 16:02:11 scdaemon[197085] DBG: apdu_open_reader: BAI=94102
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 -> S SERIALNO ABCD
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 <- SERIALNO
2023-08-04 16:02:23 scdaemon[197085] DBG: apdu_open_reader: BAI=94102
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S SERIALNO ABCD
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 <- GETATTR KEY-FPR
2023-08-04 16:02:23 scdaemon[197085] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0
2023-08-04 16:02:23 scdaemon[197085] DBG:  raw apdu: 00 CA 00 6E 00
2023-08-04 16:02:23 scdaemon[197085] DBG:  response: sw=9000  datalen=224
2023-08-04 16:02:23 scdaemon[197085] DBG:       dump:  6E 81 DD 4F ...
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 1 AXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 2 BXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 3 CXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 <- RESTART
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK

Notice that there are two separate breaks, each of 10 seconds each. It appears to be attempting to read the serial number from the smart card if I'm reading the logs correctly.

What could be causing this delay? Could it be a network lookup that is failing after 10 seconds? And how can I address this issue and not have to wait 20-30 seconds on each git commit or ssh connection I do?

0 + 4

gpg

gnupg

yubikey

James T

8/21/24, 4:31 AM

Does this yubikey have the same delay regardless of which computer you use? Does a different yubikey have the same delay on this computer? Are other operations fast, such as status? https://developers.yubico.com/yubico-piv-tool/Actions/status.html

James T

8/21/24, 4:36 AM

Also please confirm your yubikey is authentic: https://www.yubico.com/genuine/

cdecker

8/21/24, 8:37 AM

Thanks for commenting James, very good points that I should have clarified. The delay isn't always there, it appears to be related to suspending the notebook and then waking it up again. The more things I try the more I tend towards attributing the issue to DBUS being misconfigured (I'm running sway on Wayland on Ubuntu), and possible the gnome-keyring being unreachable.

cdecker

8/21/24, 8:38 AM

The yubikey is genuine, and I've only ever observed this issue on this machine, though as mentioned above, it comes and goes.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: GPG hangs when using a Yubikey

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.