GNU bug report logs -
#43302
password shows up in shell buffer (27.1)
Previous Next
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.
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):
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):
>>>>> 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):
[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):
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: 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.