Bug 969825 - gpg fails to reset terminal, causing arrow keys in `less` to fail when piped
gpg fails to reset terminal, causing arrow keys in `less` to fail when piped
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pinentry (Show other bugs)
6.4
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Boris Ranto
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-02 11:17 EDT by Adam Carheden
Modified: 2015-10-20 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-20 11:28:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Carheden 2013-06-02 11:17:52 EDT
Description of problem:
gpg fails to reset terminal, causing arrow keys in `less` to fail when piped

Version-Release number of selected component (if applicable):
$ rpm -q gnupg2
gnupg2-2.0.14-4.el6.x86_64


How reproducible: Always


Steps to Reproduce:
1. unset DISPLAY
2. gpg -d myfile.gpg | less
3. Press arrow keys. Note that they don't work
4. Type '!reset'. Note that arrow keys now work.

Actual results:
Arrow keys don't work in `less` until terminal is reset.


Expected results:
Arrow keys should work.


Additional info:
`gpg -d myfile.gpg | less` works fine in Debian Lenny, Squeeze and Wheezy
Comment 2 Tomas Mraz 2013-06-03 05:00:44 EDT
I suppose `gpg -d myfile.gpg | less` on Debian does not use gnupg2 and thus it does not use gpg-agent and pinentry to enter the password.
Comment 3 RHEL Product and Program Management 2013-10-13 19:31:40 EDT
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 unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 4 Boris Ranto 2015-10-20 11:28:24 EDT
I played with this a bit and I could hit this also in rhel 7 and even latest range of fedoras. I also tried using the latest upstream version (0.9.6) and it is not fixed there either.

The reason for this to happen is that two ncurses programs access the same tty session (pinentry-curses and less). These two programs do run in parallel and as such can set/unset the tty environment in numerous ways (thanks to the parallelism).

I don't believe we can fix this properly without some kind of sophisticated locking mechanism being imposed on ttys (per request) and that might require changes to all programs that use ncurses/fiddle with the tty environment settings (they would have to check at each write whether they can write to their tty -- whether the tty was not locked by some other process). As such this is definitely not a rhel 6 candidate bz and I'm closing this bz, at least for rhel 6. Feel free to reopen if you have an idea how to fix this in a more sane and less invasive way.

A workaround would be to use a dumber version of pinentry that does not use ncurses/fiddle with the environment so much like pinentry-tty (which is not available in rhel, though) or use a GUI (gtk/qt) version of pinentry.

btw: A more reliable reproducer for this would be e.g.

echo -e "OPTION ttyname $(tty)\ngetpin" | pinentry-curses | less

as gpg can leverage the use of pinentry in some cases (especially in more recent systems).

btw2: The gpg command in debian does in fact use a dumber password input method which does not require any tty environment fiddling (the same goes for e.g. fedora).

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