[pkg-gnupg-maint] Bug#842015: Bug#842015: Bug#842015: Similar issue, no emacs

[Daniel Kahn Gillmor]

On Wed 2016-11-02 06:25:25 -0400, Vincent Lefevre wrote:
> I think that this might be related with systemd. I have reported
> another bug (bug 842908) as actually gnupg does not work *at all*
> via SSH without $DISPLAY on one of my machines with systemd, even
> when there isn't a running gpg-agent (the problem is different:
> I just get an obscure error message). On another machine without
> systemd, there is no such problem.

I think we ought to take the "systemd" meme out of discussion here.  I
think it's being used by conflation with "d-bus", and that confusion is
unlikely to be helpful in resolving these issues.

a bit of background:

 * there are at least three different mechanisms that the GnuPG suite
   can communicate with the current user when needed:

    0) via a terminal (or pseudoterminal, terminal emulator, etc)

    1) via X11

    2) via d-bus

 * all of these mechanisms are potentially available in multiple ways on
   a standard GNU/Linux system.  That is, there is (or can be) multiple
   terminals, X11 sessions, or dbus sessions running concurrently.

 * for each mechanism, there are specific environment variables that are
   used to select which communications pathway to use.  For terminals,
   we use $GPG_TTY; for X11, we use $DISPLAY and $XAUTHORITY; and for
   d-bus we use $DBUS_SESSION_BUS_ADDRESS

 * gpg no longer handles secret key material at all.  Instead, it talks
   to gpg-agent, which handles secret key material for it.

 * if gpg-agent isn't currently running, gpg will auto-launch a copy of
   the agent, which then persists.

 * When an invocation of gpg needs to use secret key material, it will
   ask gpg-agent to do the secret key operation.  gpg-agent knows
   whether it has permission to unlock the secret key material or not.
   If it does, it uses it without interaction.  If it does not, it must
   prompt the user, either for simple confirmation, or for a passphrase.

 * when gpg-agent needs to talk to the user, it invokes pinentry.

 * gpg passes its current best guess of relevant env vars to gpg-agent,
   which in turn sets them up appropriately for pinentry if pinentry is
   invoked.

So the path to the user's prompt is:

  gpg → gpg-agent → pinentry

And note that gpg-agent may or may not have been started using the same
session information that the current run of gpg has access to.  And some
gpg instances don't have access to some of the communications channels,
even if gpg-agent itself did have that access.

Furthermore, the choice of pinentry also constrains what kind of user
communication is possible.  Different pinentry programs can take
advantage of different user communication details:

 * pinentry-curses, pinentry-tty: terminal only.  If gpg isn't directly
   connected to a terminal, or doesn't know $GPG_TTY, then gpg-agent
   simply has to guess what terminal to use.
 
 * pinentry-gtk-2, pinentry-qt: X11, fallback to terminal if $DISPLAY
   isn't available

 * pinentry-gnome3: d-bus, fallback to terminal if d-bus connectivity
   fails (this is actually somehow mixed at the moment; it's not clear
   whether pinentry should fall back to the terminal only if
   $DBUS_SESSION_BUS_ADDRESS is unset, or whether it should *also*
   fallback to the terminal if the prompting agent itself is
   unavailable; i lean toward the latter, but Werner has declined a
   patch that makes that happen)

I note that we have no pinentry program that is capable of taking
advantage of all three possible messaging routes.

So there are a few places where this can fall down:

 0) gpg can not know the locations to recommend for prompting (e.g. when
    run with no tty attached at all and a clean environment) -- in this
    case, it cannot launch an effective gpg-agent, or communicate with
    an existing gpg-agent to instruct it where the pinentry should
    appear.

 1) a running gpg-agent process may or may not be attached to the same
    communications callback mechanisms that a communicating gpg process
    has.

 2) under an ssh connection, only a terminal-based pinentry will work
    unless the ssh session has forwarded X11 (which is itself a risky
    thing to do).  ssh has no built-in, well-supported mechanism for
    forwarding d-bus connections.  Also, note that it's possible (and
    even likely on some machines) to have a dbus session running
    associated with an ssh login, but a non-X11 dbus session will be
    unable to display a graphical (GNOME3) prompt.

Of course, regular users shouldn't have to know about any of this, i'm
just trying to clarify the inter-process communications for people who
want to help resolve the issue.  Is this analysis missing anything?

Does anyone have any suggestions for what the right next steps are?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161102/ab7d2406/attachment.sig>