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

[Daniel Kahn Gillmor]

Control: tags 842015 + help

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.

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

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

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

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

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

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

instead, so that you can purge pinentry-gnome3 without it yanking
evolution.  pinentry-gtk2 is capable of stashing and restoring passwords
with the SecretService that gnome-keyring provides, so they should be OK
with that.

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.

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

 2) use pinentry-gtk2 or pinentry-qt or pinentry-curses instead of
    pinentry-gnome3
 
 3) purge dbus-user-session so that ssh sessions do not talk to the same
    d-bus session as the graphical session

 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

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

Regards,

        --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/20161109/970d9e8c/attachment-0001.sig>