Bug 620282
Summary: | can't decrypt stdin without X | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ian Donaldson <iand> |
Component: | gnupg2 | Assignee: | Rex Dieter <rdieter> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | iand, nalin, rdieter, stephent98, tmraz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-01 13:22:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ian Donaldson
2010-08-02 00:15:39 UTC
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. |