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

[Daniel Kahn Gillmor]

Control: severity 927105 important
Control: retitle 927105 pinentry-gnome3: No curses fallback over ssh when graphical console screen is locked

On Tue 2019-04-16 21:50:47 -0700, Zephaniah E. Loss-Cutler-Hull wrote:
> I need to try and find the time to spin up a Wayland native VM and do 
> some testing to see if DISPLAY is getting set in all reasonable cases.

A native Wayland GNOME3 environment with DISPLAY unset is still
reasonable (even if unlikely), and we expect pinentry-gnome3 to work in
that case.

> System was locked with the lock screen hot key, password is required to 
> unlock, and monitors were powered down by the system.  So definitely locked.

thank you for doing this testing and debugging, and for your thoughtful
documentation here.  You've demonstrated that it isn't working
as intended, and it isn't as well-integrated into the GNOME3 environment
as it should have been.

> Which means that the correct fix is to simply change the timeout from 0 
> to something sane.

yes, that sounds reasonable.

> A tested patch is attached.

great, i've pushed that patch (and an additional cleanup fix on top of
it) upstream, and am going to upload a fixed package to debian unstable
shortly.

> Now, I'm still not entirely convinced on the logic that a remote session 
> should trigger a desktop PIN entry, but that seems more like an upstream 
> design question of intent instead of something to try and fix in Debian. 
>
>   I'm happy to try and do some work to implement a check that works on 
> Wayland as well if upstream has any interest in it, but first we would 
> need to confirm the intent.

I'm as much "upstream" as anyone on the GNOME3 pinentry these days,
sadly (i don't even use GNOME3!) and while i can't speak for others in
the GnuPG team, i'll just make a few observations here:

 * "upstream" is definitely the right place to have this discussion --
   if you want to propose a change in the intent, please use
   https://dev.gnupg.org/ or the gnupg-devel at gnupg.org mailing list, and
   let's keep this bug report focused on pinentry-gnome3's failure to
   fall back to curses when the screen is known to be locked.

 * pinentry-gnome3 is designed and intended to work with the user's
   GNOME3 session.  GNOME3 itself expects that for any user, there is at
   most a single GNOME3 session active on a given machine.  This is
   actually reasonably well-aligned with GnuPG's gpg-agent, which
   assumes that the user has a single gpg-agent session active on a
   given machine.

 * detecting whether a current process is part of an active GNOME3
   session (i.e., *not* from "a remote session") is best done through
   GNOME3 mechanisms -- and how GNOME3 elements communicate with one
   another is dbus.

 * pinentry itself is not typically launched from within your ssh
   session at all -- it's launched by gpg-agent, which itself is likely
   to have been launched (on a machine capable of GNOME3) by a the
   systemd user service manager (quite possibly within the context of an
   active $DISPLAY.

   That is: you run gpg from your ssh session, it talks to gpg-agent
   (which might have been started based on socket activation from
   systemd --user), and gpg-agent (sometimes) tries to invoke pinentry.

So when you say you want pinentry to do something different from "a
remote session", you need to consider that whole communications channel
and process inheritance setup.  For example, gpg sends gpg-agent a
series of configuration options that describe its current environment,
and gpg-agent (in some cases) decides how to invoke pinentry on the
basis of that environment.  If that environment is missing information
(e.g. $DISPLAY), but gpg-agent itself knows some other relevant data
(e.g. $DISPLAY from dbus-user-session) then gpg-agent might invoke
pinentry differently.

This is an ugly mess, but it's how the GnuPG suite works at this point.
So if you want pinentry-gnome3 to do something different "from a remote
session" (not necessarily a bad thing or anything i'd reject if it was
well-thought out and predictable to the user), you probably want to
think about all those moving parts.

Thanks a lot for your help in debugging and your patch!

       --dkg
-------------- 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/20190417/a7e6a868/attachment.sig>