[pkg-gnupg-maint] Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Vincent Lefevre]

On 2016-11-08 08:21:14 -0600, Daniel Kahn Gillmor wrote:
> On Tue 2016-11-08 02:55:22 -0600, Vincent Lefevre wrote:
> > Then, there should be another mean (I don't know which one) so that
> > pinentry-gnome3 displays the prompt at the right place, e.g. when
> > the user has an X session open locally on the machine but also
> > accesses the machine remotely via ssh and the user runs gpg from
> > this remote access.
> >
> > Communicating with the d-bus session only doesn't seem to be enough
> > since DBUS_SESSION_BUS_ADDRESS has the same value under X and via ssh.
> 
> they do share a d-bus session in some circumstances (e.g. when
> dbus-user-session is installed), and they do not in others.  But I hear
> you that the situation you want changed is happening when they do share
> a session.

Yes, dbus-user-session got installed automatically as a consequence
of dependencies.

> > It should use the information about the current screen. Under X11,
> > this comes from DISPLAY (I don't think there's another way because
> > the user can choose where something should be displayed by directly
> > changing the value of DISPLAY, and disregarding DISPLAY would not
> > honor this requirement). For wayland, probably WAYLAND_DISPLAY, but
> > according to the package description, only X and text terminals are
> > currently supported by pinentry-gnome3: "If the X Window System is
> > not active then an alternative text-mode dialog will be used."
> 
> I consider this a bug in pinentry-gnome3's documentation -- it does not
> care about the X Window system at all, but rather uses d-bus.

I see, a gcr-prompter process appears when I run gpg...

> > And if you mean that pinentry-gnome3 should delegate the display
> > to GNOME so that it doesn't have to know whether X or wayland or
> > whatever is used, then fine, but:
> >
> > * It should still have a fallback to X / terminal when GNOME is not
> >   used (this is my case here).
> 
> If Gcr (the GNOME crypto kit, which includes the system prompter) is not
> available on the current d-bus session, pinentry-gnome3 *does* fall back
> to the terminal.  Are you suggesting that we should be checking for some
> other test?

So, the problem occurs only because with dbus-user-session installed,
ssh and X shares a d-bus session.

Now, how does gcr-prompter decide which display to use? The problem
may be here. This does not come from dbus-daemon, since as documented
in the dbus-daemon(1) man page:

  The per-session daemon is used for various interprocess communication
  among desktop applications (however, it is not tied to X or the GUI in
  any way).

So, I'm wondering...

> > * It should be able to detect whether the user is in front of his
> >   GNOME session or accesses the machine in some other way (e.g.
> >   ssh from a remote machine).
> 
> Can you recommend a mechanism for this?  What would you test?

This depends on how gcr-prompter currently decides which display to
use.

> We could simply test for the presence of $DISPLAY *even though
> pinentry-gnome3 doesn't need it* and fall back if it is unset.

pinentry-gnome3 could remain unaware of displays if gcr-prompter
communicates with it via d-bus. For instance, gcr-prompter could
ask the values of some environment variables. Since gcr-prompter
is the program that does the display, it should know what to ask.
That would be the obvious thing to do in order to decide which
display to use.

> But pinentry-gnome3's end-user prompts currently work even when they're
> run from a process where DISPLAY has unset for whatever reason.  It
> sounds like you're asking to break this functionality.

I actually don't understand why this should work: unsetting DISPLAY
is a way to prevent from processes using X.

I'm not asking to break this functionality, because there could be
another test before testing DISPLAY. But one needs to know why a
user would want an X dialog window while DISPLAY has been unset.
And in this case, how the display is determined.

> Another possible approach would be to prompt via the terminal *in
> addition* to prompting graphically, if the current d-bus session knows
> about an X11 session, but that X11 session does not match the current
> value of $DISPLAY (e.g. if $DISPLAY is unset, or if it is set to a
> different value).

The graphical prompt when unexpected is also itself a problem.
For instance, it can make other applications freeze while the
user hasn't acknowledged the new window via his window manager.
I use fvwm's manual placement and it is currently a problem.
So, it shouldn't be "in addition".

> To begin that work, we'd need to be able to query d-bus about what
> current X11 session it believes it is attached to.  I don't know how to
> do that.  do you?

According to the dbus-daemon(1) man page (see above), d-bus isn't
attached to an X11 session.

> >> Perhaps you mean to be using pinentry-gtk-2?
> >
> > pinentry-gnome3 is used by default, so in any case, it should work
> > correctly.
> 
> pinentry-gnome3 is used by default if it is installed.  But the default
> pinentry that will be installed if you just "apt install gnupg" will be
> pinentry-curses.

On a default Debian desktop system, pinentry-gnome3 is installed:

cventin:~> aptitude why pinentry-gnome3
i   evolution             Depends evolution-data-server (>= 3.22.1)
i A evolution-data-server Depends gnome-keyring                    
i A gnome-keyring         Depends pinentry-gnome3                  

The evolution package is marked as manually installed, but I've
never installed it explicitly. I suppose that this is because it
got installed by the Debian installer together with many other
applications.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)