If you can’t sign/decrypt with a YubiKey and Thunderbird/Enigmail you might want to add
--pinentry-mode=ask to the “additional parameters for GnuPG” in the Enigmail configuration
After setting up all the cool Encryption stuff using a YubiKey I was so happy that everything worked.
And then I set up using the YubiKey for SSH as well as described in the documents I linked in the last blogpost. It took a reboot for everything to work out as I wanted it, but I was happy. Until I wanted to send a signed Email using Thunderbird/Enigmail.
What shall I say… It didn’t work any more. Marco asked me that on Twitter when I published the last post but at that time everything was behaving as it should. I guess the tweaking to get the SSH stuff running broke something.
But today I took some time and dug into it. And it turned out that actually not Thnderbird/Enigmail was misbehaving but the underlying GPG was the root cause of the issue.
Enigmail doesn’t do the Encryption/signing themselves but delegates that task to GPG by calling some CLI-commands and handling the return values. You can find out which commands Enigmail runs by opening up the Error-Hadling Console. The command run for the actual signing part is this:
/usr/bin/gpg --charset utf-8 \ --display-charset utf-8 \ --no-auto-check-trustdb \ --batch \ --no-tty \ --verbose \ --status-fd 2 \ --log-file [/path/to/a/logfile] \ -a \ -t \ --encrypt \ --sign \ --trust-model always \ --encrypt-to [key to encrypt to] \ -r [key to sign with] \ -u [key to encrypt to]
I tried to run that in my CLI like this:
$ echo "test" | /usr/bin/gpg --charset utf-8 \ --display-charset utf-8 \ --no-auto-check-trustdb \ --batch \ --no-tty \ --verbose \ --status-fd 2 \ --log-file [/path/to/a/logfile] \ -a \ -t \ --encrypt \ --sign \ --trust-model always \ --encrypt-to [key to encrypt to] \ -r [key to sign with] \ -u [key to encrypt to]
The result was the same as when trying to send a signed email via Thunderbird. No Prompt for the PIN of my YubiKey and an error.
Then I tried the whole thing a bit simpler and ran this on the CLI:
$ echo "test" | /usr/bin/gpg -s
And what the heck: There was the PIN-Entry. But wait. It was on the CLI. And I can understand that that doesn’t work when GPG is run in batch-mode. So After a bit of tweaking and checking my (least) favourite search engine (Why google finds better results than any other search engine I’ve so far tried is a different post) I found out about
loopback-pinentry and the
To make a long story short: I now have the following entries in my
enable-ssh-support pinentry-program /usr/bin/pinentry-gtk-2 default-cache-ttl 60 max-cache-ttl 120 extra-socket /run/user/1000/gnupg/S.gpg-agent.extra browser-socket /run/user/1000/gnupg/S.gpg-agent.browser no-allow-loopback-pinentry ttytype xterm-256color no-allow-external-cache
This sets the default pinentry-program to the gtk2. So now when I run
echo "test" | gpg -s" I get a window prompting me for my YubiKey-PIN as I expected it.
But the command from Enigmail sadly still failed. So there still seemed to be an issue with the pinentry-mode. So I searched for that and after a while I stumbled over an issue in the GPG-Bugtracker that showed me a different pinentry-mode. So I tried the GPG-Command on the CLI with the additional setting of
--pinentry-mode=ask. And what shall I say. It worked immediately. I got a PIN-Entry window, could enter the PIN and the message was signed.
So I needed to add that option to the GPG-Command that Enigmail calls. So I went to “Enigmail-Settings” => “Extended” and added
--pinentry-mode=ask to the “additional Parameters for GnuPG”, saved and tried to send a signed email. And voila! Here popes the PIN-Entry window up!