FS#69013 - core/gnupg 2.2.25-1: Console password prompt breaks tmux

Attached to Project: Arch Linux
Opened by Tassilo Horn (tsdh) - Thursday, 17 December 2020, 10:30 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 05 January 2021, 15:22 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

I'm ssh-ed to some remote machine running an up-to-date arch install. There, I do:

$ tmux # fire up a new tmux session
$ gpg --decrypt --for-your-eyes-only .authinfo.gpg # decrypt pgp encrypted file

I get the password prompt shown in the attached screenshot.

After typing some characters of the passwort (or even just waiting a bit), tmux exits with [server exited unexpectedly] and I'm back at the non-tmux shell prompt. When I type there, it'll sometimes come out as the char I've type or as *, i.e., the password thingy is still active. When hitting RET, the password dialog re-appears. Typing again causes the same behavior.

When I hit RET followed by possibly "tmux a", I can get back into my tmux session where of course the gpg command has failed to read the password.

The gpg command and password prompt works without issues when executing it at a tty directly, i.e., not inside tmux.

This problem started occurring very recently, so it's probably caused by some package update.

Additional info:
* core/gnupg 2.2.25-1
* community/tmux 3.1_c-1
This task depends upon

Closed by  Doug Newgard (Scimmia)
Tuesday, 05 January 2021, 15:22 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Config issue
Comment by Tassilo Horn (tsdh) - Sunday, 20 December 2020, 17:12 GMT
Now I've tried this:

$ mv /usr/sbin/pinentry /usr/sbin/pinentry.bak
$ ln -s /usr/sbin/pinentry-tty /usr/sbin/pinentry

I've had the very same issue, i.e., being dropped out of my tmux session with keyboard input somehow still being intercepted. So it doesn't seem to be an issue with the pinentry implementation - both tty and curses exhibit that issue.
Comment by Tassilo Horn (tsdh) - Sunday, 27 December 2020, 09:25 GMT
Seems like I forgot the mentioned screenshot, so here it is.
   Screenshot-2020-12-27_102231.... (42.3 KiB)
Comment by Tassilo Horn (tsdh) - Sunday, 03 January 2021, 12:09 GMT
I've also created a screencast showing the complete failing procedure: https://www.tsdh.org/tmux-gnupg-password-breakage.mp4
Comment by Tassilo Horn (tsdh) - Monday, 04 January 2021, 18:58 GMT
I've found a workaround. The problem doesn't happen when I use mosh 1.3.2-12 to connect to the remote machine instead of openssh 8.4p1-2.
Comment by Tassilo Horn (tsdh) - Tuesday, 05 January 2021, 15:16 GMT
I finally found the culprit. I used to setup the GnuPG agent in ~/.profile including the lines:

GPG_TTY=$(tty)
export GPG_TTY

So after ssh-ing, it was set to /dev/pts/0. My fish config ensures that ~/.profile isn't sourced more than once so that I don't get duplicates in PATH and friends. So when starting tmux, tty would return /dev/pts/1 but GPG_TTY was still /dev/pts/0.

I have no clue why it worked with bash (or when connecting with mosh instead of ssh), but now I re-set GPG_TTY to the current tty in my ~/.config/fish/config.fish and pinentry works again.

Loading...