Configuration hints for using gnupg (2.0.x) interchangeably with graphical frontend and in the terminal

Peter Lebbing peter at digitalbrains.com
Thu Jun 9 19:50:25 CEST 2016


On 01/06/16 21:36, Bjoern Kahl wrote:
>  Currently, whenever Enigmail needs a passphrase, it throws up a popup
>  window (actually, it runs gpg, which runs the agent, which runs
>  pinentry-mac, which throws up the window) _somewhere_: sometimes on
>  the screen I am looking at, sometimes on another physical screen,
>  sometimes hidden behind other windows, sometimes in the front.

That's odd, I don't know pinentry-mac, but pinentry-gtk is always fully
on top. It's so much on top that you can't use any other window while
it's active. It would require the option "no-grab" to prevent it from
fully taking over the screen. Do you perhaps have that option or
something equivalent configured in gpg-agent.conf?

As for which display it pops up on... on an X11 server, it will use the
X display the request is coming from, but an X display may consist of
several physical screens. Since my two screens are next to each other, I
really can't tell you if it pops up on the same physical screen. I
suspect it might not, since it probably only communicates the contents
of the DISPLAY environment variable to the agent.

>  When using gpg in the terminal originally the same happened: Some
>  random window popping up at some random spot on some random monitor.
> 
>  Even worse, when logging in through SSH, it throw up a pin entry
>  window on the locked graphical session idling on the remote machine
>  instead of in the terminal I am working in.

Now that is something that definitely should not be happening. That's
odd. It's a pity I know nothing about Macs, so I can't directly help
you. But this does not happen here on Linux. When you invoke gpg on a
terminal and that gpg needs a pinentry, it tells the agent on which tty
it is and what its DISPLAY environment variable is. When you use SSH,
this will not set a DISPLAY variable by default, so you'll get a text
pinentry on the text terminal you run SSH on. If you use X forwarding,
it will do the correct thing and set an appropriate DISPLAY and set up
access control, after which you'll get the pinentry on the system you're
SSH'ing from. Only if you misconfigure SSH and force it to pass through
the DISPLAY environment variable, would such a thing as you describe
happen. In that case, your DISPLAY variable is probably ":0", and it
will contact the first local X server, which will be the wrong one, as
"local" is interpreted wrongly.

>  Partial solution tried:
> 
>  I created a second gpg-agent.conf named "gpg-agent-term.conf" and
>  configured the first to run pinentry-mac and the latter to run
>  pinentry-curses.

This really shouldn't be necessary. The only thing where you normally
need to watch out is with the SSH agent support, which has no means to
communicate invoking tty and graphical display. But when you're just
using gpg, it should do the correct thing out-of-the-box, and you need
no configuration for using gnupg (2.0.x) interchangeably with graphical
frontend and in the terminal (your title :).

> Searching through
>  all my shells where the passphrase dialogue appeared is annoying.

Yes, that is *very* annoying.

>  - Whenever I run gpg in a terminal, it will ask me for my passphrase
>    in exactly that terminal where I am interacting with it and expect
>    the prompt?  I.e. on that TTY that is the controlling TTY of the
>    gpg process I am interacting with?

That's exactly what should happen by default. Well, at least on the same
graphical environment as the terminal emulator if you're using one.

>  - Is there a way to have a single agent (with a single config file,
>    so I can start it at first login and have it available in all
>    terminals/shells and programs (e.g. Thunderbird) started from there)
>    but still a graphical passphrase in programs which (no longer) have
>    StdIn connected to a terminal or don't have a controlling TTY; and
>    have a plain prompt in the terminal for programs that run in a
>    terminal?

I think the priority is different: it will prefer graphical, and only
when that is deemed not available, fall back to text on the controlling
tty. If that is not available either, I think it will give up and error out.

When I say it will prefer graphical, then I mean the graphical
environment the terminal emulator is running in, not just any
environment. Certainly not on a different system. Of course, if you
multi-display a single "screen" terminal session, it might go haywire as
any X application would, since it would pick the DISPLAY from the
"screen" session that started it.

Do you have any non-default configuration set?

Again, it's a pity I know nothing of Macs. I don't even know how MacOS
communicates the fact that there is a graphical display available.
AFAIK, using X11 is just a compatibility feature thing, not the main
method to talk to the graphical environment on OS X, so it's probably
not through the DISPLAY environment variable?

However, I haven't seen anyone with actual knowledge of the topic reply
to you yet, so I thought I'd give you what I do know,

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



More information about the Gnupg-users mailing list