Bug#834633: gpg: signing failed / agent_genkey failed: Operation cancelled

[l***@c0d3.blue]

Package: gnupg
Version: 2.1.14-5
Severity: important

Hi,

Since recently (the update from gnupg 2.1.11-7 to 2.1.14-5 yesterday?)
I'm unable to use gnupg. I'm unable to decrypt mails in mutt now, and on
the console, key generation or file signing fails like this:

~~~~~
userA$ LANG=EN gpg -v -v --gen-key
gpg (GnuPG) 2.1.14; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Max Mustermann
Email address: ***@example.com
You selected this USER-ID:
"Max Mustermann <***@example.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: agent_genkey failed: Operation cancelled
Key generation failed: Operation cancelled
~~~~~

~~~~~
userB$ cd /tmp/; echo testfile > testfile.txt && LANG=EN gpg -v --sign -b testfile.txt
gpg: using pgp trust model
gpg: using "00B7A52F" as default secret key for signing
gpg: writing to 'testfile.txt.sig'
gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled
~~~~~

As I read something about systemd integration in the other tickets, I
checked "systemctl list-units" and there are no failed ones. Rebooting
the system did not help either.

Also trying to start a gpg-agent.service (not sure whether this is
relevant) fails:

~~~~~
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
~~~~~

However, after invoking --sign or --gen-key, a gpg-agent is running:

~~~~~
ps -Af |grep gpg-agent | grep -v grep
userA 4370 1 0 18:36 ? 00:00:00 gpg-agent --homedir <USERAHOME>/.gnupg --use-standard-socket --daemon
userB 6127 1 0 18:39 ? 00:00:00 gpg-agent --homedir <USERBHOME>/.gnupg --use-standard-socket --daemon
~~~~~

Please let me know if you need any further information. Thanks :-).

Regards, Linus


-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.2.3-00234-g11acd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii gnupg-agent 2.1.14-5
ii libassuan0 2.4.3-1
ii libbz2-1.0 1.0.6-8
ii libc6 2.23-4
ii libgcrypt20 1.7.2-2
ii libgpg-error0 1.24-1
ii libksba8 1.3.4-4
ii libreadline6 6.3-8+b4
ii libsqlite3-0 3.14.1-1
ii zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii dirmngr 2.1.14-5
ii gnupg-l10n 2.1.14-5

Versions of packages gnupg suggests:
pn parcimonie <none>
pn xloadimage <none>

-- no debconf information

[Linus Lüssing]

Actually, seems like the upgrade of the gnupg package from
1.4 to 2.1 is the issue (gnupg:armhf (1.4.20-6, 2.1.14-5) ).

Just reinstalled the old 1.4.20-6 version for the gnupg package
and things work nicely for me again.

Anyone having an idea why gnupg2 might fail for me?

Regards, Linus

[Linus Lüssing]

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.

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

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?)

Using ssh with X-forwarding (ssh -X):
* pinentry-gnome3: Operation cancelled (why?)
* pinentry-gtk2: works!
* pinentry-qt: works!
* pinentry-curses: Permission denied (why?)


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.

Regards, Linus


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).

[Werner Koch]

Post by Linus Lüssing
* pinentry-curses: "Permission denied" (why?)

strace will help you. Create a pinentry-wrapper script like

--8<---------------cut here---------------start------------->8---
#!/bin/sh
locale >/tmp/pinentry.err
set >>/tmp/pinentry.err
exec strace -o /tmp/pinentry.trc -e read=0 \
/somewhere/pinentry -d "$@" 2>>/tmp/pinentry.err
--8<---------------cut here---------------end--------------->8---

and put

pinentry-program /somewhere/else/pinentry-wrapper

into gpg-agent.conf. GnuPG 2.1 also support a "debug-pinentry" option
for gpg-agent.conf which traces the communication between gpg-agent and
pinentry.

Post by Linus Lüssing
should maybe try installing an alternative (non-broken?) pinentry
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

I'd suggest to use "set crypt_use_gpgme" instead of the old fashioned
interface.


Shalom-Salam,

Werner

[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.

Post by l***@c0d3.blue
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

Post by l***@c0d3.blue
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

Post by l***@c0d3.blue
* 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

Post by l***@c0d3.blue
* 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?

Post by l***@c0d3.blue
* pinentry-gnome3: Operation cancelled (why?)

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

Post by l***@c0d3.blue
* 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.

Post by l***@c0d3.blue
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).

Post by l***@c0d3.blue
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