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
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
|
Details
Description:
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:require-cross-certification .gnupg/gpg.conf:keyserver hkp://keys.gnupg.net 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
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 pinentry.sh script to verify that it seems like an upstream bug and not a boneheaded config mistake on my end.
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!
https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase