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


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

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




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.