bug#30190: 27.0.50; term run in line mode shows user passwords

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 30190@debbugs.gnu.org,  rms@gnu.org,  npostavs@users.sourceforge.net
> Date: Sat, 10 Mar 2018 17:52:25 +0900
> 
> > You'll have to convince me that
> > 1. we really cannot live with the bug until Emacs 27.
> You can live with it.  Many people can live with it.  Indeed, this bug
> has been there since the addition of this lib. several releases before.
> 
> I cannot live with it;  any user using 'term.el' in line mode
> should not live with it.  It's a security issue and should be
> taken seriously.  IMO, Emacs sends the wrong message delivering a new
> release with a security bug, having a simple and well understood
> fix for it.
> 
> Last week one of my teachers saw my email password in my screen.  He
> was very serious about that, and requested me to please, _inmediately_
> change my password.  Ciertanly, many developers care about these kind
> of issues.
> 
> >2. all of that is needed to fix the bug exposed by your recipe.
> The patch is crafted so that:
> * It just modifies one file, i.e. term.el.
> * Don't stablishes new dependencies between comint.el and term.el.
> 
> With that in mind, you can how simple is the patch.  It _just_ copy
> step by step what it is done in comint.el:

Here's what bothers me about the patch:

 . it installs the filter even when term.el is not in line 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?

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?