Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test
- From
Jeff King <peff@peff.net>
- Date
- Mar 21, 2019, 19:55 UTC
- Message-ID
- <20190321195536.GC19427@sigill.intra.peff.net>
- In-Reply-To
- <20190321174719.151877-1-jonathantanmy@google.com>
On Thu, Mar 21, 2019 at 10:47:19AM -0700, Jonathan Tan wrote:
Show 13 quoted lines
> When using protocol v0, upload-pack over HTTP permits a "half-auth"
> configuration in which, at the web server layer, the info/refs path is
> not protected by authentication but the git-upload-pack path is, so that
> a user can perform fetches that do not download any objects without
> authentication, but still needs authentication to download objects.
>
> 2e736fd5e9 ("remote-curl: retry failed requests for auth even with
> gzip", 2012-10-31) added a test for this, stating that this leaks
> information about the repository but makes it occasionally more
> convenient for users that use manual credential entry.
>
> Protocol v2 does not support this, because both ref and pack are
> obtained from the git-upload-pack path.I have mixed feelings. I agree that this this is not a setup we really want to recommend. But it did come out of somebody's real-world case[1]. It would be nice to know if it got broken, even if v2 doesn't support it.
I am a little confused about v2 here, though. It should hit the initial info/refs endpoint the same as usual. If it's a noop fetch, then it's done. Otherwise, we'd hit the git-upload-pack and expect to require authentication. That should work after your switch to using post_rpc, shouldn't it?
And I guess it does, because you did not delete the test before "clone from auth-only-for-objects repository", which would actually do the second half of that conversation, and require authentication. You're only deleting the part that does the noop fetch.
Puzzled...
-Peff
[1] https://public-inbox.org/git/CAHtLG6Q+XO=LhnKw4hhwtOe2ROeDN1Kg=JN5GTQqdvYjk-Sv4g@mail.gmail.com/