Bug 969825

Summary:	gpg fails to reset terminal, causing arrow keys in `less` to fail when piped
Product:	Red Hat Enterprise Linux 6	Reporter:	Adam Carheden <acarheden>
Component:	pinentry	Assignee:	Boris Ranto <branto>
Status:	CLOSED CANTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.4
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-20 15:28:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Carheden 2013-06-02 15:17:52 UTC

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 09:00:44 UTC

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 Program Management 2013-10-13 23:31:40 UTC

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 15:28:24 UTC

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).