http getpass function in msysgit

ALL:

        getpass at mingw.c is direct read character with function _getch().
        GUI application, such tortoisegit will halt when http need
password input because gui don't know git wait for inputing passwords.

        To resolve this problem, I have two options.
        Options 1:
                Check if terminal is exist, if exist, using old
method. Otherwise launch internal password dialog.

        Options 2:
                like openSSH,  Check if terminal is not exist and
environment HTTP_ASKPASS exist, if true, run application which
HTTP_ASKPASS point, otherwise using old ways.

       Which one do you prefer,  I can implement it.

best regards Frank Li

Frank Li <lznuaa@gmail.com> writes:

Is "Neither, at least not yet" an accepted answer?

 - If you look at an environment, why check terminal at all?  If the
   calling application wants to specify "here is the way to ask the user
   for a password" with it, why not use it unconditionally?

 - Why is it HTTP_ASKPASS?  If other codepaths (e.g. "ssh passphrase",
   "svn password") that do not have anything to do with HTTP transfer also
   wants that feature, wouldn't it be easier for the users to specify one
   single "password dialog" helper program, that is launched by various
   parts of git, and ask "I need the HTTP password to access li.org", "I
   need to unlock the ssh key for fl@li.org", etc?

I just worry about user set such environment accident. Learn it from OpenSSH. Unconditional is okay for me.

You can choose environment name you like. I choose HTTP_ASKPASS just because getpass only used at http.c ssl_cert_password = getpass("Certificate Password: ");

OpenSSH is separated application and use own SSH_ASKPASS to ask password ...

May GIT_ASKPASS is optional name.

It is nice to use one dialog for all cases. git-svn also have the same problem.

Frank Li <lznuaa@gmail.com> writes:

If that is the case, probably it is easiest for the end users if you arrange it this way:

 - If GIT_ASKPASS is not set:

   - If SSH_ASKPASS is present, then use that from getpass() for any and
     all places that would want to get "password" like things;

   - Otherwise consult the terminal as before;

 - If GIT_ASKPASS is set:

   - If SSH_ASKPASS is not set, then export the value of GIT_ASKPASS as
     such as well, so that whenever we spawn "ssh", the same GIT_ASKPASS
     program will be used as a fallback.

That way, if the user already has set up SSH_ASKPASS, we will use the same familiar dialog without forcing the user do anything extra. If the user only sets GIT_ASKPASS without doing SSH_ASKPASS, we would also use it to drive the ssh session. In either case, the user doesn't need to worry about multiple configuration or dialog interface.

People often seem to use "/usr/lib{,exec}/openssh/gnome-ssh-askpass" as SSH_ASKPASS. It takes the prompt from its command line argument, reads the input, and spits it out to its standard output so that calling program can capture it. It would be a good interface to conform to to minimize the work we need to support this.

Can we direct use SSH_ASKPASS for all getpass and don't use GIT_ASKPASS at all? The logic will be come simple.

Frank Li <lznuaa@gmail.com> writes:

If you _really_ have to ask me,...

I'd suspect people would feel it funny if the only advertised interface were SSH_*, especially when they don't use OpenSSH at all and setting up the prompter solely to use git over http. If you use GIT_ASKPASS as the advertised _primary_ interface to drive the prompter, while falling back on SSH_ASKPASS as a mere end-user convenience measure, you wouldn't have that problem. Hence my suggestion.

But in the end it's up to you to decide. I won't be writing this code ;-).