Bug 620282 - can't decrypt stdin without X
Summary: can't decrypt stdin without X
Alias: None
Product: Fedora
Classification: Fedora
Component: gnupg2   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-02 00:15 UTC by Ian Donaldson
Modified: 2011-06-01 13:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-01 13:22:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ian Donaldson 2010-08-02 00:15:39 UTC
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):


$ rpm -q --whatprovides /usr/bin/gpg

How reproducible:


Steps to Reproduce:
1. gpg -d < file
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.

Comment 1 Tomas Mraz 2010-08-02 13:45:17 UTC
Does the --batch option help?

Comment 2 Ian Donaldson 2010-08-02 14:07:41 UTC
--batch seems to produce no difference in behaviour to the above hang.
The errors are all the same as the above.

Comment 3 Tomas Mraz 2010-08-02 14:16:03 UTC
--batch --pasphrase-fd 0 --decrypt should work.

Comment 4 Ian Donaldson 2010-08-02 21:58:29 UTC
$ 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.

Comment 5 Steve Tyler 2010-08-21 14:04:53 UTC
(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."


$ rpm -qa 'gnupg*'


Comment 6 Bug Zapper 2011-06-01 12:18:53 UTC
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: 

Comment 7 Ian Donaldson 2011-06-01 13:19:22 UTC
FC14's 'gpg' is fine.  Its from 

$ rpm -q --whatprovides /usr/bin/gpg

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

Comment 8 Rex Dieter 2011-06-01 13:22:18 UTC
Thanks, looks like restoring gnupg(1) did the trick then.

Note You need to log in before you can comment on or make changes to this bug.