Re: [PATCH] git-send-email: ssh/login style password requests

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] git-send-email: ssh/login style password requests

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:09

Michael Witten [off-list ref] writes:
+--smtp-pass::
+	Password for SMTP-AUTH. The default value can be specified
+	with the configuration variable 'sendemail.smtppass' or
+	sendemail.<identity>.smtppass (see sendemail.identity).
+	The argument is optional: If no argument is specified, then
+	the password is assumed to be the empty string.
+	If a username has been set, but no password has been set,
+	the user is prompted for a password with masked input for
+	privacy; passwords need not be recorded in configuration
+	files.
I am a bit puzzled about the above description, though.  It is
not clear if there is any difference between "the empty string"
password, and "no password has been set".  It makes me wonder
what the possible cases are.

 (1) no *.smtppass configuration present; no --smtp-pass parameter
     is given on the command line.

 (2) *.smtppass configuration present but is an empty string; no
     --smtp-pass parameter is given on the command line.

 (3) *.smtppass configuration present with a non-empty string; no
     --smtp-pass parameter is given on the command line.

 (4) parameter is given with an empty string (i.e. "--smtp-pass=")
     on the command line.

 (5) parameter is given with a non-empty string (i.e. "--smtp-pass=foo")
     on the command line.

My _guess_ is that command line always trump configuration so
in cases (4) and (5) it does not matter what you have (or do not
have) in *.smtppass configuration.  In other cases, lack of *.smtppass
and having *.smtppass with an empty string as its value are equivalent.
And in any case, an empty string (or lack of specification) results
in prompting.

But you shouldn't make _me_ guess.  You certainly would be
forcing many other people to guess with this.
+		if (defined $smtp_authuser) {
+
+			if (!defined $smtp_authpass) {
+				
+				system "stty -echo";
+
+				do {
+					$_ = $term->readline("Password: ");
+				} while (!defined $_);
+
+				system "stty echo";
+
+				$smtp_authpass = $_ if ($_);
+			}
+
I like what the patch tries to do, but the system() there feels
a tad ugly.  In addition it makes me wonder (1) what happens if
you ^C out from this while loop, and (2) $term->readline()
interface might already have a method to turn echo off.

We luckily have people handy at Perl on the list, so I'll wait
for our resident Perl experts to suggest a better alterantive.

We are not in a hurry, so I expect a polished resubmit after
1.5.4.  Thanks.

Re: [PATCH] git-send-email: ssh/login style password requests

From: Michael Witten <hidden>
Date: 2016-06-15 22:44:09

On 1 Feb 2008, at 5:09 AM, Junio C Hamano wrote:
Michael Witten [off-list ref] writes:
quoted
+--smtp-pass::
+	Password for SMTP-AUTH. The default value can be specified
+	with the configuration variable 'sendemail.smtppass' or
+	sendemail.<identity>.smtppass (see sendemail.identity).
+	The argument is optional: If no argument is specified, then
+	the password is assumed to be the empty string.
+	If a username has been set, but no password has been set,
+	the user is prompted for a password with masked input for
+	privacy; passwords need not be recorded in configuration
+	files.
I am a bit puzzled about the above description, though.  It is
not clear if there is any difference between "the empty string"
password, and "no password has been set".  It makes me wonder
what the possible cases are.
How are these descriptions:

	http://web.mit.edu/mfwitten/git-send-email.html

I've attempted to keep them short, but complete. Also, the
resulting man page versions are formatted similarly (though
at the expense of some ASCIIdoc readability).
In other cases, lack of *.smtppass
and having *.smtppass with an empty string as its value are  
equivalent.
And in any case, an empty string (or lack of specification) results
in prompting.
Actually, a lack of *.smtp<user|pass> results in variables without
definition rather than with empty-string values; the original code,
too, makes use of this fact. Consequently, an empty string for
*.smtppass does not result in prompting, as tested.
quoted
+		if (defined $smtp_authuser) {
+
+			if (!defined $smtp_authpass) {
+				
+				system "stty -echo";
+
+				do {
+					$_ = $term->readline("Password: ");
+				} while (!defined $_);
+
+				system "stty echo";
+
+				$smtp_authpass = $_ if ($_);
+			}
+
I like what the patch tries to do, but the system() there feels
a tad ugly.  In addition it makes me wonder (1) what happens if
you ^C out from this while loop
Good question! Though I'm not sure you can handle this any other
way than to intercept the signal.
(2) $term->readline() interface might already have a method to turn  
echo off.
I have very limited knowledge of these things, especially of Perl's  
interfaces,
but this is what `perldoc -q password` has to say about it:
	There's an example of this in "crypt" in perlfunc).
	First, you put the terminal into "no echo" mode,
	then just read the password normally.  You may do
	this with an old-style ioctl() function, POSIX
	terminal control (see POSIX or its documentation
	the Camel Book), or a call to the stty program,
	with varying degrees of portability.
	
	You can also do this for most systems using the
	Term::ReadKey module from CPAN, which is easier
	to use and in theory more portable.
	
	   use Term::ReadKey;
	
	   ReadMode('noecho');
	   $password = ReadLine(0);
My code is from the "crypt" version. The other versions require
extra module dependencies, and the portability doesn't extend
immediately to Windows with any of these methods.
We are not in a hurry, so I expect a polished resubmit after
1.5.4.  Thanks.
Great!

Sincerely,
Michael Witten

Re: [PATCH] git-send-email: ssh/login style password requests

From: Michael Witten <hidden>
Date: 2016-06-15 22:44:09

On 1 Feb 2008, at 1:38 PM, Michael Witten wrote:
quoted
I like what the patch tries to do, but the system() there feels
a tad ugly.  In addition it makes me wonder (1) what happens if
you ^C out from this while loop
Good question! Though I'm not sure you can handle this any other
way than to intercept the signal.
It turns out that --compose will also leave some temporary files
behind if git-send-email is terminated out of course.

Should I establish a general handler for SIGTERM and SIGINT?

Michael Witten
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help