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

[Daniel Kahn Gillmor]

Hi Vincent--

On Tue 2016-11-08 10:23:22 -0600, Vincent Lefevre wrote:
> Yes, dbus-user-session got installed automatically as a consequence
> of dependencies.

dbus-user-session is also very much in line with gpg-agent's
--standard-socket option (which is now the default): both of them have
the concept of a single session running for any given user on the
machine.

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

yes, launched due to
/usr/share/dbus-1/services/org.gnome.keyring.SystemPrompter.service

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

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 depends on how gcr-prompter currently decides which display to
> use.

it uses the graphical session attached to the dbus session.  if there is
no graphical session, it fails in a noticeable way, which is when we
choose to fall back to text.

> 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 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.  It uses the gcr
prompter, which it talks to over d-bus.  We're going around in circles
on this bug report, and i'm starting to feel diminishing returns.

> 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 :/

>> 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".

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.  we're
already in a corner case (ssh to a machine where the same user is
already logged in on the graphical console) of a corner case (and the
graphical screen isn't locked, despite that we're working with sensitve
secret key material), and i need to focus what debian/GnuPG packaging
energies are available on things that affect more people.

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

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.

          --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/20161108/0ea4cc4d/attachment.sig>