[pkg-gnupg-maint] Bug#834633: Bug#834633: Info received (Bug#834633: Acknowledgement (gpg: signing failed / agent_genkey failed: Operation cancelled))

[Daniel Kahn Gillmor]

Control: reassign 834633 src:pinentry
Control: tags 834633 + moreinfo
Control: retitle 834633 pinentry curses fallback failing without clear explanation

Hi Linus--

Sounds like the bug you're reporting really does have to do with
pinentry, so let's try to get that figured out.  I'm reassigning this
bug report to the pinentry package.

There are different pinentry variants which each support different
environments.

Different variants need specific environment variables available to them
in order to run correctly, though.  It sounds like you're doing this on
some sort of remote machine, rather than a normal desktop session.  is
that right?  I'd still expect the ones that need fancier environments to
be able to fall back to curses if the fancier environments aren't
available, though.

> userA$ LANG=EN systemctl --user enable gpg-agent; LANG=EN systemctl --user start gpg-agent
> Failed to connect to bus: No such file or directory
> Failed to connect to bus: No such file or director

This makes me think you don't have dbus installed or something.  is that
right?  how are you connecting to this session?  if this login is
managed by systemd, is there a systemd user session started?  is
libpam-systemd installed and activated for your particular login method?

is there a session-specific dbus session running?

what do you see if you do:

   echo $DBUS_SESSION_BUS_ADDRESS

On Mon 2016-08-22 18:56:10 -0400, Linus Lüssing wrote:
> With some help from IRC the problem could be narrowed down to
> pinentry. My setup so far involved a VNC session and the only
> pinentry package installed was "pinentry-gnome3". What works for
> me is pinentry-gtk2, for instance.

what exactly are you doing to run the test?  I often test pinentry
directly with something like:

   tty=$(tty)
   echo getpin | env -i pinentry --ttyname=$TTY --ttytype=$TERM --display=$DISPLAY


> Using VNC:
> * pinentry-gnome3: "Operation cancelled" (why?)
> * pinentry-gtk2: works!
> * pinentry-qt: Other, VNC+qt4 specific bug
> * pinentry-curses: "Permission denied" (why?)

you say "using VNC" -- what's offering the VNC login?  does it start a
systemd session?

for gnome3 -- do you have dbus installed?  I've just proposed a patch
upstream for pinentry-gnome3 [0] -- that pinentry should really be
ignoring X11 entirely and just focusing on dbus.

[0] https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031529.html

> Using ssh:
> * pinentry-gnome3: Permission denied (obviously,needs X11)
> * pinentry-gtk2: Permission denied (obviously, needs X11)
> * pinentry-qt: Permission denied (obviously, needs X11)
> * pinentry-curses: Permission denied (why?) 

These should all still fall back to pinentry-curses if there is a
terminal available.  what kind of test are you using where the curses
fallback isn't happening?  Is $TERM set appropriately?

> Using ssh with X-forwarding (ssh -X):
> * pinentry-gnome3: Operation cancelled (why?)

I suspect this is due to the X11-vs-dbus confusion in upstream gnome3 currently

> * pinentry-gtk2: works!
> * pinentry-qt:  works!
> * pinentry-curses: Permission denied (why?)

this is probably the same reason that curses is failing above.  once we
work that out, it should be fixed.

> So I'll be using pinentry-gtk2 for now which reduces the severity
> of this bug for me. But the error message gnupg displays is a
> little confusing and does not indicate to the user that s/he
> should maybe try installing an alternative (non-broken?) pinentry
> package.

sounds to me like there are three specific bugs here:

 a) some vnc+qt4 bug that you mention above -- do you have a pointer to
    that?  I'd like to identify it as affecting pinentry-qt if possible.
   
 b) some gnome3+dbus bug, combined with gnome3 being confused about
    trying to talk to X11 somehow.  I think this is an upstream bug with
    pinentry-gnome3 so i hope to resolve it separately.

 c) some bug where the curses fallback isn't happening correctly.

I'm going to re-focus this bug on (c) in the hope that we can figure out
at least that part of things.

If you want to try to track down (a) and (b) separately, feel free to
clone this bug (or ask me to clone it).

> PS: And with switching to pinentry-gtk2 I also had to add a
> "set pgp_use_gpg_agent=yes" to my muttrc to avoid being asked for
> a password twice (once within mutt and once in the pop-up).

mutt should probably default to using libgpgme these days, but that's a
separate issue worth reporting on mutt itself.

         --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/20160829/885bf6a8/attachment-0001.sig>