You are not logged in.
I'm not exactly sure what's going wrong -- the upgrade of gnupg from 2.0.26-1 to 2.1.0-4 (which also deprecates dirmngr package) today breaks my duply/duplicity passphrase pipe via STDIN. 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; if I downgrade the gnupg package (after killing gpg-agent) + dirmngr then everything works as expected (the passphrase is accepted from STDIN). The /usr/bin/pinentry symlink points to pinentry-gtk-2 in both packages, and I don't use and 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 - took a look upstream and see a bunch of 2.1.0 issues but nothing that seems applicable:
http://git.gnupg.org/cgi-bin/gitweb.cgi … ads/master
https://bugs.g10code.com/gnupg/issue?@s … ,3,4,5,6,7
Anyone have an idea what else to try? Nothing in the gpg-agent man page looked applicable, I'm sure it's something to do with 2.1.0 upstream...
Last edited by TE (2014-11-28 16:39:21)
Offline
Same here. Maybe you should fill a bug report?
Offline
Thanks for confirming - I opened a bug in our system before upstream to be sure it's not the Arch package compile options or whatnot.
Offline
I don't know if it's related to your problem but GPG2.1 doesn't allow pass phrases to be specified in a file or on the command-line. See the page on unattended operation, look at "%ask-passphrase" and "%no-protection" https://www.gnupg.org/documentation/man … ation.html
Offline
I don't know if it's related to your problem but GPG2.1 doesn't allow pass phrases to be specified in a file or on the command-line. See the page on unattended operation, look at "%ask-passphrase" and "%no-protection" https://www.gnupg.org/documentation/man … ation.html
Thanks for the link - that's only for gen-key, however. But I do confirm the "--passphrase-fd 0" is supposed to still be working as described in the current docs:
https://www.gnupg.org/documentation/man … ic-Options
--passphrase-fd n
Read the passphrase from file descriptor n. Only the first line will be read from file descriptor n. If you use 0 for n, the passphrase will be read from STDIN. This can only be used if only one passphrase is supplied.
So in theory the functionality hasn't changed. :-/
Offline
Same problems here. --passphrase-fd 0 is not working. I can't sign emails. gpg-agent also appears to have stopped working (GPG_AGENT_INFO does not get exposed in the environment file). I'm considering downgrading gpg. This is a mess.
Last edited by ignorant (2014-11-25 18:40:35)
Offline
Nevermind. I got gpg-agent working again (it goes by GPG_TTY now instead of GPG_AGENT_INFO), but the --passphrase-fd bug is still a problem.
Offline
It's fortunately easy to downgrade, and it solves (at least temporarily) the problem.
Offline
After testing the latest git code, upstream bug filed: https://bugs.g10code.com/gnupg/issue1772
Offline
Before downgrading be sure to kill the gpg-agent process; you may need to log out/in to reset GPG_AGENT_INFO depending on your config (I think '/usr/bin/gnome-keyring-daemon --start --components=gpg' sets it, it's the 'GNOME GPG Agent" in startup apps on my MATE desktop).
Offline
It looks like the latest gpg put my private key into a new format. So downgrading will be annoying. I'll have to go grab my private key from my backup. Is this fixable? This is so damn frustrating. gpg has always had a horrible interface, but they had to go break it on top of that.
Last edited by ignorant (2014-11-25 20:04:55)
Offline
I give up. --passsphrase-fd is just flatout broken. I'm done trying to debug this mess. I guess I'll wait a few weeks for a fix. In the meantime all my emails are unsigned. Lovely.
Offline
Hey, just ran into this. Would someone mind walking me through the use of that downgrade script? I tried just:
downgrade gpg
but it failed silently, and the author's troubleshooting advice wasn't much help :S.
curl --fail --silent --data arch=x86_64 --data-urlencode pkgname=gpg http://repo-arm.archlinuxcn.org/exact
gives nothing
Offline
If you haven't cleaned your cache, you can try this:
pacman -U /var/cache/pacman/pkg/gnupg-2.0.26-1-x86_64.pkg.tar.xz
If you have cleaned your cache, just grab these two files:
http://seblu.net/a/arm/packages/g/gnupg … pkg.tar.xz
http://seblu.net/a/arm/packages/d/dirmn … pkg.tar.xz
... toss them in /var/cache/pacman/pkg/ and then run the above command to downgrade. The .sig files are on the ARM server if you want to check your sigs (a good idea since this is gnupg).
Offline
We shouldn't have to downgrade due to incompetence. The latest gnupg upgraded my private key to the latest format which means I have to get my old private key unless it's backwardly compatible. How is there not a workaround for this? Is it working as intended? Am I missing something?
Offline
Screws fall out all the time, the world's an imperfect place. - John Bender
Relax man, it's just a broken new dot-oh - we've reported it upstream, coderninjas will get it fixed. With Arch upgrades you take the good with the bad - sometimes things are just broken, this is the first major release of the gnupg 2.1 branch.
Offline
Sorry. Just really upset from this.
Offline
Aight, thanks TE. I can once again sign my commits without being bothered by their horrible pinentry system .
Offline
In case you didn't notice: Doesn't seem like a bug, but like a new way of doing things -- an option to imitate 1.4 behaviour is provided: https://bugs.g10code.com/gnupg/msg5580
Last edited by ball (2014-11-27 12:48:43)
Offline
yeah, got that email -- I'm spinning up a VM in Virtualbox to try it out, don't want to risk my real GPG yet (again) until we figure it out exactly. I'm hoping these can be set in ~/.gnupg/gpg.conf and gpg-agent.conf so that existing code doesn't need changed. I'm using all this to encrypt my backups with duply/duplicity, risking breakage is not fun at all.
Offline
I've added these in my test VM (after copying over my real ~/gnupg/):
$ grep loop ~/.gnupg/*.conf
~/.gnupg/gpg-agent.conf:allow-loopback-pinentry
~/.gnupg/gpg.conf:pinentry-mode loopback
...and tested these - seem to be working:
$ echo XXXX | /usr/bin/gpg --sign --default-key 15DE5E40 --passphrase-fd 0 --batch -r 15DE5E40 -o /tmp/test.enc -e /usr/bin/ls
$ gpg test.enc
gpg: Good signature from ... [ultimate]
$ gpg --gen-key
pub rsa2048/243C1EBF 2014-11-27
sub rsa2048/EB49D024 2014-11-27
$ gpg --edit-key 243C1EBF
gpg> trust
gpg> sign
It's looking good in this test VM. Any other operations someone wants me to try while I have this VM up? I'm not sure what other things setting this 'loopback' config on will affect...
Offline
Note that the upstream authors have recommended against setting '~/.gnupg/gpg.conf:pinentry-mode loopback':
If you add it to gpg.conf the Pinentry won't be used and there are fir sure cases where things won't work. In an unattended use I can't see a problem right now.
I've filed an upstream with duply to bring awareness of the change (https://sourceforge.net/p/ftplicity/bugs/76/). Further testing in my VM shows the solution works for me in several situations, I'll mark this thread Solved. I think they made this way too complicated to feed in a password during scripts in GPG 2.1, but it is what it is.
Offline
I've closed out the Arch bug report and GnuPG bug report - I tried to describe the change with a new wiki subsection:
https://wiki.archlinux.org/index.php/Gn … passphrase
Please clean it up with more info from your own testing/usage scenarios. I can only confirm duply/duplicity are working...
Offline
Wow this is weird, at least I can sign emails again. Thank you TE for clearing this up. It didn't work at first until I edited my config files. That wasn't mentioned on the mailing list.
Offline
This is actually really nice. Finally I don't have to use pinentry-curses. I just wish it had been announced more vocally. Sorry for the outburst.
Offline