Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#42896 - [gnupg] 2.1.0-4 upgrade breaks passphrase via STDIN

Attached to Project: Arch Linux
Opened by Troy Engel (TE) - Tuesday, 25 November 2014, 14:18 GMT
Last edited by Gaetan Bisson (vesath) - Friday, 28 November 2014, 18:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



The upgrade of gnupg from 2.0.26-1 to 2.1.0-4 breaks duply/duplicity passphrase pipe via STDIN (scripted), instead of accepting the passphrase echo'd in gpg-agent (?) pops up a GTK pinentry dialog.

(Manually typing the passphrase in the pinentry works, however - that part is not broken.)

Additional Information:

I ran duply in preview mode and grabbed the basic command from it's initial test+encrypt:

-- Run cmd -- Test - Encrypt to '15DE5E40' & Sign with '15DE5E40' --
echo XXXXXX | /usr/bin/gpg --sign --default-key 15DE5E40 --passphrase-fd 0 --batch -r 15DE5E40 --status-fd 1 -o /tmp/duply.5459.1416887390_ENC -e /usr/bin/duply 2>&1

If I run that by hand, I unexpectedly get a gpg-agent/pinentry GTK dialog popup on my desktop instead of the passphrase being accepted from STDIN (no user input/scripted); if I kill gpg-agent and downgrade the gnupg package to 2.0.26-1 then everything works as expected (the passphrase is accepted from STDIN).

I don't use any fancy gnupg configs:

$ egrep -v "^(#|$)" .gnupg/gpg*.conf
.gnupg/gpg-agent.conf:default-cache-ttl 300
.gnupg/gpg-agent.conf:max-cache-ttl 999999
.gnupg/gpg.conf:keyserver hkp://

I tried adding 'pinentry-program /usr/bin/pinentry-curses' as a test and recycled gpg-agent, it "worked" but just hung on an input screen. I see a number of commits and bugs upstream, some that seem close but nothing obvious. I notice in the changes to PKGBUILD from -3 to -4 that "--enable-standard-socket" was added, however since I didn't test 2.1.0-3 I'm not sure if this is what broke it.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Friday, 28 November 2014, 18:59 GMT
Reason for closing:  Upstream
Comment by Gaetan Bisson (vesath) - Tuesday, 25 November 2014, 16:12 GMT
Could you report this upstream?
Comment by Troy Engel (TE) - Tuesday, 25 November 2014, 18:59 GMT

I spent the day working from git and built a new package (2.1.1-beta44) and same behaviour, so it's not one of the fixed commits yet. I did further testing by using the same method the 'tests/openpgp/signencrypt.test" uses and the fake script to verify that it seems like an upstream bug and not a boneheaded config mistake on my end.
Comment by Troy Engel (TE) - Tuesday, 25 November 2014, 19:01 GMT
Forum thread with other users verifying:
Comment by Troy Engel (TE) - Friday, 28 November 2014, 17:10 GMT
OK, worked this out with upstream -- the upgrade "breaks" backwards compatibility without some changes:

1. The user must add "allow-loopback-pinentry" to ~/.gnupg/gpg-agent.conf -- this will take affect when gpg-agent is auto launched as needed, version 2.1+ *requires* gpg-agent and pinentry now.

2. The apps need to use "--pinentry-mode loopback" as a commandline option, or alternatively add "pinentry-mode loopback" to ~/.gnupg/gpg.conf (however the upstream author things this will break other things).

Luckily duply already supports a 'GPG_OPTS=' config and I was able to fully test the upgrade by applying the two above changes. I've added a new blurb to the wiki trying to describe this change, we can close out this bug report. Thanks!
Comment by Gaetan Bisson (vesath) - Friday, 28 November 2014, 18:59 GMT
Thank you so much for working this out! Cheers.