Re: git https transport and wrong password

From: Mikko Rapeli <mikko.rapeli@iki.fi>
Date: Apr 3, 2013, 16:15 UTC
Message-ID: <20130403161536.GZ30514@lakka.kapsi.fi>
In-Reply-To: <20130403141212.GA10494@sigill.intra.peff.net>

On Wed, Apr 03, 2013 at 10:12:12AM -0400, Jeff King wrote:

Show 23 quoted lines

> I would expect without the username in the URL for it to make only two
> requests: one to get the first 401, then git collects the credentials,
> then a follow-up with the credentials. But instead we get:
> 
>   $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \
>       2>&1 >/dev/null | egrep '^>|^< HTTP|^Authorization|requested URL'
>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1
>   * The requested URL returned error: 401 Authorization Required
>   Username for 'https://github.com': foo
>   Password for 'https://foo@github.com': 
>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1
>   < HTTP/1.1 401 Authorization Required
>   > GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1
>   Authorization: Basic Zm9vOmJhcg==
>   < HTTP/1.1 401 Authorization Required
>   * The requested URL returned error: 401
> 
> So we get a 401, as expected, git prompts for the credentials and feeds
> them directly to curl, but then we still get _two_ requests: we trigger
> another 401, and only then does curl provide the authorization header to
> the server.
> 
> I'm not sure if that extra auth is intended or not.

git uses CURLAUTH_ANY which means: first try without authentication (CURLAUTH_NONE), if that fails it will try (I guess) CURLAUTH_BASIC|DIGEST| GSS|NTML and so on, and only then it will fail with the 401.

It seems that skipping CURLAUTH_NONE try is not possible even if it's not a good idea when a username and possibly password is available. Changing CURLAUTH_ANY to skip CURLAUTH_NONE could also break other users.

Since netrc support really needs this one try from git to curl before password prompt I guess in our case using HTTPS with git is simply not feasible. Changing the corporate single sign-on policies is also hard so I will now try to get SSH transport running on the server.

Account locking will still be quite easy but hopefully only after multiple false passwords to the SSH promp.

-Mikko