GNU bug report logs - #43302
password shows up in shell buffer (27.1)

Previous Next

Package: emacs;

Reported by: Nicholas Drozd <nicholasdrozd <at> gmail.com>

Date: Thu, 10 Sep 2020 00:41:01 UTC

Severity: normal

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43302 in the body.
You can then email your comments to 43302 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#43302; Package emacs. (Thu, 10 Sep 2020 00:41:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicholas Drozd <nicholasdrozd <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 10 Sep 2020 00:41:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicholas Drozd <nicholasdrozd <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: password shows up in shell buffer (27.1)
Date: Wed, 9 Sep 2020 19:40:04 -0500
The password input starring in shell mode seems to have changed in 27
from 26 to become more lax. Here is a small shell script:

#+begin_src shell
echo "Password:"
read -sr password
#+end_src

In 26, it looks like this when I run it:

#+begin_quote
$ bash password.sh
Password:
$
#+end_quote

The password is input starred into the minibuffer, not in the shell
buffer itself.

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 have tried on both Linux and Mac.

This may be related to
https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00028.html




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43302; Package emacs. (Thu, 10 Sep 2020 12:28:02 GMT) Full text and rfc822 format available.

Message #8 received at 43302 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Nicholas Drozd <nicholasdrozd <at> gmail.com>
Cc: 43302 <at> debbugs.gnu.org
Subject: Re: bug#43302: password shows up in shell buffer (27.1)
Date: Thu, 10 Sep 2020 14:26:56 +0200
>>>>> On Wed, 9 Sep 2020 19:40:04 -0500, Nicholas Drozd <nicholasdrozd <at> gmail.com> said:

    Nicholas> This may be related to
    Nicholas> https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00028.html

The patch for that is in master, not in emacs-27, so something else is
going on.

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43302; Package emacs. (Wed, 27 Jan 2021 06:21:02 GMT) Full text and rfc822 format available.

Message #11 received at 43302 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nicholas Drozd <nicholasdrozd <at> gmail.com>
Cc: 43302 <at> debbugs.gnu.org
Subject: Re: bug#43302: password shows up in shell buffer (27.1)
Date: Wed, 27 Jan 2021 07:20:39 +0100
[Message part 1 (text/plain, inline)]
Nicholas Drozd <nicholasdrozd <at> 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:

[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
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

bug closed, send any further explanations to 43302 <at> debbugs.gnu.org and Nicholas Drozd <nicholasdrozd <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 27 Jan 2021 06:21:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43302; Package emacs. (Fri, 12 Feb 2021 20:51:02 GMT) Full text and rfc822 format available.

Message #16 received at 43302 <at> debbugs.gnu.org (full text, mbox):

From: Nicholas Drozd <nicholasdrozd <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43302 <at> debbugs.gnu.org
Subject: Re: bug#43302: password shows up in shell buffer (27.1)
Date: Fri, 12 Feb 2021 14:50:01 -0600
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 <at> gnus.org> wrote:
>
> Nicholas Drozd <nicholasdrozd <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43302; Package emacs. (Sat, 13 Feb 2021 07:24:01 GMT) Full text and rfc822 format available.

Message #19 received at 43302 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicholas Drozd <nicholasdrozd <at> gmail.com>
Cc: larsi <at> gnus.org, 43302 <at> debbugs.gnu.org
Subject: Re: bug#43302: password shows up in shell buffer (27.1)
Date: Sat, 13 Feb 2021 09:23:49 +0200
> From: Nicholas Drozd <nicholasdrozd <at> gmail.com>
> Date: Fri, 12 Feb 2021 14:50:01 -0600
> Cc: 43302 <at> debbugs.gnu.org
> 
> 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.)

I'd start at comint-watch-for-password-prompt.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 13 Mar 2021 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 16 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.