Re: [PATCH v3] t5550: add netrc tests for http 401/403

>
> 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
>>
>