The crux of my conclusion comes after the ---------------------------- .

On 2 Feb 2008, at 4:31 PM, Junio C Hamano wrote:

quoted text
> Actually, I just tried this myself:
>
>    #!/usr/bin/perl -w
>
>    use Term::ReadLine;
>    my $term = new Term::ReadLine 'foobar';
>
>    my ($user, $password);
>    while (!defined $user) {
>            $user = $term->readline("User: ");
>    }
>    system 'stty -echo';
>    while (!defined $password) {
>            $password = $term->readline("Password: ");
>    }
>    system 'stty echo';
>    print "You said <$user><$password>\n";
>    print "ReadLine backend used was ", $term->ReadLine, "\n";
>
> In my case, the backend was "Term::ReadLine::Perl".  A few
> problems:
>
> * After typing "junio <Enter>" to "User:", an extra newline is
>   left before "Password:" prompt;

I didn't have this problem.

quoted text
> * "Password:" prompt still echoed password "abc".  There was no
>   extra newline before "You said <junio><abc>".

Indeed. I tested your code and my git-send-email code with all three
backend implementations (Term::ReadLine::Stub, Term::ReadLine::Gnu, and
Term::ReadLine::Perl). The problem with echoing seems to be a fault of
the Term::ReadLine::Perl implementation.

quoted text
> * In either case, typing <Enter> returns an empty string from
>   $term->readline() so the "while (!defined)" loop does not buy
>   us anything.

Frankly, I wrote that readline code according to the other uses of  
readline,
as I am not well versed in these things.

Because all other uses of readline are wrapped in such while loops, I  
assume
that they are meant to cover systems with non-blocking (unbuffered)  
IO, rather
than to continue to prompt the user due to empty strings.

Should empty-string passwords not be allowed?

-------------------------------------------------

quoted text
> Another example which appears in PerlFAQ #8 uses ReadKey with
> its ReadLine, like this:
>
>    use Term::ReadKey;
>    ReadMode('noecho');
>    $password = ReadLine(0);
>
> which is different from Term::ReadLine's "ReadLine".  An earlier
> example you cited from perlfunc.pod's crypt() entry does:
>
>    system "stty -echo";
>    print "Password: ";
>    chomp($word = <STDIN>);
>    print "\n";
>    system "stty echo";
>
> In either case, I was worried about the interaction between the
> Term::ReadLine backend implementation and "stty".

This got me thinking: At first I wanted to use readline for the  
password prompt,
because I figured it would allow the user better editing facilities,  
especially
with regard to the arrow keys. However, it occurred to me that perhaps  
this should
not be the case; perhaps arrow keys are meant to be useable in  
passwords, etc.

Well, this turns out to be the case! (which may not be a surprise to  
most people,
but it was to me). Passwords can actually contain some of the keycodes  
that read-
line converts into editing commands (now you know which characters you  
don't have
to test when cracking my password). Therefore, we shouldn't even  
bother using the
readline backend for password prompting; neither passwd nor ssh use  
readline, for
example.

I support the 'crypt' method, because the Term::ReadKey approach  
requires another
module dependency.

Sincerely,
Michael Witten
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html