On Tue 2016-11-08 02:55:22 -0600, Vincent Lefevre wrote: > Then, there should be another mean (I don't know which one) so that > pinentry-gnome3 displays the prompt at the right place, e.g. when > the user has an X session open locally on the machine but also > accesses the machine remotely via ssh and the user runs gpg from > this remote access. > > Communicating with the d-bus session only doesn't seem to be enough > since DBUS_SESSION_BUS_ADDRESS has the same value under X and via ssh.
they do share a d-bus session in some circumstances (e.g. when dbus-user-session is installed), and they do not in others. But I hear you that the situation you want changed is happening when they do share a session. > It should use the information about the current screen. Under X11, > this comes from DISPLAY (I don't think there's another way because > the user can choose where something should be displayed by directly > changing the value of DISPLAY, and disregarding DISPLAY would not > honor this requirement). For wayland, probably WAYLAND_DISPLAY, but > according to the package description, only X and text terminals are > currently supported by pinentry-gnome3: "If the X Window System is > not active then an alternative text-mode dialog will be used." I consider this a bug in pinentry-gnome3's documentation -- it does not care about the X Window system at all, but rather uses d-bus. > And if you mean that pinentry-gnome3 should delegate the display > to GNOME so that it doesn't have to know whether X or wayland or > whatever is used, then fine, but: > > * It should still have a fallback to X / terminal when GNOME is not > used (this is my case here). If Gcr (the GNOME crypto kit, which includes the system prompter) is not available on the current d-bus session, pinentry-gnome3 *does* fall back to the terminal. Are you suggesting that we should be checking for some other test? > * It should be able to detect whether the user is in front of his > GNOME session or accesses the machine in some other way (e.g. > ssh from a remote machine). Can you recommend a mechanism for this? What would you test? We could simply test for the presence of $DISPLAY *even though pinentry-gnome3 doesn't need it* and fall back if it is unset. 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. 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). To begin that work, we'd need to be able to query d-bus about what current X11 session it believes it is attached to. I don't know how to do that. do you? >> Perhaps you mean to be using pinentry-gtk-2? > > pinentry-gnome3 is used by default, so in any case, it should work > correctly. pinentry-gnome3 is used by default if it is installed. But the default pinentry that will be installed if you just "apt install gnupg" will be pinentry-curses. Regards, --dkg
signature.asc
Description: PGP signature