I have been asked to look at bug 676034 in Red Hat Enterprise Linux. There we actually two issues there:
- Running pinentry with DISPLAY variable set but no available GUI pinenty helpers
- Using gpg on console after doing “su -”
First problem was relatively easy to figure out. Pinentry finds DISPLAY variable and looks for pinentry-gtk, pinentry-qt or pinentry-qt4 helpers to ask for passphrase. Unfortunately if none of these GUI helpers can be found, pinentry doesn’t try their console counterpart. Workaround is simple: unset DISPLAY variable if you are working over ssh connection (or don’t use X forwarding when you don’t need it). More recent pinentry features proper failover to pinentry-curses
Second problem was a bit more tricky to figure out, although in the end it was a facepalm situation. When trying to use GNUPG as root on console, hoping for pinentry-curses to ask for passphrase, users were instead introduced to this message: ERR 83886179 Operation cancelled. To make things more confusing, everything seemed to work when logging in as root directly from ssh.
At first I thought that this must be caused by environment variables, but this seemed to be incorrect assumption. Instead the reason was that current tty was owned by original owner and not root. This seemed to cause problem with gpg-agent and/or ncurses pinentry. I will investigate who was the real culprit here, but this bug seems to be fixed at least in recent Fedoras
So what should you do if you have weird problems with gpg and pinentry as root? Here’s what:
$ su -
# chown root `tty`
[use gpg, pinentry as you want]
Easy right? As a final note…I’ve been to FOSDEM and I plan to blog about it, but I guess I am waiting for the videos to show online. It’s quite possible I’ll blog about it before that however, since it’s taking a while.