Bug#840687: gnupg: Fails to sign git commits

[Josef Vitu]

Package: gnupg
Version: 2.1.15-4
Severity: normal

Dear Maintainer,

after upgrading from 1.4.20-6 to 2.1.15-4, signing a git commit fails with
the following errors:

gpg: signing failed: No data callback in IPC
gpg: signing failed: No data callback in IPC
error: gpg failed to sign the data
fatal: failed to write commit object

The password input into the pinentry-gnome3 (or pinentry-gtk-2) dialog is
100% correct.

Attempts to use pinentry-tty failed with:

gpg: signing failed: Invalid IPC response

I can view/edit/etc. all of the stored keys (using gpg; tried to install
seahorse as well), only the communication wit git seems to be failing.

Downgrading to 1.4.18-7+deb8u2 fixes the problem.

Regards
Josef Vitu


-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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.15-4
ii libassuan0 2.4.3-1
ii libbz2-1.0 1.0.6-8
ii libc6 2.24-3
ii libgcrypt20 1.7.3-1
ii libgpg-error0 1.24-1
ii libksba8 1.3.5-2
ii libreadline7 7.0-1
ii libsqlite3-0 3.14.2-1+b1
ii zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii dirmngr 2.1.15-4
pn gnupg-l10n <none>

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

-- no debconf information

[Daniel Kahn Gillmor]

Control: tags 840687 + unreproducible moreinfo

Hi Josef--

thanks for your report! sorry to hear you're having this problem.
hopefully we can get it sorted out!

I tried to replicate this with a test directory:

workdir=$(mktemp -d)
export GNUPGHOME="$workdir/gpg"
mkdir -m 0700 $GNUPGHOME
gpg --batch --passphrase-fd 3 3<<<test --quick-gen-key 'test account <te...@example.org>'
fpr=$(gpg --with-colons --with-fingerprint --list-secret-keys | awk -F: '/^fpr:/{print $10}' | head -n1)
git init "$workdir/test"
cd "$workdir/test"
echo test > test.txt
git add test.txt
git commit -S"$fpr" -m 'test commit'

and it worked for me, using a pinentry-gnome3 :/

I did *not* get the responses you got:

On Thu 2016-10-13 16:44:38 -0400, Josef Vitu wrote:

> after upgrading from 1.4.20-6 to 2.1.15-4, signing a git commit fails with
> the following errors:
>
> gpg: signing failed: No data callback in IPC
> gpg: signing failed: No data callback in IPC
> error: gpg failed to sign the data
> fatal: failed to write commit object
>
> The password input into the pinentry-gnome3 (or pinentry-gtk-2) dialog is
> 100% correct.

Then i tried using pinentry-tty manually, with:

echo pinentry-program pinentry-tty >> "$workdir/gpg/gpg-agent.conf"
gpg-connect-agent killagent /bye

And i got the same errors you did:

> Attempts to use pinentry-tty failed with:
>
> gpg: signing failed: Invalid IPC response

with pinentry-tty, i saw:

gpg: signing failed: Invalid IPC response
gpg: signing failed: Invalid IPC response

error: gpg failed to sign the data
fatal: failed to write commit object

However, if i set GPG_TTY before trying to sign, the signature worked
with pinentry-tty as well:

export GPG_TTY=$(tty)
git commit -S"$fpr" -m 'test commit'

that worked fine.

So something is different about your setup. Can you start by trying the
same sequence i tried (with 2.1.15-4) and letting me know whether it
works independent of your homedir?



With your own homedir where this stuff is failing, can you turn up the
logging in gpg-agent and see what's going on there? add the following
lines to ~/.gnupg/gpg-agent.conf :

debug-pinentry
log-file /home/YOURUSER/gpg-agent.log

and then kill off the agent so it can be restarted:

gpg-connect-agent killagent /bye

and try to sign again.

Let me know what you find!

--dkg

[Josef Vítů]

Dear Daniel,

thanks for your prompt reply. The test setup worked just fine, but
after debugging gpg-agent as you suggested (with a higher debug-level,
though) I know where the problem is. Attaching the log is pointless I
think, as the critical line is clearly here:

DBG: chan_10 -> SETERROR Passphrase too long (try 2 of 3)

Looks like pinentry cannot handle passwords longer than 255 ASCII
characters (at least in my case), and there's even an abandoned bug
report about that, so maybe I should move there?

https://bugs.gnupg.org/gnupg/issue1592

Thank you once more.

Regards
Josef Vitu

[Daniel Kahn Gillmor]

Control: forwarded 840687 https://bugs.gnupg.org/gnupg/issue2758
Control: retitle 840687 gpg does not cope well with long passphrases

On Fri 2016-10-14 03:29:34 -0400, Josef Vítů wrote:

> thanks for your prompt reply. The test setup worked just fine, but
> after debugging gpg-agent as you suggested (with a higher debug-level,
> though) I know where the problem is. Attaching the log is pointless I
> think, as the critical line is clearly here:
>
> DBG: chan_10 -> SETERROR Passphrase too long (try 2 of 3)
>
> Looks like pinentry cannot handle passwords longer than 255 ASCII
> characters (at least in my case), and there's even an abandoned bug
> report about that, so maybe I should move there?
>
> https://bugs.gnupg.org/gnupg/issue1592

ah yes, sounds like you've found the issue. I'm retitling this bug
report, because gpg should at least tell you that it doesn't like the
length of your passphrases, rather than leaving it to fail mysteriously.

there's also:

https://bugs.gnupg.org/gnupg/issue2038

I've also just done some additional experimentation with ultra-long
passphrases and the result is this additional upstream bug report:

https://bugs.gnupg.org/gnupg/issue2758

fwiw, i don't think you should need more than 128 characters or so for a
really strong passphrase (plain english is about 1 bit of entropy per
character, and passphrases longer than 128 bits of entropy are probably
pointless), and gpg's limits are supposed to be ~256 characters.

But still, gpg should make those limits much more clear to the user.

--dkg