Re: git https transport and wrong password

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 03, 2013 at 10:12:12AM -0400, Jeff King wrote:
> 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@xxxxxxxxxx': 
>   > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]