GNU bug report logs - #30190
27.0.50; term run in line mode shows user passwords

Previous Next

Package: emacs;

Reported by: Tino Calancha <tino.calancha <at> gmail.com>

Date: Sun, 21 Jan 2018 12:17:02 UTC

Severity: normal

Tags: confirmed, fixed, security

Found in versions 27.0.50, 24.3

Fixed in version 26.2

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Tino Calancha <tino.calancha <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30190 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net, rms <at> gnu.org, Tino Calancha <tino.calancha <at> gmail.com>
Subject: bug#30190: 27.0.50; term run in line mode shows user passwords
Date: Sat, 10 Mar 2018 19:44:13 +0900 (JST)

On Sat, 10 Mar 2018, Eli Zaretskii wrote:

> Here's what bothers me about the patch:
>
> . it installs the filter even when term.el is not in line mode
It must install it by default, because the user might switch several
times between char mode <-> line mode (I do a lot).  Furthermore,
'term-watch-for-password-prompt' is a noop in char-mode.  Besides that,
'term-send-input' is just called in line-mode, so the filter would ever
be called in char mode.

> . it uses many constructs in term-password-prompt-regexp that could
>   happen in unrelated text--does that mean such unrelated text will
>   become invisible, thus making the session at least look buggy?
Regarding this issue, it would behave exactly as a dumb shell buffer does
M-x shell RET
I've never seen a bug report about that for comint.el.  If you see that, 
you should definitely open a bug report!

> The 2nd issue looks to me like a more serious one, unless I'm missing
> something.  Is it possible to make sure we don't mistakenly take some
> innocent text as a password?  Did you try in your testing to type text
> that matches this regexp, and if so, what did you see as result?

I tried just after I read your message.  I don't find a problem.  And as
a pointed out above, it uses the same mechanism as comint.el (e.g. 
dumb shell buffers), so I don't think you should worry about it.

> If anyone can show just cause why this patch cannot lawfully be joined
> together in Emacs-26 branch, let them speak now or forever hold their
> peace.
I have booked all the celebration... :-S I hope I can marriage soon ;-)




This bug report was last modified 6 years and 357 days ago.

Previous Next


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