# No negotiation for repos on HTTP servers? 2 messages from 2015-09-13 to 2015-09-13. Participants: Christoffer Haglund, brian m. carlson. Thread: https://gitlist.dev/t/40343 ## Christoffer Haglund, 2015-09-13 19:31 Subject: No negotiation for repos on HTTP servers? Message-ID: URL: https://gitlist.dev/e/CAGHtn%3DoXUa2%3Dn2aMWQKndDSfGZ2bPm-dxZ7jin7QOx8dRxp3Kw%40mail.gmail.com ``` Hi, I wonder if I've hit a bug in git, or perhaps in libcurl. Our team that use git repos hosted on a number of different environments, including HTTP servers using Kerberos or NTLM to authenticate users. Command-line git needs explicit credentials to work against these repos, while Visual Studio (i.e. libgit2) does not. The other day I noticed that when I give null credentials (i.e. empty username and password) normal command-line git works beautifully, authenticating as the currently signed-in user. I digged around a bit and found a potential bug in how libcurl is used; when using CURLAUTH_ANY, no handshaking will actually be done unless a user name is specified - even if it's a fake one. This is consistent with the documentation for curl itself, http://curl.haxx.se/docs/manpage.html#--negotiate , however I see no mention of this quirk in the libcurl API documentation. The fix I'm using locally is quite straightforward: diff --git a/http.c b/http.c index 9dce380..f62f6b6 100644 --- a/http.c +++ b/http.c @@ -668,6 +668,10 @@ struct active_request_slot *get_active_slot(void) #endif if (http_auth.password) init_curl_http_auth(slot->curl); +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY + else + curl_easy_setopt(slot->curl, CURLOPT_USERNAME, ""); +#endif return slot; } As far as I can tell this works fine against NTLM and Kerberos HTTP servers, and has no effect on servers allowing anonymous access. Against a server using Basic authentication the patch will cause git to fire off a redundant 'GET' with the empty username before asking the user for credentials. I'm not sure if that could cause problems for other users, I would expect that anyone working against a server with Basic authentication uses stored credentials anyway :-) But perhaps there is some other case I've not considered? // Christoffer ``` ## brian m. carlson, 2015-09-13 21:19 Subject: Re: No negotiation for repos on HTTP servers? Message-ID: <20150913211922.GF8394@vauxhall.crustytoothpaste.net> URL: https://gitlist.dev/e/20150913211922.GF8394%40vauxhall.crustytoothpaste.net In-Reply-To: ``` On Sun, Sep 13, 2015 at 09:31:54PM +0200, Christoffer Haglund wrote: > Our team that use git repos hosted on a number of different > environments, including HTTP servers using Kerberos or NTLM to > authenticate users. Command-line git needs explicit credentials to > work against these repos, while Visual Studio (i.e. libgit2) does not. > The other day I noticed that when I give null credentials (i.e. empty > username and password) normal command-line git works beautifully, > authenticating as the currently signed-in user. > > I digged around a bit and found a potential bug in how libcurl is > used; when using CURLAUTH_ANY, no handshaking will actually be done > unless a user name is specified - even if it's a fake one. Yes, this is correct. My general strategy with Kerberos is to use the actual username, but you could simply use a dummy (e.g. git@). This isn't really a bug in git so much as a limitation in libcurl. libgit2 doesn't have this problem because it doesn't use libcurl. Of course, it has it's own problems, like its SSH support not doing Kerberos. > This is consistent with the documentation for curl itself, > http://curl.haxx.se/docs/manpage.html#--negotiate , however I see no > mention of this quirk in the libcurl API documentation. It is present somewhere in there, but it's not easy to find, I'll admit. > Against a server using Basic authentication the patch will cause git > to fire off a redundant 'GET' with the empty username before asking > the user for credentials. I'm not sure if that could cause problems > for other users, I would expect that anyone working against a server > with Basic authentication uses stored credentials anyway :-) I don't see any problems with this. I'd suggest sending the patch as specified in Documentation/SubmittingPatches, and it's likely Junio will pick it up. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 ```