Rémi Vanicat <vanicat@xxxxxxxxxx> 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.
--
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