Rémi Vanicat [off-list ref] 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.
On Fri, Jul 01, 2011 at 10:00:27AM -0700, Junio C Hamano wrote:
quoted
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.
Coincidentally, I am working on a big patch series for exactly this.
It is still lacking some docs and tests, but if you want to take a peek,
it's at:
https://github.com/peff/git.git jk/http-auth
It runs external credential helpers, giving them a unique context (like
the protocol and hostname for http connections), as well as a username,
if we already have one. The goal is two-fold:
1. Plug into existing password wallets that are going to be
user- and OS- specific.
2. Provide a few stock helpers to implement simple policies in a
pluggable way.
Right now I have two helpers: "store", and "cache". Both will check
internal storage for a password; if we don't have one, they will prompt
and put the result in internal storage. In either case, the password is
sent back to git. They differ in what "internal storage" means.
In the case of "store", it is a mode 600 ~/.git-credentials file. Yes,
this is horribly insecure. But it's what some people want, it's no worse
than .netrc, and it's what svn does (and what gitter wouldn't be swayed
by that last argument? :) ). It's a little more friendly than netrc
because the storage happens transparently. I think the docs for this
should discourage it because of the security implications, and it should
definitely never become the default.
For "cache", we fork off a storage daemon which keeps the password in
memory for a specified period of time. The password never touches the
disk. It doesn't mlock() right now, but it could on platforms that
support it.
Both are obviously mediocre solutions in comparison to a real password
wallet[1]. But they're really simple to implement and give us a better
baseline to ship with git. I'm hoping users of individual keychains will
implement helpers to use them. Somebody from GitHub is going to work on
an OS X keychain helper. I personally use a home-grown password safe;
writing a read-only helper was about 10 lines of shell code.
Anyway, if people want to try it out, build the branch I mentioned above
and configure it like:
# horribly insecure
git config http.credentialhelper store
or
# a little better
git config http.credentialhelper cache
# we will now cache results for 15 minutes, but there's no reason not
# to store the username all the time, to avoid having to type it on a
# cache miss
git config credential.https:github.com.username peff
I've been using it for the past week or so, but I'm sure there are
lurking bugs. If you run into any, let me know.
-Peff
[1] Obviously this entire exercise is an attempt to make https
authentication as nice a user-experience as ssh with keys and ssh-agent.
So it's tempting to say "just use ssh with keys". But I think the
reality is that ssh and keys are just too challenging for a subset of
the user population (especially ones on operating systems without good
support). Apparently GitHub's most common tech support issues are people
unable to figure out how to make ssh keys, set up an agent, etc.