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
Hope this helps,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 930 bytes
Desc: not available
More information about the Gnupg-users