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

[Vincent Lefevre]

On 2016-11-08 17:41:54 -0600, Daniel Kahn Gillmor wrote:
> From the dbus-user-session package description:
> 
>      This model merges all parallel non-graphical login sessions (text
>      mode, ssh, cron, etc.), and up to one graphical session, into a
>      single "user-session" or "super-session" within which all
>      background D-Bus services are shared.

This is unclear because ssh + X forwarding should not be regarded
as a non-graphical login session.

> > 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.
> 
> perhaps you'd like to reassign this bug to gcr-prompter?  I'm not
> convinced that they would accept it -- gcr-prompter is attached to a
> single d-bus session, and if that d-bus session has a graphical session
> associated with it, it uses that session.

But with the concept of "super-session", this way of doing doesn't
make sense. Before using the graphical session, it should make sure
that it has been called from this graphical session.

> >> 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.
> 
> Right.  And pinentry-gnome3 does not itself use X.

OK, but it uses dbus. So, there should be a way with dbus to know
whether the user is currently using the graphical session.

> > 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.
> 
> What test are you imagining?  Most users don't want an "X dialog window"
> -- they want a graphical window where possible, and they have no idea
> what DISPLAY is :/

Most users don't need to know. DISPLAY is inherited from the
environment.

> i'm sorry, but if this bug report depends on the user using manual
> window placement with fvwm, i'm inclined to close it wontfix.

That's just an example. The fault does not come from fvwm, but
entirely from pinentry/Gcr, which opens a window on the wrong screen.

> we're already in a corner case (ssh to a machine where the same user
> is already logged in on the graphical console)

This is certainly not a corner case.

> of a corner case (and the graphical screen isn't locked, despite
> that we're working with sensitve secret key material),

The machine is in a locked room, and I'm the only one to have the key.

> > 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                  
> 
> on a default debian system, the user has the GNOME lockscreen and the
> GNOME window placement, and the screen will lock when they leave it long
> enough to get to an ssh client elsewhere and connect in.

No, not everyone uses GNOME on a default Debian system.

> If you have a concrete test that you think we could implement in
> pinentry-gnome3, i'm game to entertain it.  Please test.  But if what
> you want is a pinentry that strictly follows the currently-attached X11
> session (rather than following the attached d-bus session), you might
> want to just use a different pinentry.

Then that should be the default.

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