[pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Daniel Kahn Gillmor]

Control: severity 911768 normal

Hi Simon --

Thanks for this detailed triage!

On Sun 2019-03-10 14:35:04 +0000, Simon McVittie wrote:
> I think this should be considered to be a pinentry-gnome3 bug rather than
> nfs-kernel-server. I think the plausible routes forward are to either
> escalate dbus-user-session from Recommends to Depends, downgrade this bug
> to non-RC (because not working completely reliably without Recommends is
> not entirely unexpected), or consider it to be "not a bug" and close it
> (same reason).

escalating dbus-user-session to a Depends: for pinentry-gnome3 seems
like a mistake to me (pinentry-gnome3 *should* work even on sytsems
where dbus-user-session isn't installed, particularly on systems where
there is no systemd session-manager), so i'm downgrading the severity at
least here.  What do others think?

For the moment, i'm reducing severity to "normal" since it seems to only
affect certain selections of packages in combination with certain system
configurations.

This is the worst kind of sticky issue for debian generally, because
there is no clear way to apportion responsibility, and the intersection
between the packages can fall through the cracks :( If someone can
propose a concrete path forward that will resolve the problem for those
folks who have it, i'd be happy to try to incorporate it.

> It's a pity we can't make pinentry-gnome3 depend on something like
> "dbus-user-session | not(libpam-systemd)".

that would be nice, but it's still not the most robust, because of
course you can have libpam-systemd installed and not have it listed in
/etc/pam.d/common-session :/

> As a dbus upstream and Debian maintainer, I'd recommend installing
> dbus-user-session, particularly if you have bits of infrastructure that
> want to run one instance per (machine,uid) pair (typically user-services
> started by `systemd --user`) and communicate via D-Bus.

Note that gpg-agent itself, whether invoked as a systemd user-service or
manually/automagically (as upstream prefers), is precisely one of these
per (machine,uid) pair services.

The main difference is that when gpg-agent is invoked as a systemd
user-service, its lifetime terminates at the same time as the user
session (because the systemd --user manager terminates it upon session
close).  When gpg-agent is invoked manually/automagically, it has no
clear termination strategy, which means it may linger (sometimes with
unlocked key material) well after session termination, if no other
reaping mechanism is explicitly invoked.

> dbus-user-session is entirely "glue" and doesn't contain significant
> amounts of code. Depending how other packages' dependencies are set up
> and how much progress has been made on fixing my 2016 mass-bug-filing
> about dbus-launch (dbus-x11), installing dbus-user-session might let
> you remove dbus-x11, which is larger than dbus-user-session. Is that
> any help? :-)

should we discourage these two packages (dbus-user-session and dbus-x11)
from being co-installed somehow?

> For what it's worth, I couldn't reproduce this bug by installing a fairly
> minimal GUI system (xdm, xorg and openbox) plus pinentry-gnome3 and
> gpg-agent in a test VM, purging dbus-user-session, and adding and
> removing nfs-kernel-server.

Can someone provide a minimal reproducer, starting from an empty VM?

    --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/20190312/496ead43/attachment.sig>