Frank Li <lznuaa@xxxxxxxxx> writes:
> 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.
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.
> It is nice to use one dialog for all cases. git-svn also have the same problem.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html