Message ID | 20190322190139.151189-1-jonathantanmy@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] t5551: mark half-auth no-op fetch test as v0-only | expand |
On Fri, Mar 22, 2019 at 12:01:39PM -0700, Jonathan Tan wrote: > 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. > > But protocol v2 does not support this, because both ref and pack are > obtained from the git-upload-pack path. > > Mark the test verifying this behavior as protocol v0-only, with a > description of what needs to be done to make v2 support this. Thanks, this looks like a fine solution to me. I do not really expect anyone will ever get around to this NEEDSWORK, but we can see. :) -Peff
Hi, Jonathan Tan wrote: > 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. > > But protocol v2 does not support this, because both ref and pack are > obtained from the git-upload-pack path. > > Mark the test verifying this behavior as protocol v0-only, with a > description of what needs to be done to make v2 support this. > > Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Thanks for the analysis. Makes sense. > --- a/t/t5551-http-fetch-smart.sh > +++ b/t/t5551-http-fetch-smart.sh > @@ -164,7 +164,17 @@ test_expect_success 'clone from auth-only-for-objects repository' ' > > test_expect_success 'no-op half-auth fetch does not require a password' ' > set_askpass wrong && > - git --git-dir=half-auth fetch && > + > + # NEEDSWORK: When using HTTP(S), protocol v0 supports a "half-auth" > + # configuration with authentication required only when downloading > + # objects and not refs, by having the HTTP server only require > + # authentication for the "git-upload-pack" path and not "info/refs". > + # This is not possible with protocol v2, since both objects and refs > + # are obtained from the "git-upload-pack" path. A solution to this is > + # to teach the server and client to be able to inline ls-refs requests > + # as an Extra Parameter (see pack-protocol.txt), so that "info/refs" > + # can serve refs, just like it does in protocol v0. > + GIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch && > expect_askpass none I suspect it's fine if protocol v2 never supports this. Can we change the NEEDSWORK comment to say that the protocol v2 spec should document the lack of support for half-auth? With or without such a change, Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Thanks.
> > + # NEEDSWORK: When using HTTP(S), protocol v0 supports a "half-auth" > > + # configuration with authentication required only when downloading > > + # objects and not refs, by having the HTTP server only require > > + # authentication for the "git-upload-pack" path and not "info/refs". > > + # This is not possible with protocol v2, since both objects and refs > > + # are obtained from the "git-upload-pack" path. A solution to this is > > + # to teach the server and client to be able to inline ls-refs requests > > + # as an Extra Parameter (see pack-protocol.txt), so that "info/refs" > > + # can serve refs, just like it does in protocol v0. > > + GIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch && > > expect_askpass none > > I suspect it's fine if protocol v2 never supports this. Can we change > the NEEDSWORK comment to say that the protocol v2 spec should document > the lack of support for half-auth? > > With or without such a change, > Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Thanks for your review. Junio brought up a possible workflow that uses this feature [1] and while I don't know if we will ever get around to supporting half-auth in v2, it seems better to me to leave the possibility open. [1] https://public-inbox.org/git/xmqq36nfsl8t.fsf@gitster-ct.c.googlers.com/
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index a685d3edb6..c760514716 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -164,7 +164,17 @@ test_expect_success 'clone from auth-only-for-objects repository' ' test_expect_success 'no-op half-auth fetch does not require a password' ' set_askpass wrong && - git --git-dir=half-auth fetch && + + # NEEDSWORK: When using HTTP(S), protocol v0 supports a "half-auth" + # configuration with authentication required only when downloading + # objects and not refs, by having the HTTP server only require + # authentication for the "git-upload-pack" path and not "info/refs". + # This is not possible with protocol v2, since both objects and refs + # are obtained from the "git-upload-pack" path. A solution to this is + # to teach the server and client to be able to inline ls-refs requests + # as an Extra Parameter (see pack-protocol.txt), so that "info/refs" + # can serve refs, just like it does in protocol v0. + GIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch && expect_askpass none '
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. But protocol v2 does not support this, because both ref and pack are obtained from the git-upload-pack path. Mark the test verifying this behavior as protocol v0-only, with a description of what needs to be done to make v2 support this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> --- This is based on master + jt/test-protocol-version, but should apply cleanly to many places. After reading Peff's and Junio's replies, it seems that it would be better to retain this test. So here's a version that retains the test but just marks it as v0, with an explanation as to what needs to be done to make v2 be compatible with it. --- t/t5551-http-fetch-smart.sh | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)