No negotiation for repos on HTTP servers?

Christoffer Haglund· Sep 13, 2015, 19:31 UTC · lore

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· Sep 13, 2015, 21:19 UTC · re: Christoffer Haglund · lore

Re: No negotiation for repos on HTTP servers?

On Sun, Sep 13, 2015 at 09:31:54PM +0200, Christoffer Haglund wrote:

Show 11 quoted lines

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

Show 5 quoted lines

> 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