From: Ashlesh Gawande <git@ashlesh.me>
Date: Fri, 06 Feb 2026 15:25:26 GMT
Subject: Re: [PATCH v3] t5550: add netrc tests for http 401/403
Message-ID: <8ac465f8-6fda-43a1-8bfc-3e88f30d1ca5@ashlesh.me>
In-Reply-To: <20260206093840.GC2761602@coredump.intra.peff.net>


On 2/6/26 15:08, Jeff King wrote:
> On Thu, Feb 05, 2026 at 09:05:51PM -0800, Junio C Hamano wrote:
>
>>>    - Third test case checks that the git clone fails when the .netrc file
>>>      provides credentials that are valid but do not have permission for
>>>      this user. For example one may have multiple tokens in GitHub
>>>      and uses the one which was not authorized for cloning this repo.
>>>      In such a case the HTTP server returns 403 Forbidden.
>>>      For this test, the apache.conf is modified to return a 403
>>>      on finding a forbidden-user. No prompt for username/password is
>>>      expected after the 403 (unlike 401). This is because prompting may wipe
>>>      out existing credentials or conflict with custom credential helpers.
>> Nicely summarised.  So we say 401 when we do not know you, while we
>> say 403 when we know you and do not want you to be accessing the
>> resource.  We test for both.
> I think it is fine to check the 403 handling, but note that this _isn't_
> how GitHub would respond. If you try to fetch from a repository you
> don't have access to, it will return a 401 first (so you try to log in)
> and then a 404. The idea being to avoid revealing the existence of the
> repository to unauthorized users.
In the case of fine-grained access token such that the token has read 
access to the repository
but not write access GitHub does return a 403.
(I think this is correct behavior as the token has read access so user 
is authorized/knows about the repository).
>> Just out of curiosity, do we test for these codes with other
>> credential helpers or is this only relevant for .netrc users?
> The netrc support here should not involve credential helpers at all. It
> is all being done internally by curl. So in this (third and final) test:
>
>>> +test_expect_success 'netrc authorized but forbidden credentials (fail on 403)' '
>>> +	test_when_finished clear_netrc &&
>>> +	set_askpass wrong &&
>>> +	set_netrc 127.0.0.1 forbidden-user@host pass@host &&
>>> +	test_must_fail git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-netrc-403 2>err &&
>>> +	expect_askpass none &&
>>> +	grep "The requested URL returned error: 403" err
>>> +'
> ...what is happening is roughly:
>
>    - curl sends the first request with no credentials, which gets a 401
>
>    - curl internally, without returning a response to Git, looks up the
>      netrc value and repeats the request with an Authorization header
>
>    - curl returns the resulting 403 to Git
>
>    - Git calls this an error (just like it would a 404) and bails
>
> But from Git's perspective the use of netrc here is not really
> interesting. We don't even know it happened! And if the server did
> return a 401, we'd happily try to get credentials (from the user or from
> a helper) in the usual way. And that's what happens in the second test:
>
>>> +test_expect_success 'netrc unauthorized credentials (prompt after 401)' '
>>> +	test_when_finished clear_netrc &&
>>> +	set_askpass wrong &&
>>> +	set_netrc 127.0.0.1 user@host pass@wrong &&
>>> +	test_must_fail git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-netrc-401 &&
>>> +	expect_askpass both wrong
>>> +'
> Curl tries the credential under the hood, but we have no idea, and we
> process a 401 in the usual way.
>
> And in the first one:
>
>>> +test_expect_success 'using credentials from netrc to clone successfully' '
>>> +	test_when_finished clear_netrc &&
>>> +	set_askpass wrong &&
>>> +	set_netrc 127.0.0.1 user@host pass@host &&
>>> +	git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-netrc &&
>>> +	expect_askpass none
>>> +'
> We do not ever even see the 401, and curl just magically handles it for
> us. We see only the successful 200 code, just as if authentication was
> not required in the first place.
>
>
> So really, none of this is testing anything novel in Git at all that is
> not covered elsewhere, except for the fact that we pass the flag to curl
> that says "you may use netrc". And so there's some value in adding it in
> that case. But trying to answer your question about other credential
> helpers, no, they're not even entering the picture here.
>
> -Peff
>