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

Previous Next

Full log

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

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: Re: bug#30190: 27.0.50; term run in line mode shows user passwords
Date: Sun, 11 Mar 2018 20:02:08 +0900 (JST)

On Sat, 10 Mar 2018, Eli Zaretskii wrote:

>> 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 22:17:13 +0900
>>
>> Bad behaviour:
>> [sudo] password for foo:
>> # This throws 'command not found' BUT _sometimes_ you are prompted for
>> # your password in the minibuffer.
>> # Note: This happens in a dumb shell buffer as well.
>
> What happens if you have a command (say, a shell script) that prompts
> for something that is not a password with a prompt that starts with
> text that matches the regexp -- what is the behavior then, after your
> changes?  What I see here is that the filter redirects that to the
> minibuffer, and doesn't show the text I type, unlike what happened
> before your changes.  Wouldn't that look like a bug and cause bug
> reports?
IMO, if the regexp is matched, then you must be prompt in the minibuffer.
It is the responsability of the person writing the script to chose
sensible variable names, and right prompts.  If I am prompted and I
expect I shouldn't, then what is happening is that I wrote a poor script.


> I'm also worried by the "_sometimes_" part: does it mean the behavior
> is not deterministic?  Why?
This is not crafted from me; it how it's designed in comint.el.  It must
mean that the long strings are send in chunks.  That would be a totally
independent bug report.  Actually if it's a bug or not is arguable:
don't think it is, at least until we canot fire it in a more sensical
example that the toy string:
[sudo] password for:

>> Whatever misfunction of my patch should happen in a dumb shell buffer
>> started with:
>> M-x shell
>
> Yes, but two wrongs don't make a right...
There levels of wrongs: showing a password is simply too wrong.

And 2 wrongs, sharing same code give more testers, i.e., more chances 
to detect the anomaly to finally fix it.

Anyway I already have patched my local sources and I am 
happy with that.  I don't have time to argue further, so I give up.
My team is pushing me to focus in our project.

Previous Next

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