bug#43302: password shows up in shell buffer (27.1)

[Nicholas Drozd <nicholasdrozd@gmail.com>]

Your workaround works, but the fact remains that the behavior changed
between 26 and 27, and it changed in a way that I as a user found
disturbing. I switched to 27, and on my first session I ran a script
that queried for a password. Previously Emacs had hid the password as
I expected, but in 27 my password was unexpectedly exposed on the
screen. It's a bug, and it should be fixed. (I would try to fix it
myself, but I have no idea where to start. With a little guidance I
could take a crack at it.)

Alternatively, it could have been an intentional change in behavior.
In that case it should be noted in NEWS. Something like: "shell-mode:
Passwords are protected in fewer circumstances." But that sounds more
like antinews than news.

On Wed, Jan 27, 2021 at 12:20 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Nicholas Drozd <nicholasdrozd@gmail.com> writes:
>
> > In 27, it looks like this:
> >
> > #+begin_src
> > $ bash password.sh
> > Password:
> > asdf
> > $
> > #+end_src
> >
> > The password (=asdf=) gets input directly into the shell buffer, unstarred.
>
> I'm able to reproduce the behaviour in Emacs 27 and 28.  However, if you
> say this:
>
> echo -n "Password:"
> read -sr password
>
> Then Emacs will *** the password in the minibuffer, so comint only
> triggers the password-reading behaviour if there's no newline there.
>
> Now, Emacs 26 did handle this...  somewhat:
>
>
> That is, it would include the newline in the prompt.
>
> So...  I think basically this works as intended currently: comint only
> triggers the password-reading behaviour if the prompt is on the current
> line (i.e., without a newline), so I'm closing this bug report.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no