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

Previous Next

Full log

Message #65 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 12:25:08 +0200

> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 30190 <at> debbugs.gnu.org,  rms <at> gnu.org,  npostavs <at> 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?

Previous Next

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