Description of problem: gpg -d < file previously prompted on the /dev/tty for a passphrase in prior Fedora's, but now it insists on contacting an agent and if you don't have DISPLAY set, it just hangs. Version-Release number of selected component (if applicable): FC13 $ rpm -q --whatprovides /usr/bin/gpg gnupg2-2.0.14-2.fc13.i686 How reproducible: 100% Steps to Reproduce: 1. gpg -d < file 2. 3. Actual results: $ gpg -d < blah.gpg You need a passphrase to unlock the secret key for user: "XXXX ..." 1024-bit ELG key, ID 3E4C54A6, created 2003-03-31 (main key ID B20F9BBF) can't connect to `/home/XXXX/.gnupg/S.gpg-agent': No such file or directory pinentry-qt4: no LC_CTYPE known - assuming UTF-8 pinentry-qt4: no LC_CTYPE known - assuming UTF-8 pinentry-qt4: no LC_CTYPE known - assuming UTF-8 pinentry-qt4: no LC_CTYPE known - assuming UTF-8 gpg: signal Interrupt caught ... exiting Expected results: a prompt on /dev/tty for the passphrase with echo disabled, as before Additional info: Just discovered that a variant of this does work... gpg -d file which prompts using a curses app. Seems to me that gpg should do an isatty(0) test and only fire up the curses app if fd#0 its a tty (ie: not a file), else open /dev/tty and do the old non-curses based passphrase prompting method. Looking at the FC13 gpg man page, the '-d' option is still documented to use STDIN for the file to decrypt if no file is supplied, so this new key fetching behaviour is clearly broken and contrary to the man page.
Does the --batch option help?
--batch seems to produce no difference in behaviour to the above hang. The errors are all the same as the above.
--batch --pasphrase-fd 0 --decrypt should work.
$ gpg --batch --passphrase-fd 0 --decrypt < blah.gpg gpg: no valid OpenPGP data found. gpg: decrypt_message failed: Unknown system error Doesn't work as its trying to read the passphrase and the cyphertext from the same fd. $ gpg --batch --passphrase-fd 0 --decrypt blah.gpg kinda works except that it doesn't turn off echo, but I'm not concerned with that. I'm concerned with the backwards compatability being broken. ie: gpg -d < blah.gpg both decrypted and turned off echo for the passphrase prior to FC13.
(In reply to comment #4) ... > I'm concerned with the backwards compatability being broken. gnupg2 broke a shell script of mine. > ie: gpg -d < blah.gpg > both decrypted and turned off echo for the passphrase prior to FC13. The good news is that gnupg (1.4.10) with this functionality has been restored to F13: "This re-introduces the 1.4.10 version of gnupg. It takes over control of the gpg binaries which were symlinks in previous gnupg2 releases. gnupg2 retains control of the gpg2 binaries so that they can be installed in parallel." https://admin.fedoraproject.org/updates/gnupg2-2.0.14-6.fc13,gnupg-1.4.10-2.fc13 $ rpm -qa 'gnupg*' gnupg-1.4.10-2.fc13.x86_64 gnupg2-2.0.14-6.fc13.x86_64 Thanks!
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
FC14's 'gpg' is fine. Its from $ rpm -q --whatprovides /usr/bin/gpg gnupg-1.4.11-2.fc14.i686 However FC14 gpg2 has the above mentioned problem, and my original report used gpg from gnupg2 package; presumably the default 'gpg' has shifted back to the 'gnupg' package since then. I'm not so worried about that; gpg is what I use. $ rpm -q --whatprovides /usr/bin/gpg2 gnupg2-2.0.16-3.fc14.1.i686
Thanks, looks like restoring gnupg(1) did the trick then.