gpg crashes the solokey v2, firmware 0.128.241
Closed this issue · 1 comments
Hello,
As others have reported, this is not the place for firmware issues, but the issue tracker for those has been closed.
It seems invoking gpg
(version 2.2.40) on Debian unstable (I haven't tried to reproduce this on other machines) crashes the solokey v2 completely.
Commands like gpg --edit-card
or gpg --sign foo.txt
take a while to run (~20s, which is not normal) and eventually fail (since there's no smartcard present on the system), but this ends up crashing the solokey v2. The token becomes unresponsive to touch and to CLI commands.
This is pretty bad, as my use case requires the solokey v2 to push git commits (ed25519-sk
key) and I need my GPG token to sign commits...
Note that I've reported this as a gnupg
bug on Debian (as gpg shouldn't crash the solokey), but on the other hand, the solokey shouldn't be crashing when some random, unrelated program runs on my machine either ¯\_(ツ)_/¯
If anyone stumbles on this issue (which I'm closing), the problem does seem to be a firmware issue. As reported here, the issue is likely caused by some missing abort
handling in the code.
GnuPG itself it also probably to blame, as scdaemon
sees the solokey v2 as an OpenPGP smartcard, which it is not.
The way to "fix" this issue (a proper fix would probably be a firmware one...) is to use the reader-port
argument in scdaemon
not to match the solokey:
- Plug both your solokey v2 and your OpenPGP smartcard
- Run the following command, to get a list of the tokens
scdaemon
sees:$ echo scd getinfo reader_list | gpg-connect-agent --decode | awk '/^D/ {print $2}'
- Identify your OpenPGP smartcard. For example, my Nitrokey Smart is listed as
20A0:4211:FSIJ-1.2.15-43211613:0
- Create a file in
~/.gnupg/scdaemon.conf
that includes the following linereader-port $YOUR_TOKEN_ID
. For example, in my case it is:reader-port 20A0:4211:FSIJ-1.2.15-43211613:0
- Reload scdaemon:
$ gpgconf --reload scdaemon
Voilàààà.