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

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sat, 10 Mar 2018 19:44:13 +0900 (JST)
> cc: Tino Calancha <tino.calancha@gmail.com>, 30190@debbugs.gnu.org, 
>     rms@gnu.org, npostavs@users.sourceforge.net
> 
> > . 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.

Can you please show some examples?  First, what text triggers the new
functionality correctly, when the user types a password at some
relevant prompt, and then what happens when an unrelated prompt is
taken by the filter function as a prompt for a password.  I'd like to
understand better what happens in each case.

> 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.

Sorry, this doesn't really tell me enough, because I don't think I
understand the relevance of dumb shells and comint to the issue at
hand.

Thanks.