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! > 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 -- 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
