Red Hat Bugzilla – Bug 1058972
pinentry-curses mixes control pipe and TTY in non-interactive setups
Last modified: 2016-11-03 21:04:43 EDT
Version-Release number of selected component (if applicable): pinentry-0.8.1-12.el7.x86_64 Steps to Reproduce: $ (echo 'GETPIN'; sleep 3600) | pinentry-curses |& cat -v Actual results: See an "OK your orders please line, followed by terminal control sequences Expected results: See no control sequences sent to the control pipe, and fail cleanly. This seems to be the underlying cause of the breakage in non-interactive setups. Ordinarily gpg-agent sends "OPTION ttyname" to a TTY to be used, but that AFAICS only happens if one of the standard file descriptors is a TTY; if it isn't (e.g. during a mock build), no OPTION ttyname is used, and pinentry defaults to using stdin/stdout - both writing escape sequences where the agent is expecting a response, and waiting for the PIN input from the agent's command input. The same problem happens for pinentry-gtk2 when it falls back to the curses backend. The full reproducer mirroring a non-interactive situation, starting e.g. from a terminal in X: $ pkill gpg $ rm ~/.gnupg/S.gpg-agent $ GPG_AGENT_INFO= DISPLAY= gpg2 -c -o test </dev/null 2>&1 |cat # ... will hang, with pinentry-* actually taking 100% CPU because read(0) returns "0" and pinentry doesn't interpret this as a reason to give up.
Created attachment 863242 [details] proposed patch I have sent attached patch to upstream, however I am not 100% sure about this. Pinentry has quite a few interactions around assuan protocol and it's entirely possible the patch would break some of those use cases. Otherwise I am not sure why wouldn't upstream do this change long time ago.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
The patch is available upstream http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=3803fd15942f2f25108e400be6cd6faef791c8f7 and is fairly straight-forward. We should aim this bz at 7.3. (fasttrack should be ok)
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-2016-2226.html