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

[Vincent Lefevre]

On 2016-11-09 11:56:20 -0600, Daniel Kahn Gillmor wrote:
> On Wed 2016-11-09 01:57:41 -0600, Vincent Lefevre wrote:
> > OK, but it uses dbus. So, there should be a way with dbus to know
> > whether the user is currently using the graphical session.
> 
> We *do* know whether the user is currently using the graphical session.
> The user is logged in at the graphical console, has a gcr-prompter
> available, and the screen is not locked.

No, this is wrong. In this case, the user isn't necessarily using
the graphical session. Moreover, there are uses where one certainly
does *not* want to lock the screen. For instance, the screen is
not locked because I'm watching a video or TV full screen but at
the same time, I'm using my phone to do some work on the machine.
Making the prompt window appear on the screen is wrong.

In the past, I was using VNC (I mean, the full desktop in VNC) because
I had several machines at home, so that I could reuse the same desktop
on a different one (the VNC client was opened full screen). Locking
the virtual X session makes no sense at all.

I was also using VNC at my lab because I was using some X tool
on some server, which had to be kept permanently running. This
is currently not the case, but may occur again.

Some users also work with multiple machines / desktops / screens
at the same time without VNC.

The only correct and *standard* way is to test $DISPLAY.

> gcr opens a window on the screen where it knows the user is logged in,
> present, and not locked.  right?

It does, but this is wrong. The prompt should appear where the user
has invoked gpg.

> The default debian desktop system used GNOME the last time i tried to
> install it.

It's available, but the user still has the choice to select what he
wants. Anyway, I'm using gpg, which has nothing to do with GNOME.

> The default for a GNOME desktop is to integrate well with GNOME. Your
> main concern here is that gnome-keyring depends on pinentry-gnome3 and
> no other pinentry.    Perhaps you'd like to reassign this bug report to
> gnome-keyring and ask them to:
> 
>     Depend: pinentry-gnome3 | pinentry-gtk2

I don't use gnome-keyring, but the dependency on pinentry comes
from gnupg-agent, which has:

Depends: pinentry-curses | pinentry, [...]

However, pinentry-curses is not installed by default because
pinentry-gnome3 is already installed via gnome. Perhaps it should have
a Recommends on pinentry-curses or pinentry-gtk2 to make sure that by
default, pinentry-gnome3 is not the only one installed.

> instead, so that you can purge pinentry-gnome3 without it yanking
> evolution.

Well, I don't mind yanking evolution. But what about multi-user
machines, which may have GNOME and non-GNOME users?

IMHO, the correct solution would be to detect whether GNOME is used,
and with a wrapper, select pinentry-gnome3 in this case, and
pinentry-gtk2 otherwise when available.

Note that pinentry-gtk2 remains superior for non-GNOME users (and
for GNOME users who connect by SSH), because it will still be able
to display a graphic window (which users may prefer to curses) even
with SSH + X forwarding, contrary to pinentry-gnome3, if I understand
correctly.

> I'm marking this bug with "help" because i'm at my wit's end here.  I
> understand the situation you've described.  I do think it's a corner
> case (most people don't ssh into any machine, let alone into a
> workstation that they're currently logged into), and you have many other
> options to work around it that you refuse to do:
> 
>  0) log out of your workstation when you leave it.

Obviously unacceptable (or I would at least need to use VNC, with
the same issues, I assume).

>  1) let GNOME lock your screen automatically, or lock it when you leave
>      the workstation.

I'm not using GNOME. And autolock is annoying. Detecting whether
a session is idle is broken anyway (I use DPMS, but sometimes the
screen gets on again even if I'm not touching the machine). I don't
want to lock manually because that's annoying too, and I may forget
and so on. Anyway, there are cases where one does not want to lock.

>  2) use pinentry-gtk2 or pinentry-qt or pinentry-curses instead of
>     pinentry-gnome3

This should be the default for non-GNOME users, then. By default,
things should not break!

>  3) purge dbus-user-session so that ssh sessions do not talk to the same
>     d-bus session as the graphical session

It would break Recommends or something like that, i.e. potentially
breaking other software. Well, I now know remamber that I installed
dbus-user-session due to the following bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829557

It is now fixed, but in any case, dbus-user-session should not
introduce unwanted side effects because it may still be useful
in the future, and may be more or less mandatory; see discussion
"Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)"
in debian-devel (July 2016).

>  4) manually export DBUS_SESSION_BUS_ADDRESS=/dev/null inside your ssh
>     connection so that anything running there knows not to talk to dbus,
>     ever

This may break things. In the past, I got GConf errors (with the Gtk
version of Emacs?) because DBUS_SESSION_BUS_ADDRESS got unset.

Note also that the problem should be solved for VNC users too.

> If you have a more constructive suggestion for how to resolve it, i'm
> happy to hear it.

What about the wrapper idea? (The best solution, IMHO, as the use
of pinentry-gtk2 may be better than the fallback to curses.)

Otherwise, test some environment variable(s), either in pinentry-gnome3
or in Gcr via a communication of the value with pinentry-gnome3 (but
I think that the communication would be overkill in practice).

-- 
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)