Bug 662770
Summary: | gpg --gen-key fails if pinentry GUI is not installed. | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jeff Laughlin <jeff.laughlin> | |
Component: | pinentry | Assignee: | Boris Ranto <branto> | |
Status: | CLOSED ERRATA | QA Contact: | Martin Žember <mzember> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.0 | CC: | branto, cww, daniel_johnson1, ebenes, mzember, ovasik, pvrabec, sreber, tmraz, tscherf | |
Target Milestone: | rc | Keywords: | Patch | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | pinentry-0.7.6-7.el6 | Doc Type: | Bug Fix | |
Doc Text: |
Cause: The auto-detection of pinentry to-be-run binary failed in few cases.
Consequence: The pinentry wrapper tried to launch pinentry-gtk even if it was not installed.
Fix: Update the pinentry wrapper to handle the corner cases better and fall back to pinentry-curses in this case.
Result: The pinentry wrapper falls back to pinentry-curses in this case.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1231229 (view as bug list) | Environment: | ||
Last Closed: | 2015-03-30 08:09:17 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1075802, 1159820 |
Description
Jeff Laughlin
2010-12-13 20:17:27 UTC
Do you have $DISPLAY set? Does 'export PINENTRY_BINARY="/usr/bin/pinentry-curses"' work as a workaround? Yes it does, thanks. The curses interface appears, takes my password, and gpg moves on to key generation as expected. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. This should be solved in the pinentry helper to use the ncurses interface if the GUI is not installed even if the $DISPLAY is set if running on a terminal. It should be noted however that such behaviour trades convenience for security. That is because an X window provided by GTK/QT pinentries is able to grab input globally, whereas pinentry-curses is not. It would be therefore possible for a malicious application to hijack and record passphrase being given to pinentry curses in X terminal. Moreover pinentry has no simple way to know if it's being run on a terminal or not. That is because gnupg redirects stdin/out of child pinentry process into a pipe. There are a few partial solutions and/or workarounds: 1. Manually set PINENTRY_BINARY as was suggested above (or set it in ~/.gnupg/gpg-agent.conf) 2. Install graphical pinentry if you are using X11 forwarding 3. Unset DISPLAY prior to working with gnupg over SSH 4. It would certainly help if gnupg tested that pinentry works in the beginning of any action which might require pinentry input. This would help users avoid having to go through filling in information only to be told in the end that it failed during last step. But this is not directly related to this bug Stanislav, feel free to close this bug as WONTFIX or NOTABUG given the available workarounds. There are workarounds, however users are repeatedly hitting this issue so some improvement for handling this situation should be found. There should certainly be a better way for gnupg to handle pinentry failure in a more informative way. "No pinentry" is extremely frustrating message when you know you have pinentry installed. Same goes for using gnupg in graphical applications. It can result in silent failures where there is no clear message for the user (i.e. he/she will not even see the "Please install pinentry-gui"). This falls under things which should obviously be handled with upstream though. While helping a customer with this issue we were still unable to get pinentry-curses to work, and eventually were led to a bug that prevents pinentry-curses from working if you are su'd instead of properly logged in as the end user: https://bugs.g10code.com/gnupg/issue1391 Customer was running RHEL v6.5 x64. pinentry v0.7.6-6 and gnupg2 v2.0.14-6. dist-git commits related to build pinentry-0.7.6-7.el6: http://pkgs.fedoraproject.org/cgit/cgit/rpms/pinentry.git/commit/?h=rhel-6.7&id=3bef01a095e14cd5b939627f35276e9ec4130f3d http://pkgs.fedoraproject.org/cgit/cgit/rpms/pinentry.git/commit/?h=rhel-6.7&id=3c43f22e43747b9ca16793539730ab39432d0921 @Daniel: I was able to hit that issue but unlike the report that you referenced I could not reproduce it when su'd to root. I had to be su'd to another regular user for it to reproduce. However, this has got nothing to do with this issue so feel free to open a separate bz for the issue. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0755.html |