Re: git with https and client cert asks for password repeatedly

From: Josef Wolf <jw@raven.inka.de>
Date: Feb 25, 2009, 21:42 UTC
Message-ID: <20090225214224.GB4573@raven.wolf.lan>
In-Reply-To: <ca433830902241911x10b08a4fg8e790000a5cf9f3b@mail.gmail.com>

On Tue, Feb 24, 2009 at 10:11:40PM -0500, Mark Lodato wrote:

> When fetching or pushing over https:// with a client certificate
> (http.sslCert / http.sslKey), git asks for a password for every single
> requested file.  For example, here I push three commits with a couple
> changed files each:

[ ... ]

> This problem makes client-side certificates unusable with git.  A
> possible workaround is to leave the key unencrypted, but this is
> usually unacceptable for security reasons.

For the (pretty much standard) Basic authentication over https, it is even worse: you have to put your password in plain text into .netrc :-( Check out http://marc.info/?l=git&m=122426078301793&w=2 if you have a couple of minutes left.

> Ideally, I would just type
> my password once per invocation and git would remember it.  (This is
> how svn works.)

Yeah, that would be great!

Show 9 quoted lines

> I think the root problem is that git creates a completely new http(s)
> connection for every request, rather than using one persistent
> connection.  Using a persistent connection would theoretically speed
> up the transfers, in addition to fixing the password prompt issue.
> I'm pretty sure that calling `curl_easy_cleanup()' after every request
> is causing this behavior; I don't think this is necessary.
> 
> I tried fixing this myself, but the http/curl code is pretty
> confusing.  Just wondering - why is HTTP_MULTI required for http-push?

The integration of curl into git looks somewhat strange to me, also. It seems to implement some sort of request-queue on top of curl-multi and falls back to re-implement some curl-multi functionality in the case when only curl-easy is available. Or something like that. I have not looked too much into the details, and have already forgotten what I saw there.

Instead, I looked into curl-lib to implement some sort of credential caching. The idea was to implement something like get_basic_credentials() in the LWP::UserAgent perl module.

Once such a retrieval callback/cache would be implemented in curl, it would be pretty easy to make use of it from git without messing/breaking too much with the existing code.

So I went to the curl-library list. Please feel free to read the discussion on http://curl.haxx.se/mail/lib-2008-10/index.html#286

Check out http://curl.haxx.se/mail/lib-2008-11/index.html#38 for a first draft of the change I suggested.

Unfortunately, I got stuck implementing the regression tests for this change. Then I got short on time to proceed the work on this topic. Check out http://curl.haxx.se/mail/lib-2008-11/index.html#51 for the last state of affairs I posted. Once the regression tests are implemented, implementing the remaining functionality would be pretty much straight forward. But currently, I have no clue when I will get around to continue working on that.

> Finally, is there interest in refactoring the http code to make it a
> little cleaner?  That is, make a wrapper library around curl so that
> you can just call GET or POST or whatever and not worry about how to
> invoke curl?

As I mentioned above, I figured that implementing the callback method in curl-lib would probably be easier than understanding the usage of curl within git. So I'd say refactoring would be an improvement. But I bet the git gurus will flame me for saying that =:-S