Re: [Wishlist] could git tell which password it is asking when asking a password.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 1, 2011, 17:00 UTC
- Message-ID
- <7v62nmos0k.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <877h82nlua.dlv@debian.org>
Rémi Vanicat <vanicat@debian.org> writes:
> When git is asking for a password (for example for pushing over https) > it call the $GIT_ASKPASS script with only "Password: " as a an argument, > so when one have several remote, it might not know which one is asking > the password.
On the C side, git_getpass() is the function to touch. It has only three callers.
In init_curl_http_auth() in http.c, we know "user_name" but we do not give it as a hint when coming up with a prompt. A possible update to the git_getpass() API would be to make the call look like this:
diff --git a/http.c b/http.c index a1ea3db..ee3e821 100644 --- a/http.c +++ b/http.c @@ -214,7 +214,7 @@ static void init_curl_http_auth(CURL *result) if (user_name) { struct strbuf up = STRBUF_INIT; if (!user_pass) - user_pass = xstrdup(git_getpass("Password: ")); + user_pass = git_getpass(_("Password for %s: "), user_name); strbuf_addf(&up, "%s:%s", user_name, user_pass); curl_easy_setopt(result, CURLOPT_USERPWD, strbuf_detach(&up, NULL)); The points are (1) to show identity for which the password is being asked for; (2) to give a fresh and stable memory, making it unnecessary to xstrdup() while at it. The same thing for the call in has_cert_password(), which may want to use ssl_cert as the identifier. There is an abuse of git_getpass() in http_request() to ask for the username. It inherits the "noecho"-ness of git_getpass() which gives a bad user experience. We _may_ want to give another parameter to git_getpass() to specify if we want noecho. The other call is from imap-send.c that knows srvc->user and srvc->host and formulates the prompt including the identity. So an alternative route may be to keep git_getpass() as-is, and update the init_curl_http_auth() callsite to include the username (but imap-send assumes that user and host are relatively short without verifying that assumption, and should not be used as a model of good existing code). > It would be interesting also to plug some sort of password-safe unto > git, or some "git-agent". I am not particularly interested in seeing git specific agent. Something that can be called as an external process that talks with existing practices (gpg agent and friends) would be nice.