Re: No negotiation for repos on HTTP servers?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 13, 2015, 21:19 UTC
Message-ID: <20150913211922.GF8394@vauxhall.crustytoothpaste.net>
In-Reply-To: <CAGHtn=oXUa2=n2aMWQKndDSfGZ2bPm-dxZ7jin7QOx8dRxp3Kw@mail.gmail.com>

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