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
signature.asc
Description: PGP signature