Specifying different pinentry based on caller?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Nov 9 17:44:24 CET 2016

On Wed 2016-11-09 05:14:30 -0600, Peter Lebbing wrote:
> On 08/11/16 20:24, Tim Chase wrote:
>> When using a GUI program like Claws Mail, I'd
>> like to use the graphical pinentry, but I'd prefer to default to the
>> terminal pinentry for everything else.
> One step in the right direction is unsetting the DISPLAY environment
> variable when gpg is invoked. Ensuring that gpg never gets to see a
> usable DISPLAY var might be all that is needed (or it might not,
> depending on Desktop Environment, I don't know :-).
> It works for me on a terminal just invoking:
> $ DISPLAY= gpg2 -s test.txt
> (Actually, that's not unsetting it, just setting it to an empty value.
> But it works.)

fwiw, this is taking advantage of the "curses fallback" in whatever
pinentry you're using -- it is not using a different pinentry.

But in general, i think it's better to let the agent do its thing
independent of gpg.  why do you want a terminal-based pinentry in other
contexts?  secret key isolation is one of the big advantages of the
2.1.x gpg-agent, and trying to mix the agent's interactions with the
process that's using the agent makes that isolation less effective.

If you really want to do this, though, i note that unsetting DISPLAY
won't work for all graphical pientry programs.  In particular, the
development branch of pinentry-gnome3 (and the versions in debian
testing and unstable) use d-bus to talk to the GNOME system prompter,
and don't interact directly with the X11 session.  I don't know what
pinentry you're using, but if your goal is to force the curses-fallback,
you might want to also explicitly point DBUS_SESSION_BUS_ADDRESS at
something that isn't a dbus socket; this will cause anything that tries
to talk to d-bus to fail, which should result in a curses fallback.  At
the same time, you also need to ensure that GPG_TTY is explicitly set,
otherwise the curses fallback will fail if the tool that ultimately
invokes gpg has no access to a tty directly (or if you invoke gpg with
stdin and stdout bound to non-pty pipes).  So i think you want:

    DISPLAY= DBUS_SESSION_BUS_ADDRESS=/dev/null GPG_TTY=$(tty) gpg2 […]

If you know that gpg is going to be in a position to prompt the user
directly, and you're running 2.1.15 or later, you can also try adding
the --pinentry-mode=loopback argument to your gpg command.

But again, i recommend *not* trying to do this.  let the agent be
effectively isolated!

Hope this helps,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161109/2b6380de/attachment.sig>

More information about the Gnupg-users mailing list