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