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
signature.asc
Description: PGP signature