Re: GIT, libcurl and GSS-Negotiate

From: Jeff King <peff@peff.net>
Date: May 12, 2014, 20:21 UTC
Message-ID: <20140512202153.GB2329@sigill.intra.peff.net>
In-Reply-To: <20140510210132.GD45511@vauxhall.crustytoothpaste.net>

On Sat, May 10, 2014 at 09:01:32PM +0000, brian m. carlson wrote:

Show 12 quoted lines

> What it looks like is happening is that git is offering Negotiate data,
> and then your server is responding with a 401 Unauthorized.  libgit2
> (presumably using WinHTTP) continues in this case, retrying with a
> longer set of credential containing more data, but git gives up.
> 
> Both responses comply with RFC 2616, by my reading.  I guess there are a
> couple of choices here:
> 
> * Make your web server happy with the data that it gets passed
>   initially.
> * Make git understand that it really needs to try again with different
>   credentials in this case (how to do that is unknown).

It should be pretty straightforward to loop again; http_request_reauth just needs to turn into a for-loop on getting HTTP_REAUTH, rather than a static two-tries (I even had a patch for this a while ago, but the function has changed a bit in the interim).

The tricky part is figuring out when to return HTTP_NOAUTH ("do not try again, we failed") versus HTTP_REAUTH ("get credentials and try again") in handle_curl_result. Right now the decision is based on "did we have a username and password for this request?" I'm not clear on what extra bits would be needed to decide to continue in the case you guys are discussing.

> * Provide some way of forcing git to use a particular authentication
>   protocol.

Yeah, we just set CURLAUTH_ANY now, but it would be fairly trivial to add "http.authtype" and "http.proxyauthtype" to map to CURLOPT_HTTPAUTH and CURLOPT_PROXYAUTH.

-Peff