[pkg-gnupg-maint] Bug#842015: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Control: tag 842015 + moreinfo

On Sat 2016-11-05 06:31:39 -0400, Vincent Lefevre wrote:
> Control: reopen 842015
> Control: found 842015 0.9.7-7
>
> On 2016-11-04 23:23:43 -0400, Daniel Kahn Gillmor wrote:
>> The three bugs above are all caused by a situation where the user wants
>> to use secret key material with gpg, while relying on pinentry-gnome3
>> with access to a d-bus session, but where that d-bus session has no
>> access to an expected GNOME session.
> [...]
>
> The problem is still there. Note that I've tried after upgrading then
> rebooting the machine to make sure that nothing from old software was
> running (in particular, I've noticed that otherwise, gpg-agent is
> still running after I log out of all my X / SSH / screen sessions).
>
> Basically:
>
> 1. Upgrade and reboot the machine A.
>
> 2. Log in with X.
>
> 3. Type "gpg -d file.gpg" and cancel at the pinentry-gnome3 prompt.
>
> 4. On some other machine, ssh to machine A.
>
> 5. In this ssh session, type "gpg -d file.gpg".
>
> Result: A pinentry window is opened on the X display of machine A
> and this gpg "freezes".

It's not freezing, it's waiting for the user of the GNOME3 session to
respond to the pinentry-gnome3 prompt.

When there is no GNOME3 session connected to the d-bus session, 0.9.7-7
does in fact fall back to curses as expected.

But when there's an active GNOME3 session, pinentry-gnome3 prompts via
the GNOME3 session.  This is why it's called "pinentry-gnome3".

> I confirm that the workaround (unset DBUS_SESSION_BUS_ADDRESS and
> kill gpg-agent) still works.

This is not an effective workaround, for several reasons:

 * you may be running other code that wants a dbus session, so unsetting
   it is not reasonable.

 * by killing gpg-agent and restarting it without a dbus session, you've
   removed the ability for gpg processes *within* the gnome3 session to
   actually prompt the user via gnome3's standard prompter.

If you want a pinentry that only speaks curses (and never tries to
integrate with a gnome3 session), you should install pinentry-curses and
either remove pinentry-gnome3, or place "pinentry-program
/usr/bin/pinentry-curses" in your gpg-agent.conf.

One additional exacerbating factor that you're seeing is probably due to
the fact that pinentry-gnome3 doesn't currently respect the default
timeout.  I have patches queued that will respect the timeout that will
be uploaded shortly as 0.9.7-8, though.

It's not clear to me what you actually want to happen here (which is why
i've tagged this bug report with "moreinfo").  Can you help me
understand?  Over on https://bugs.gnupg.org/gnupg/issue2818 i discuss
the corner case where there is an active gnome3 session but it is
screen-locked; pinentry-gnome3 could be made to fall back to curses in
that scenario as well (by querying the state of the gnome screensaver),
but that still wouldn't change the scenario that you describe above:

  if the user is connected to an active gnome3 session, and they are
  talking to gpg-agent which is configured to use pinentry-gnome3,
  gpg-agent's prompt will appear on the active gnome3 session.

Can you explain what you'd rather happen here?

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161106/7e561510/attachment.sig>