Re: [PATCH 1/2][Perlers?] git-send-email: ssh/login style password requests

From: Michael Witten <mfwitten@mit.edu>
Date: Feb 3, 2008, 17:59 UTC
Message-ID: <87CDEC9F-8153-48D0-AD1C-A3B3CEF6FDAE@MIT.EDU>
In-Reply-To: <7vve5711wa.fsf@gitster.siamese.dyndns.org>

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

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

Show 24 quoted lines

> 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.

> * "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.

> * 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?

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

Show 18 quoted lines

> 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