GNU bug report logs - #17839
24.4.50; read-passwd echoes password input in non-interactive sessions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17839 in the body.
You can then email your comments to 17839 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; read-passwd echoes password input in non-interactive sessions
Date: Mon, 23 Jun 2014 15:51:37 +0200

In a non-interactive session, i.e. "emacs -Q --batch …", `read-passwd'
currently echoes the password input on the TTY.

I would expect `read-passwd' to suppress input echo while reading a
password, like suo, sudo, SSH, GPG and similar programs do.

In my opinion, the current behaviour is harmful, because from their
experience with these programs user will likely expect that input
following a "Password: " prompt is hidden, and thus may accidentally
expose their password, being unaware that Emacs behaves differently.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Mon, 23 Jun 2014 17:46:55 +0200

Sebastian Wiesner <swiesner <at> lunaryorn.com> writes:

> In a non-interactive session, i.e. "emacs -Q --batch …", `read-passwd'
> currently echoes the password input on the TTY.

Batch mode isn't designed for interaction.  It uses standard I/O,
oblivious to who is consuming the input.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Mon, 23 Jun 2014 18:52:34 +0200

Am 23.06.2014 um 17:46 schrieb Andreas Schwab <schwab <at> suse.de>:

> Sebastian Wiesner <swiesner <at> lunaryorn.com> writes:
> 
>> In a non-interactive session, i.e. "emacs -Q --batch …", `read-passwd'
>> currently echoes the password input on the TTY.
> 
> Batch mode isn't designed for interaction. It uses standard I/O,
> oblivious to who is consuming the input.

In this case `read-passwd’ should at least signal an error when called in non-interactive mode, and have a warning in its doctoring.  

Currently it is simply insecure in non-interactive mode, and neither its docstring nor the Emacs Lisp manual document that the password is exposed when called in non-interactive mode.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Tue, 24 Jun 2014 14:41:51 -0400

Sebastian Wiesner wrote:

>> Batch mode isn't designed for interaction. It uses standard I/O,
>> oblivious to who is consuming the input.
>
> In this case `read-passwd' should at least signal an error when called
> in non-interactive mode,

I think that would be overkill.

> and have a warning in its doctoring.

A notice perhaps.

> Currently it is simply insecure in non-interactive mode, and neither
> its docstring nor the Emacs Lisp manual document that the password is
> exposed when called in non-interactive mode.

It's in the manual section on minibuffer input, and in batch mode there
is no minibuffer. For example, read-file-name doesn't offer completion
in batch-mode. It doesn't provide history. ctrl-k doesn't work. Etc.
I see no point in mentioning these things in the doc-string of every
function that uses the minibuffer.

But yes, read-passwd is a slightly special case and could stand to
mention batch mode in its doc.

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 00:55:53 +0200

Am 24.06.2014 um 20:41 schrieb Glenn Morris <rgm <at> gnu.org>:

> Sebastian Wiesner wrote:
> 
>>> Batch mode isn't designed for interaction. It uses standard I/O,
>>> oblivious to who is consuming the input.
>> 
>> In this case `read-passwd' should at least signal an error when called
>> in non-interactive mode,
> 
> I think that would be overkill.

I think that `read-passwd’ is a special case, because it *leaks a secret* when used in non-interactive mode, and the fact that it does is not immediately obvious.  To learn this *in advance*, that is, before actually using this function in non-interactive code, one has to conclude from some rather abstract descriptions of Emacs’ behavior in the Emacs manual.

>> Currently it is simply insecure in non-interactive mode, and neither
>> its docstring nor the Emacs Lisp manual document that the password is
>> exposed when called in non-interactive mode.
> 
> It's in the manual section on minibuffer input, and in batch mode there
> is no minibuffer. For example, read-file-name doesn't offer completion
> in batch-mode. It doesn't provide history. ctrl-k doesn't work. Etc.
> I see no point in mentioning these things in the doc-string of every
> function that uses the mini buffer.

There is a difference, I think.  Completion, history, C-k, etc. are not crucial for entering a file name, but hiding input is absolutely crucial to entering a password securely.  I can perfectly enter a file name without history or completion, but I cannot securely enter a password if it is shown during input.  

So `read-file-name’ works in non-interactive mode, albeit less conveniently, but `read-passwd’ arguably does not.

Pointing out that non-interactive mode isn’t designed for interaction is right, probably, but misses the point imho.

Besides, “non-interactive” is a little vague.  It’s obvious that `--batch’ is non-interactive, but is `--script’ as well?  In other languages, e.g. Python or Perl, scripts regularly do interaction, including reading passwords.

I think it’s only natural that Emacs users will try to do the same in Emacs Lisp, encouraged by the existence of `--script’, so they’ll sooner or later hit this issue.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 09:47:55 +0200

Sebastian Wiesner <swiesner <at> lunaryorn.com> writes:

> Besides, “non-interactive” is a little vague.  It’s obvious that `--batch’ is non-interactive, but is `--script’ as well?  In other languages, e.g. Python or Perl, scripts regularly do interaction, including reading passwords.

Emacs is an editor, not a script language.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 10:01:46 +0200

Andreas Schwab <schwab <at> suse.de> writes:

> Sebastian Wiesner <swiesner <at> lunaryorn.com> writes:
>
>> Besides, “non-interactive” is a little vague.  It’s obvious that
>> `--batch’ is non-interactive, but is `--script’ as well?  In other
>> languages, e.g. Python or Perl, scripts regularly do interaction,
>> including reading passwords.
>
> Emacs is an editor, not a script language.

An example where cleartext passwords are annoying me for a while is
running the test suite. Use another remote host for Tramp tests, like
this:

# env REMOTE_TEMPORARY_FILE_DIRECTORY=/sudo::/tmp make check

> Andreas.

Best regards, Michael.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 10:15:22 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> An example where cleartext passwords are annoying me for a while is
> running the test suite. Use another remote host for Tramp tests, like
> this:
>
> # env REMOTE_TEMPORARY_FILE_DIRECTORY=/sudo::/tmp make check

So use a method that does not need to ask for a password.  Both sudo and
ssh can be configured like this.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 11:20:45 +0200

Andreas Schwab <schwab <at> suse.de> writes:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> An example where cleartext passwords are annoying me for a while is
>> running the test suite. Use another remote host for Tramp tests, like
>> this:
>>
>> # env REMOTE_TEMPORARY_FILE_DIRECTORY=/sudo::/tmp make check
>
> So use a method that does not need to ask for a password.  Both sudo and
> ssh can be configured like this.

That's not the problem, I know how to configure them. I gave sudo just
as an example you could reproduce yourself.

When preparing a Tramp release, I run the Tramp test suite for about 20
different remote file names. This includes connection methods like smb,
dav(s), telnet, nc, adb. Not all of them can be configured to work
password-less.

And sometimes I also want to test the case of providing a wrong password.

> Andreas.

Best regards, Michael.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 11:26:09 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> When preparing a Tramp release, I run the Tramp test suite for about 20
> different remote file names. This includes connection methods like smb,
> dav(s), telnet, nc, adb. Not all of them can be configured to work
> password-less.

So provide it on stdin.  You want to automate your tests anyway, don't
you?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 17839 <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 11:52:24 +0200

Am 25.06.2014 um 09:47 schrieb Andreas Schwab <schwab <at> suse.de>:

> Sebastian Wiesner <swiesner <at> lunaryorn.com> writes:
> 
>> Besides, “non-interactive” is a little vague.  It’s obvious that `--batch’ is non-interactive, but is `--script’ as well?  In other languages, e.g. Python or Perl, scripts regularly do interaction, including reading passwords.
> 
> Emacs is an editor, not a script language.

I’m sorry to see that you are stuck with this view, and I am disappointed that this prevents an important issue from being addressed.  

The community has gone beyond that, and uses Emacs Lisp for other purposes as well.

Anyhow, seeing that there is no interest in fixing this issue, I see no point in continuing this discussion.  How can I unsubscribe from bugs?

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 25 Jun 2014 12:03:31 +0200

Andreas Schwab <schwab <at> suse.de> writes:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> When preparing a Tramp release, I run the Tramp test suite for about 20
>> different remote file names. This includes connection methods like smb,
>> dav(s), telnet, nc, adb. Not all of them can be configured to work
>> password-less.
>
> So provide it on stdin.  You want to automate your tests anyway, don't
> you?

It depends on timing. Sometimes, during the test runs, the password
expires and will be requested, again.

And it isn't just me. (Tramp) users are encouraged to run the test suite
in their local environment, when Tramp produces an error. 

> Andreas.

Best regards, Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 17839 <at> debbugs.gnu.org, Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50; read-passwd echoes password input in
 non-interactive sessions
Date: Wed, 25 Jun 2014 10:32:51 -0400

>> Besides, “non-interactive” is a little vague.  It’s obvious that `--batch’
>> is non-interactive, but is `--script’ as well?  In other languages,
>> e.g. Python or Perl, scripts regularly do interaction, including
>> reading passwords.
> Emacs is an editor, not a script language.

There are all kinds of reasons why the current behavior is "logical",
but indeed, it's not desirable.  Could someone install the obvious patch
in read-passwd to emit a warning (right after the prompt, so the user
will necessarily see it)?

If someone is motivated, I would even accept a patch that turns echo off
temporarily.


        Stefan

Message #46 received at 17839-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 17839-done <at> debbugs.gnu.org
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 26 Jun 2014 15:01:53 -0400

Version: 24.4

Stefan Monnier wrote:

> but indeed, it's not desirable.  Could someone install the obvious patch
> in read-passwd to emit a warning (right after the prompt, so the user
> will necessarily see it)?

Done and documented.
(Feel free to adjust wording.)

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 10 Jul 2014 16:36:43 +0200

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> If someone is motivated, I would even accept a patch that turns echo off
> temporarily.

Well, I've tried this 'cos I believe it is important. The idea is to
give the prompt in read-passwd the text property 'hide-chars. In
noninteractive mode, emacs writes "." instead of echoing the password
while typing. You can test it with

# emacs -batch -eval '(progn (message (read-string "Prompt1: ")) (message (read-passwd "Prompt2: ")) (message (read-string "Prompt3: ")))'

The patch is not perfect (it doesn't handled multi-byte chars, and I
have tested it only under Gnu/Linux), but it is a first step.

Comments?

>         Stefan

Best regards, Michael.

[diff (text/x-patch, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 10 Jul 2014 12:43:46 -0400

> Well, I've tried this 'cos I believe it is important.  The idea is to
> give the prompt in read-passwd the text property 'hide-chars.  In
> noninteractive mode, emacs writes "." instead of echoing the password
> while typing. You can test it with

I think a more idiomatic way to do that would be to use a global Lisp
var that's let-bound in read-passwd.

> +      else if (hide_chars && (c == 127)) /* DEL */
> +	{
> +	  /* Unfortunately, we cannot edit stdout.  */
> +	  // fprintf (stdout, "%c", c);
> +	  /* Hmm, this doesn't work for multi-byte characters.  */
> +	  (len > 0) && len--;
> +	}

I don't think that's worth the trouble.


        Stefan

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 10 Jul 2014 23:46:33 +0200

Am 10.07.2014 um 16:36 schrieb Michael Albinus <michael.albinus <at> gmx.de>:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
>> If someone is motivated, I would even accept a patch that turns echo off
>> temporarily.
> 
> Well, I've tried this 'cos I believe it is important.

Many thanks!

Sebastian

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 11:15:14 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Well, I've tried this 'cos I believe it is important.  The idea is to
>> give the prompt in read-passwd the text property 'hide-chars.  In
>> noninteractive mode, emacs writes "." instead of echoing the password
>> while typing. You can test it with
>
> I think a more idiomatic way to do that would be to use a global Lisp
> var that's let-bound in read-passwd.

OK. There is now `read-hide-char', which triggers it. Users can let-bind
it to the character they prefer for hiding. This will be used in
`read-passwd', choosing the default ?. if it is not let-bound already.

>> +      else if (hide_chars && (c == 127)) /* DEL */
>> +	{
>> +	  /* Unfortunately, we cannot edit stdout.  */
>> +	  // fprintf (stdout, "%c", c);
>> +	  /* Hmm, this doesn't work for multi-byte characters.  */
>> +	  (len > 0) && len--;
>> +	}
>
> I don't think that's worth the trouble.

I've removed this.

The patch is committed to the trunk as revision 117510.

>         Stefan

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Sebastian Wiesner <swiesner <at> lunaryorn.com>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 11:41:05 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> The patch is committed to the trunk as revision 117510.

Grrrr. 117511, of course.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 12:45:14 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Fri, 11 Jul 2014 11:15:14 +0200
> Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
> 	Sebastian Wiesner <swiesner <at> lunaryorn.com>
> 
> OK. There is now `read-hide-char', which triggers it. Users can let-bind
> it to the character they prefer for hiding. This will be used in
> `read-passwd', choosing the default ?. if it is not let-bound already.
> 
> >> +      else if (hide_chars && (c == 127)) /* DEL */
> >> +	{
> >> +	  /* Unfortunately, we cannot edit stdout.  */
> >> +	  // fprintf (stdout, "%c", c);
> >> +	  /* Hmm, this doesn't work for multi-byte characters.  */
> >> +	  (len > 0) && len--;
> >> +	}
> >
> > I don't think that's worth the trouble.
> 
> I've removed this.
> 
> The patch is committed to the trunk as revision 117510.

Which breaks the MS-Windows build, of course, since Windows doesn't
have termios.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 11:58:51 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Which breaks the MS-Windows build, of course, since Windows doesn't
> have termios.

That's what I have said my first message: I could test it for Gnu/Linux only.
Shall I add "#ifndef WINDOWSNT" at the usual places?

Alternatively, shall we add (disable|enable)_echo functions to sysdep.c?
While looking for the tty solution, I have also seen that there are
Windows specific functions for that.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael.albinus <at> gmx.de
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 13:03:14 +0300

> Date: Fri, 11 Jul 2014 12:45:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, swiesner <at> lunaryorn.com
> 
> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Date: Fri, 11 Jul 2014 11:15:14 +0200
> > Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
> > 	Sebastian Wiesner <swiesner <at> lunaryorn.com>
> > 
> > OK. There is now `read-hide-char', which triggers it. Users can let-bind
> > it to the character they prefer for hiding. This will be used in
> > `read-passwd', choosing the default ?. if it is not let-bound already.
> > 
> > >> +      else if (hide_chars && (c == 127)) /* DEL */
> > >> +	{
> > >> +	  /* Unfortunately, we cannot edit stdout.  */
> > >> +	  // fprintf (stdout, "%c", c);
> > >> +	  /* Hmm, this doesn't work for multi-byte characters.  */
> > >> +	  (len > 0) && len--;
> > >> +	}
> > >
> > > I don't think that's worth the trouble.
> > 
> > I've removed this.
> > 
> > The patch is committed to the trunk as revision 117510.
> 
> Which breaks the MS-Windows build, of course, since Windows doesn't
> have termios.

I installed a temporary fix, to allow the build to succeed, but it
means that currently `read-hide-char' is a no-op on MS-Windows.  Stay
tuned.

Btw, I think it's a mistake to expose termios bowels of struct
emacs_tty in minibuf.c.  I think we should move that code to a
separate function in sysdep.c, which will be called from minibuf.c.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 13:13:51 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: monnier <at> iro.umontreal.ca,  schwab <at> suse.de,  17839 <at> debbugs.gnu.org,  swiesner <at> lunaryorn.com
> Date: Fri, 11 Jul 2014 11:58:51 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Which breaks the MS-Windows build, of course, since Windows doesn't
> > have termios.
> 
> That's what I have said my first message: I could test it for Gnu/Linux only.

Testing on GNU/Linux is not the same as installing Posix-only code in
a function that is compiled on non-Posix platforms.

> Shall I add "#ifndef WINDOWSNT" at the usual places?

I already did that.

> Alternatively, shall we add (disable|enable)_echo functions to sysdep.c?

Yes, please.  This will make emulating termios for Windows easier.

Thanks.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 12:15:19 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I installed a temporary fix, to allow the build to succeed, but it
> means that currently `read-hide-char' is a no-op on MS-Windows.  Stay
> tuned.

Not fully a no-op. As side effect, you could apply your own hiding
character even in interactive mode. ?* instead of ?. as you like ...

> Btw, I think it's a mistake to expose termios bowels of struct
> emacs_tty in minibuf.c.  I think we should move that code to a
> separate function in sysdep.c, which will be called from minibuf.c.

... as I have proposed the other message as well. I will work on this;
unfortunately too much pressure on work these days. It might take some
days.

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 13:32:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> That's what I have said my first message: I could test it for Gnu/Linux only.
>
> Testing on GNU/Linux is not the same as installing Posix-only code in
> a function that is compiled on non-Posix platforms.

At least it forces answers to my "Comments?" question ...

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 14:43:10 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Alternatively, shall we add (disable|enable)_echo functions to sysdep.c?
>
> Yes, please.  This will make emulating termios for Windows easier.

I've moved the code to the new function suppress_echo_on_tty of
sysdep.c. For resetting the tty, no new function was necessary.

> Thanks.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 17:02:48 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: monnier <at> iro.umontreal.ca,  schwab <at> suse.de,  17839 <at> debbugs.gnu.org,  swiesner <at> lunaryorn.com
> Date: Fri, 11 Jul 2014 14:43:10 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Alternatively, shall we add (disable|enable)_echo functions to sysdep.c?
> >
> > Yes, please.  This will make emulating termios for Windows easier.
> 
> I've moved the code to the new function suppress_echo_on_tty of
> sysdep.c. For resetting the tty, no new function was necessary.

Thanks.  I added implementation for MS-Windows.

The result is not 100% satisfactory, as one needs to press RET twice
to finish the input, and it looks like some garbage is left in the
input buffer, since the following (normal) input gets something
strange.  A workaround is to press C-z, which produces EOF, instead of
RET, when password entry is finished.

I also needed a change in minibuf.c to end the reading loop on CR, not
just a newline.  If this is bad news for Posix platforms, we can make
that code conditional on Windows.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 16:57:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> The result is not 100% satisfactory, as one needs to press RET twice
> to finish the input, and it looks like some garbage is left in the
> input buffer, since the following (normal) input gets something
> strange.  A workaround is to press C-z, which produces EOF, instead of
> RET, when password entry is finished.

Maybe because just "\n" is sent by fprintf()? In the Windows case,
"\r\n" might be the better choice?

And maybe we must handle the case, that RET sends 2 characters, which
must be handled by a double call of getchar()?

> I also needed a change in minibuf.c to end the reading loop on CR, not
> just a newline.  If this is bad news for Posix platforms, we can make
> that code conditional on Windows.

That's OK, I've just tested.

When I've read the code of read_minibuf_noninteractive for the first
time, I've seen that just CR was used for finishing input, and I've
thought that nobody ever used this for MS Windows. This is one of the
reasons I was somehow Windows agnostic during my work.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 swiesner <at> lunaryorn.com
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Fri, 11 Jul 2014 18:46:16 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: monnier <at> iro.umontreal.ca,  schwab <at> suse.de,  17839 <at> debbugs.gnu.org,  swiesner <at> lunaryorn.com
> Date: Fri, 11 Jul 2014 16:57:40 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The result is not 100% satisfactory, as one needs to press RET twice
> > to finish the input, and it looks like some garbage is left in the
> > input buffer, since the following (normal) input gets something
> > strange.  A workaround is to press C-z, which produces EOF, instead of
> > RET, when password entry is finished.
> 
> Maybe because just "\n" is sent by fprintf()? In the Windows case,
> "\r\n" might be the better choice?

I don't think so.  The problem is not what is printed, the problem is
that the loop is not exited on the 1st RET, and in fact it looks like
nothing is returned by getchar until you press the 2nd RET.

> And maybe we must handle the case, that RET sends 2 characters, which
> must be handled by a double call of getchar()?

It doesn't look like it sends 2 characters: the next call to getchar
after exiting the loop waits for more input.

> When I've read the code of read_minibuf_noninteractive for the first
> time, I've seen that just CR was used for finishing input

You mean, just the newline, right?

> and I've thought that nobody ever used this for MS Windows.

That code worked perfectly well with cooked input mode, since then RET
is converted to a newline by the stdio machinery (as it uses text
mode).

And that just gave me an idea: switch stdin to binary when not echoing
input.  Which solved the problem of double RET (and now it's clear why
it was being eaten up).

Thanks.

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>, monnier <at> iro.umontreal.ca
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Tue, 5 Aug 2014 22:25:25 +0200

I’m sorry to bring this issue up again, but I noticed that the patch that hides input was only committed to Emacs trunk.  Would it be possible to backport this patch to the Emacs 24 branch as well, so that it the patch is also included Emacs 24.4?  

I know, Emacs is in feature freeze, and I understand that this patch required some changes to Emacs’ internals, but considering the security implications I think it’d be important to include this patch in Emacs 24.4 as well, to bring it downstream as soon as possible.

Greetings,
Sebastian Wiesner

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: schwab <at> suse.de, Eli Zaretskii <eliz <at> gnu.org>, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Wed, 06 Aug 2014 13:39:21 -0400

> I know, Emacs is in feature freeze, and I understand that this patch
> required some changes to Emacs’ internals, but considering the security
> implications I think it’d be important to include this patch in Emacs 24.4
> as well, to bring it downstream as soon as possible.

AFAIK, this problem is far from new, so there's no real hurry.
At least

   emacs23 -Q --batch --eval '(read-passwd "hello: ")'

does not hide the password for me.


        Stefan

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: schwab <at> suse.de, Eli Zaretskii <eliz <at> gnu.org>, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 07 Aug 2014 13:12:59 +0200

Am Mittwoch, 6. August 2014, 13:39:21 schrieb Stefan Monnier:
> > I know, Emacs is in feature freeze, and I understand that this patch
> > required some changes to Emacs’ internals, but considering the security
> > implications I think it’d be important to include this patch in Emacs 24.4
> > as well, to bring it downstream as soon as possible.
> 
> AFAIK, this problem is far from new, so there's no real hurry.

I know, but I'd argue that since it's kind of a security issue, albeit small, 
it deserves a timely fix.  YMMV, though, and I'm ok with either decision you 
make.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: schwab <at> suse.de, Eli Zaretskii <eliz <at> gnu.org>, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 07 Aug 2014 09:01:49 -0400

> I know, but I'd argue that since it's kind of a security issue, albeit
> small,  it deserves a timely fix.  YMMV, though, and I'm ok with
> either decision you  make.

I'm OK with installing a fix for it in emacs-24, but the fix we have in
trunk is not "obviously safe" enough to be appropriate for emacs-24.
And I think the warning we added to emacs-24 is a sufficient (tho not
ideal) stop-gap for emacs-24.

IOW feel free to send a safer patch (with corresponding copyright
paperwork, of course),


        Stefan

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: schwab <at> suse.de, Eli Zaretskii <eliz <at> gnu.org>, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 7 Aug 2014 15:12:27 +0200

Am 07.08.2014 um 15:01 schrieb Stefan Monnier <monnier <at> iro.umontreal.ca>:

>> I know, but I'd argue that since it's kind of a security issue, albeit
>> small,  it deserves a timely fix.  YMMV, though, and I'm ok with
>> either decision you  make.
> 
> I'm OK with installing a fix for it in emacs-24, but the fix we have in
> trunk is not "obviously safe" enough to be appropriate for emacs-24.

I know.

> And I think the warning we added to emacs-24 is a sufficient (tho not
> ideal) stop-gap for emacs-24.

Ok.

> 
> IOW feel free to send a safer patch (with corresponding copyright
> paperwork, of course),

I don’t think that I’m competent enough to do that.  If I understand correctly, Windows support is the main issue, and I do not use Windows.

Besides, you know my opinion of your copyright paperwork, and it hasn’t changed lately.  I won’t contribute to Emacs.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, michael.albinus <at> gmx.de,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 07 Aug 2014 18:30:31 +0300

> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
> Date: Thu, 7 Aug 2014 15:12:27 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  Michael Albinus <michael.albinus <at> gmx.de>,
>  schwab <at> suse.de,
>  17839 <at> debbugs.gnu.org
> 
> If I understand correctly, Windows support is the main issue

??? No, it isn't.  Once Michael added the code to do this on Posix
platforms, the Windows code was added to follow suit.

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

From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andreas Schwab <schwab <at> suse.de>, 17839 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 7 Aug 2014 18:08:28 +0200

Am 07.08.2014 um 17:30 schrieb Eli Zaretskii <eliz <at> gnu.org>:

>> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
>> Date: Thu, 7 Aug 2014 15:12:27 +0200
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> Michael Albinus <michael.albinus <at> gmx.de>,
>> schwab <at> suse.de,
>> 17839 <at> debbugs.gnu.org
>> 
>> If I understand correctly, Windows support is the main issue
> 
> ??? No, it isn't.  Once Michael added the code to do this on Posix
> platforms, the Windows code was added to follow suit.

I’m sorry.  I did not follow the entire discussion, since I couldn’t comment on the implementation anyway.  All that I read was that there was some Windows-specific discussion, and from Stefan’s comment I presumed that Windows was still an issue.

But if it isn’t, I don’t see why this patch shouldn’t be “safe” for Emacs 24?  I’m sorry if I’m asking a stupid question, but I’m not familiar with Emacs’ policies.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastian Wiesner <swiesner <at> lunaryorn.com>
Cc: schwab <at> suse.de, 17839 <at> debbugs.gnu.org, michael.albinus <at> gmx.de,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#17839: 24.4.50;
 read-passwd echoes password input in non-interactive sessions
Date: Thu, 07 Aug 2014 19:38:46 +0300

> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
> Date: Thu, 7 Aug 2014 18:08:28 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  Michael Albinus <michael.albinus <at> gmx.de>,
>  Andreas Schwab <schwab <at> suse.de>,
>  17839 <at> debbugs.gnu.org
> 
> >> If I understand correctly, Windows support is the main issue
> > 
> > ??? No, it isn't.  Once Michael added the code to do this on Posix
> > platforms, the Windows code was added to follow suit.
> 
> I’m sorry.  I did not follow the entire discussion, since I couldn’t comment on the implementation anyway.  All that I read was that there was some Windows-specific discussion, and from Stefan’s comment I presumed that Windows was still an issue.

The Windows-specific discussion was because implementing the same
feature on Windows had some subtle issues.

> But if it isn’t, I don’t see why this patch shouldn’t be “safe” for Emacs 24?

I guess because the code changes are not entirely trivial.

Previous Next

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