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

[Jeff King <peff@peff.net>]

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.

> 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