[pkg-gnupg-maint] Bug#927105: Bug#927105: pinentry-gnome3: No proper curses fallback.

[Daniel Kahn Gillmor]

Control: tags 927105 + upstream moreinfo

Hi Zephaniah--

Thanks for your thoughtful report!

On Sun 2019-04-14 23:25:14 -0700, Zephaniah E. Loss-Cutler-Hull wrote:

> Looking at the code, it sure looks like it tries to handle this, by 
> checking to see if there is a DBUS_SESSION_BUS_ADDRESS (which there is, 
> inherited from the gpg-agent), if a gcr system prompt is available, and 
> trying to see if the screen is locked, however in my testing none of 
> these actually seem to work to detect that, indeed, the screen is locked 
> and the user isn't at the desktop any more.
>
> To me the obvious solution is to also check and see if there is a 
> display set, using the same logic as pinentry-gtk-2, I have some fear 
> that this will break a pure wayland environment (one with no xwayland 
> involved), however I don't actually have one of those handy to test 
> with.  If someone with a wayland environment could test this that would 
> be appreciated.

As far as i'm aware, the current state is a deliberate choice by
upstream (and it's also one that i think is the right answer) -- GNOME3
is not X11-only, and pinentry-gnome3 doesn't bother communicating with
the X11 session via $DISPLAY at all.  As you point out, your proposed
patch seems likely to fail in environments like Wayland.

If you don't want to talk to a GNOME3 session, you can change your
pinentry explicitly to be something other than pinentry-gnome3 :)

That said, are you certain that GNOME desktop is is locked when you
conduct your test?  What screenlocking mechanism are you using?  If the
screen is *unlocked* then i think there's a decent argument for wanting
the prompt to happen on the screen anyway.  But if the screen is locked,
and it can fall back to curses maybe i can agree with you that it
should?

If you have any patch that you want to propose that falls back to curses
if both:

 * gcr fails because the screen is locked, and
 * a tty is available

Then i would be happy to help you convince upstream (e.g. via
https://dev.gnupg.org/) that this should be adopted.  I've suggested
this approach before in #842015, but i haven't had the time (or the
experience with using dbus to monitor a GNOME session lock, e.g. [0]) to
implement it myself.

There may also be a race condition here -- between testing for the
screen lock and using gcr, or vice versa.  Perhaps gcr itself is what
needs to be able to fail cleanly (thereby triggering the fallback) if
the screen is locked?  that seems less likely to have a race.  I'm open
to different implementation ideas, anyway, but testing for $DISPLAY
seems like the wrong choice.

          --dkg

[0] https://elementaryos.stackexchange.com/questions/14083/dbus-signal-for-session-lock-unlock
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20190416/6d676050/attachment.sig>