If pinentry-ncurses is invoked while in an emacs buffer then the results are as follows: 1. the screen is garbled 2. text entered into pinentry shows up as plain text 3. a kind of "denial of service" More on point 3: The entire buffer must be killed, but pinentry does not die (from process list). You cannot start another login session if you're possibly invoking pinentry from your .bash* (eg. from keychain). I had to kill pinentry from another emacs shell buffer (emacs shell buffers are not login shells). I think the problem might be inherent to pinentry. It might also be related to Bug 119356. Ideally, if the environment contains "EMACS=t", then pinentry should instead send the string "Pass phrase: " (or anything that matches the regexp in emacs's comint-password-prompt-regexp variable (eg. \\(\\([Oo]ld \\|[Nn]ew \\|'s \\|login \\|Kerberos \\|CVS \\|UNIX \\| SMB \\|^\\)[Pp]assword\\( (again)\\)?\\|pass phrase\\|\\(Enter\\|Repeat\\|Bad\\) passphrase\\)\\(?:, try again\\ \)?\\(?: for [^:]+\\)?:\\s *\\'"). When Emacs sees text matching comint-password-prompt-regexp in the shell buffer, it switches to read unechoed characters from the minibuffer (printed with *'s etc.), which is great. Then it sends the string it collected to the sub process but without echoing it.
Where I wrote: More on point 3: The entire buffer must be killed, but pinentry does not die (from process list). That part is actually incorrect. Sending ^C does actually kill it in the emacs buffer. The rest of the problems described are still accurate though.
Looking at the source for pinentry, looks like this would be resolves with significant work upstream, so perhaps this bug should be closed here since it isn't really our problem
invalidating own bug.
