baldurmen
commented
1 year ago 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
scdaemonsees:$ 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.confthat 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àààà.
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-cardorgpg --sign foo.txttake 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-skkey) and I need my GPG token to sign commits...Note that I've reported this as a
gnupgbug 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¯\_(ツ)_/¯