{"thread":{"id":"50797","subject":"[RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","startedAt":"2019-03-21T17:47:26Z","lastAt":"2019-04-08T17:01:30Z","messageCount":12,"participants":["Jonathan Tan","Jeff King","Junio C Hamano","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"372147","messageId":"20190321174719.151877-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":null,"subject":"[RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-03-21T17:47:19Z","receivedAt":"2019-03-21T17:47:26Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"When using protocol v0, upload-pack over HTTP permits a \"half-auth\"\nconfiguration in which, at the web server layer, the info/refs path is\nnot protected by authentication but the git-upload-pack path is, so that\na user can perform fetches that do not download any objects without\nauthentication, but still needs authentication to download objects.\n\n2e736fd5e9 (\"remote-curl: retry failed requests for auth even with\ngzip\", 2012-10-31) added a test for this, stating that this leaks\ninformation about the repository but makes it occasionally more\nconvenient for users that use manual credential entry.\n\nProtocol v2 does not support this, because both ref and pack are\nobtained from the git-upload-pack path.\n\nBecause this configuration is not supported by all protocol versions,\nand because this configuration seems to be of limited usefulness (only\nuseful for people who use manual credential entry and on servers that\nare OK with exposing refs but not objects, and even in this case, helps\nonly in a no-op fetch), delete the test that verifies that this\nconfiguration works.\n\nThis issue was discovered by the GIT_TEST_PROTOCOL_VERSION patches.\n\nSigned-off-by: Jonathan Tan <jonathantanmy@google.com>\n---\nThis is on master. (It is reasonable to apply it even in the absence of\nGIT_TEST_PROTOCOL_VERSION.)\n\nMarking this as RFC, because my opinion is that the usefulness of this\nfeature is limited (as you can see in the commit message), but others\nmay have a use case that I haven't thought about.\n\nThe alternative is to add GIT_TEST_PROTOCOL_VERSION=0 to this test (and\nrebase it to a branch that has GIT_TEST_PROTOCOL_VERSION).\n---\n t/t5551-http-fetch-smart.sh | 6 ------\n 1 file changed, 6 deletions(-)\n\ndiff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh\nindex ba83e567e5..3be9c0063b 100755\n--- a/t/t5551-http-fetch-smart.sh\n+++ b/t/t5551-http-fetch-smart.sh\n@@ -149,12 +149,6 @@ test_expect_success 'clone from auth-only-for-objects repository' '\n \ttest_cmp expect actual\n '\n \n-test_expect_success 'no-op half-auth fetch does not require a password' '\n-\tset_askpass wrong &&\n-\tgit --git-dir=half-auth fetch &&\n-\texpect_askpass none\n-'\n-\n test_expect_success 'redirects send auth to new location' '\n \tset_askpass user@host pass@host &&\n \tgit -c credential.useHttpPath=true \\\n-- \n2.21.0.155.ge902e9bcae.dirty\n\n"},{"id":"372159","messageId":"20190321195536.GC19427@sigill.intra.peff.net","threadId":"50797","inReplyTo":"20190321174719.151877-1-jonathantanmy@google.com","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-21T19:55:37Z","receivedAt":"2019-03-21T19:55:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 21, 2019 at 10:47:19AM -0700, Jonathan Tan wrote:\n\n> When using protocol v0, upload-pack over HTTP permits a \"half-auth\"\n> configuration in which, at the web server layer, the info/refs path is\n> not protected by authentication but the git-upload-pack path is, so that\n> a user can perform fetches that do not download any objects without\n> authentication, but still needs authentication to download objects.\n> \n> 2e736fd5e9 (\"remote-curl: retry failed requests for auth even with\n> gzip\", 2012-10-31) added a test for this, stating that this leaks\n> information about the repository but makes it occasionally more\n> convenient for users that use manual credential entry.\n> \n> Protocol v2 does not support this, because both ref and pack are\n> obtained from the git-upload-pack path.\n\nI have mixed feelings. I agree that this this is not a setup we really\nwant to recommend. But it did come out of somebody's real-world case[1].\nIt would be nice to know if it got broken, even if v2 doesn't support\nit.\n\nI am a little confused about v2 here, though. It should hit the initial\ninfo/refs endpoint the same as usual. If it's a noop fetch, then it's\ndone. Otherwise, we'd hit the git-upload-pack and expect to require\nauthentication. That should work after your switch to using post_rpc,\nshouldn't it?\n\nAnd I guess it does, because you did not delete the test before \"clone\nfrom auth-only-for-objects repository\", which would actually do the\nsecond half of that conversation, and require authentication. You're\nonly deleting the part that does the noop fetch.\n\nPuzzled...\n\n-Peff\n\n[1] https://public-inbox.org/git/CAHtLG6Q+XO=LhnKw4hhwtOe2ROeDN1Kg=JN5GTQqdvYjk-Sv4g@mail.gmail.com/\n"},{"id":"372160","messageId":"20190321200231.GD19427@sigill.intra.peff.net","threadId":"50797","inReplyTo":"20190321195536.GC19427@sigill.intra.peff.net","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-21T20:02:31Z","receivedAt":"2019-03-21T20:02:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 21, 2019 at 03:55:37PM -0400, Jeff King wrote:\n\n> I am a little confused about v2 here, though. It should hit the initial\n> info/refs endpoint the same as usual. If it's a noop fetch, then it's\n> done. Otherwise, we'd hit the git-upload-pack and expect to require\n> authentication. That should work after your switch to using post_rpc,\n> shouldn't it?\n> \n> And I guess it does, because you did not delete the test before \"clone\n> from auth-only-for-objects repository\", which would actually do the\n> second half of that conversation, and require authentication. You're\n> only deleting the part that does the noop fetch.\n> \n> Puzzled...\n\nAh, nevermind. I forgot that v2 really will make two requests for this\nnoop case. The initial endpoint hit only returns the capabilities and\nnothing else. And that's inherent in the protocol.\n\nI'm OK with dropping this test, but I think my reasoning is slightly\ndifferent than what you wrote. The interesting bits are actually\nhappening in the test _before_ this one, which are exercising the\ngzipped auth-retry code. And that happens in both protocol v0 and v2.\n\nThe test you're deleting is basically just verifying that our apache\nconfig is indeed \"half-auth\". Because in v0, the server is never even\ngoing to ask for credentials, so no interesting code paths in the client\nare triggered. So it's not actually testing anything of interest.\n\n-Peff\n"},{"id":"372161","messageId":"20190321202435.19140-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":"20190321200231.GD19427@sigill.intra.peff.net","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-03-21T20:24:35Z","receivedAt":"2019-03-21T20:24:41Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> On Thu, Mar 21, 2019 at 03:55:37PM -0400, Jeff King wrote:\n> \n> > I am a little confused about v2 here, though. It should hit the initial\n> > info/refs endpoint the same as usual. If it's a noop fetch, then it's\n> > done. Otherwise, we'd hit the git-upload-pack and expect to require\n> > authentication. That should work after your switch to using post_rpc,\n> > shouldn't it?\n> > \n> > And I guess it does, because you did not delete the test before \"clone\n> > from auth-only-for-objects repository\", which would actually do the\n> > second half of that conversation, and require authentication. You're\n> > only deleting the part that does the noop fetch.\n> > \n> > Puzzled...\n> \n> Ah, nevermind. I forgot that v2 really will make two requests for this\n> noop case. The initial endpoint hit only returns the capabilities and\n> nothing else. And that's inherent in the protocol.\n\nYes, you're right.\n\n> I'm OK with dropping this test, but I think my reasoning is slightly\n> different than what you wrote. The interesting bits are actually\n> happening in the test _before_ this one, which are exercising the\n> gzipped auth-retry code. And that happens in both protocol v0 and v2.\n> \n> The test you're deleting is basically just verifying that our apache\n> config is indeed \"half-auth\". Because in v0, the server is never even\n> going to ask for credentials, so no interesting code paths in the client\n> are triggered. So it's not actually testing anything of interest.\n\nIf both of us want to drop this test, that's great :-) but for\nclarification: in addition to verifying that our apache config is\n\"half-auth\", this test also verifies that in a no-op fetch, we don't hit\nthe path that is guarded by an authentication requirement. This seems\nsignificant to me in light of the link you provided in your prior email\n[1].\n\n[1] https://public-inbox.org/git/20190321195536.GC19427@sigill.intra.peff.net/\n"},{"id":"372180","messageId":"20190321214827.GA22582@sigill.intra.peff.net","threadId":"50797","inReplyTo":"20190321202435.19140-1-jonathantanmy@google.com","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-21T21:48:28Z","receivedAt":"2019-03-21T21:48:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 21, 2019 at 01:24:35PM -0700, Jonathan Tan wrote:\n\n> > The test you're deleting is basically just verifying that our apache\n> > config is indeed \"half-auth\". Because in v0, the server is never even\n> > going to ask for credentials, so no interesting code paths in the client\n> > are triggered. So it's not actually testing anything of interest.\n> \n> If both of us want to drop this test, that's great :-) but for\n> clarification: in addition to verifying that our apache config is\n> \"half-auth\", this test also verifies that in a no-op fetch, we don't hit\n> the path that is guarded by an authentication requirement. This seems\n> significant to me in light of the link you provided in your prior email\n> [1].\n\nYeah, I suppose it does. I just never really thought of that as a\nplausible regression to introduce, given the way the v0 protocol works. :)\n\nAlthough in a sense it is interesting, because it did reveal something\nabout v2 that we hadn't considered. I don't think it's worth addressing\n(especially now), but had we been doing cross-protocol tests sooner, we\nmight have looked at it more in the design phase.\n\nSo I would also be OK with just marking it as as v0-only test.\n\n-Peff\n"},{"id":"372190","messageId":"20190321223615.53228-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":"20190321214827.GA22582@sigill.intra.peff.net","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-03-21T22:36:15Z","receivedAt":"2019-03-21T22:36:21Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> On Thu, Mar 21, 2019 at 01:24:35PM -0700, Jonathan Tan wrote:\n> \n> > > The test you're deleting is basically just verifying that our apache\n> > > config is indeed \"half-auth\". Because in v0, the server is never even\n> > > going to ask for credentials, so no interesting code paths in the client\n> > > are triggered. So it's not actually testing anything of interest.\n> > \n> > If both of us want to drop this test, that's great :-) but for\n> > clarification: in addition to verifying that our apache config is\n> > \"half-auth\", this test also verifies that in a no-op fetch, we don't hit\n> > the path that is guarded by an authentication requirement. This seems\n> > significant to me in light of the link you provided in your prior email\n> > [1].\n> \n> Yeah, I suppose it does. I just never really thought of that as a\n> plausible regression to introduce, given the way the v0 protocol works. :)\n> \n> Although in a sense it is interesting, because it did reveal something\n> about v2 that we hadn't considered. I don't think it's worth addressing\n> (especially now), but had we been doing cross-protocol tests sooner, we\n> might have looked at it more in the design phase.\n> \n> So I would also be OK with just marking it as as v0-only test.\n\nOK - I'll wait to see what others think. Thanks for looking at this so\nfar.\n"},{"id":"372193","messageId":"xmqq36nfsl8t.fsf@gitster-ct.c.googlers.com","threadId":"50797","inReplyTo":"20190321174719.151877-1-jonathantanmy@google.com","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-22T02:20:34Z","receivedAt":"2019-03-22T02:20:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Tan <jonathantanmy@google.com> writes:\n\n> Because this configuration is not supported by all protocol versions,\n> and because this configuration seems to be of limited usefulness (only\n> useful for people who use manual credential entry and on servers that\n> are OK with exposing refs but not objects, and even in this case, helps\n> only in a no-op fetch), delete the test that verifies that this\n> configuration works.\n\nA possible and different conclusion that naturally follow your first\n\"because\" could be \"fix protocol versions whose support of this\nconfiguration is broken\", and your second \"because\" is with \"seems\nto be\", that makes it quite weak.\n\nQuite honestly, I hate to see a proposed log message that downplays\nits potential negative effects without sufficient justification.\n\nIsn't this feature primarily for those who want to poll from an\nautomated job (and naturally you want to assign as little privilege\nas possible to such an automated job) with ls-remote and only run an\nauthenticated fetch, perhaps manually, with or without cred helper,\nwhen the automated polling job finds there is something worthwhile\nto fetch?  What this test is checking seems to be a quite effective\nway to achieve that useful workflow, at least to me, and offhand I\ndo not think of other ways to easily achieve the same.\n\nThe \"ls-remote\" communication may not even touch any outside network\nbut may be happening all within a single organization, in which case\n\"are OK with exposing refs\" is making a security mountain out of a\nmolehill.  If it were a truly problematic hole that makes it a\nsecurity issue, wouldn't we deleting this test and at the same time\nplugging the hole for earlier protocol versions?\n\nHaving said all that, I do not care too deeply.  Would a much better\nlonger-term solution for those who want to poll and fetch only when\nthere is something new be to allow clients to subscribe to a feed\nthat hangs while there is nothing new, and lets the upstream side\ncontinuously feed incremental updates to the receiving client, as\nits refs are updated, or something?  As long as such a thing is in\nour vision (it is OK if nobody is currently working on it) to become\nreplacement, I do not think it is a huge loss to lose the ability for\nunauthenticated ls-remote with authenticated fetch.\n\nThanks.\n\n\n"},{"id":"372260","messageId":"20190322172023.238242-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":"xmqq36nfsl8t.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-03-22T17:20:23Z","receivedAt":"2019-03-22T17:20:29Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> Jonathan Tan <jonathantanmy@google.com> writes:\n> \n> > Because this configuration is not supported by all protocol versions,\n> > and because this configuration seems to be of limited usefulness (only\n> > useful for people who use manual credential entry and on servers that\n> > are OK with exposing refs but not objects, and even in this case, helps\n> > only in a no-op fetch), delete the test that verifies that this\n> > configuration works.\n> \n> A possible and different conclusion that naturally follow your first\n> \"because\" could be \"fix protocol versions whose support of this\n> configuration is broken\", and your second \"because\" is with \"seems\n> to be\", that makes it quite weak.\n> \n> Quite honestly, I hate to see a proposed log message that downplays\n> its potential negative effects without sufficient justification.\n\nThat is true, and that's fair.\n\n> Isn't this feature primarily for those who want to poll from an\n> automated job (and naturally you want to assign as little privilege\n> as possible to such an automated job) with ls-remote and only run an\n> authenticated fetch, perhaps manually, with or without cred helper,\n> when the automated polling job finds there is something worthwhile\n> to fetch?  What this test is checking seems to be a quite effective\n> way to achieve that useful workflow, at least to me, and offhand I\n> do not think of other ways to easily achieve the same.\n> \n> The \"ls-remote\" communication may not even touch any outside network\n> but may be happening all within a single organization, in which case\n> \"are OK with exposing refs\" is making a security mountain out of a\n> molehill.  If it were a truly problematic hole that makes it a\n> security issue, wouldn't we deleting this test and at the same time\n> plugging the hole for earlier protocol versions?\n\nThanks - that's a reasonable use case.\n\n> Having said all that, I do not care too deeply.  Would a much better\n> longer-term solution for those who want to poll and fetch only when\n> there is something new be to allow clients to subscribe to a feed\n> that hangs while there is nothing new, and lets the upstream side\n> continuously feed incremental updates to the receiving client, as\n> its refs are updated, or something?  As long as such a thing is in\n> our vision (it is OK if nobody is currently working on it) to become\n> replacement, I do not think it is a huge loss to lose the ability for\n> unauthenticated ls-remote with authenticated fetch.\n\nI just remembered that one way we can support the existing use case is\nto inline the ls-refs call that we make as an Extra Parameter [1]. This\nwould restore the ability to obtain refs through only the info/refs\npath.\n\nPerhaps this is the component in our vision that we need - I'll write\nanother patch that merely forces GIT_TEST_PROTOCOL_VERSION=0 and has a\nNEEDSWORK comment that explains this. \n\n[1] https://github.com/git/git/blob/master/Documentation/technical/pack-protocol.txt\n"},{"id":"372269","messageId":"20190322190139.151189-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":"20190321174719.151877-1-jonathantanmy@google.com","subject":"[PATCH v2] t5551: mark half-auth no-op fetch test as v0-only","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-03-22T19:01:39Z","receivedAt":"2019-03-22T19:01:46Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"When using protocol v0, upload-pack over HTTP permits a \"half-auth\"\nconfiguration in which, at the web server layer, the info/refs path is\nnot protected by authentication but the git-upload-pack path is, so that\na user can perform fetches that do not download any objects without\nauthentication, but still needs authentication to download objects.\n\nBut protocol v2 does not support this, because both ref and pack are\nobtained from the git-upload-pack path.\n\nMark the test verifying this behavior as protocol v0-only, with a\ndescription of what needs to be done to make v2 support this.\n\nSigned-off-by: Jonathan Tan <jonathantanmy@google.com>\n---\nThis is based on master + jt/test-protocol-version, but should apply\ncleanly to many places.\n\nAfter reading Peff's and Junio's replies, it seems that it would be\nbetter to retain this test. So here's a version that retains the test\nbut just marks it as v0, with an explanation as to what needs to be done\nto make v2 be compatible with it.\n---\n t/t5551-http-fetch-smart.sh | 12 +++++++++++-\n 1 file changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh\nindex a685d3edb6..c760514716 100755\n--- a/t/t5551-http-fetch-smart.sh\n+++ b/t/t5551-http-fetch-smart.sh\n@@ -164,7 +164,17 @@ test_expect_success 'clone from auth-only-for-objects repository' '\n \n test_expect_success 'no-op half-auth fetch does not require a password' '\n \tset_askpass wrong &&\n-\tgit --git-dir=half-auth fetch &&\n+\n+\t# NEEDSWORK: When using HTTP(S), protocol v0 supports a \"half-auth\"\n+\t# configuration with authentication required only when downloading\n+\t# objects and not refs, by having the HTTP server only require\n+\t# authentication for the \"git-upload-pack\" path and not \"info/refs\".\n+\t# This is not possible with protocol v2, since both objects and refs\n+\t# are obtained from the \"git-upload-pack\" path. A solution to this is\n+\t# to teach the server and client to be able to inline ls-refs requests\n+\t# as an Extra Parameter (see pack-protocol.txt), so that \"info/refs\"\n+\t# can serve refs, just like it does in protocol v0.\n+\tGIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch &&\n \texpect_askpass none\n '\n \n-- \n2.21.0.155.ge902e9bcae.dirty\n\n"},{"id":"372298","messageId":"20190323070548.GA24065@sigill.intra.peff.net","threadId":"50797","inReplyTo":"20190322190139.151189-1-jonathantanmy@google.com","subject":"Re: [PATCH v2] t5551: mark half-auth no-op fetch test as v0-only","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-23T07:05:48Z","receivedAt":"2019-03-23T07:05:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2019 at 12:01:39PM -0700, Jonathan Tan wrote:\n\n> When using protocol v0, upload-pack over HTTP permits a \"half-auth\"\n> configuration in which, at the web server layer, the info/refs path is\n> not protected by authentication but the git-upload-pack path is, so that\n> a user can perform fetches that do not download any objects without\n> authentication, but still needs authentication to download objects.\n> \n> But protocol v2 does not support this, because both ref and pack are\n> obtained from the git-upload-pack path.\n> \n> Mark the test verifying this behavior as protocol v0-only, with a\n> description of what needs to be done to make v2 support this.\n\nThanks, this looks like a fine solution to me.\n\nI do not really expect anyone will ever get around to this NEEDSWORK,\nbut we can see. :)\n\n-Peff\n"},{"id":"373283","messageId":"20190406113113.GA219876@google.com","threadId":"50797","inReplyTo":"20190322190139.151189-1-jonathantanmy@google.com","subject":"Re: [PATCH v2] t5551: mark half-auth no-op fetch test as v0-only","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-04-06T11:31:13Z","receivedAt":"2019-04-06T11:31:18Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJonathan Tan wrote:\n\n> When using protocol v0, upload-pack over HTTP permits a \"half-auth\"\n> configuration in which, at the web server layer, the info/refs path is\n> not protected by authentication but the git-upload-pack path is, so that\n> a user can perform fetches that do not download any objects without\n> authentication, but still needs authentication to download objects.\n>\n> But protocol v2 does not support this, because both ref and pack are\n> obtained from the git-upload-pack path.\n>\n> Mark the test verifying this behavior as protocol v0-only, with a\n> description of what needs to be done to make v2 support this.\n>\n> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>\n\nThanks for the analysis.  Makes sense.\n\n> --- a/t/t5551-http-fetch-smart.sh\n> +++ b/t/t5551-http-fetch-smart.sh\n> @@ -164,7 +164,17 @@ test_expect_success 'clone from auth-only-for-objects repository' '\n>  \n>  test_expect_success 'no-op half-auth fetch does not require a password' '\n>  \tset_askpass wrong &&\n> -\tgit --git-dir=half-auth fetch &&\n> +\n> +\t# NEEDSWORK: When using HTTP(S), protocol v0 supports a \"half-auth\"\n> +\t# configuration with authentication required only when downloading\n> +\t# objects and not refs, by having the HTTP server only require\n> +\t# authentication for the \"git-upload-pack\" path and not \"info/refs\".\n> +\t# This is not possible with protocol v2, since both objects and refs\n> +\t# are obtained from the \"git-upload-pack\" path. A solution to this is\n> +\t# to teach the server and client to be able to inline ls-refs requests\n> +\t# as an Extra Parameter (see pack-protocol.txt), so that \"info/refs\"\n> +\t# can serve refs, just like it does in protocol v0.\n> +\tGIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch &&\n>  \texpect_askpass none\n\nI suspect it's fine if protocol v2 never supports this.  Can we change\nthe NEEDSWORK comment to say that the protocol v2 spec should document\nthe lack of support for half-auth?\n\nWith or without such a change,\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks.\n"},{"id":"373434","messageId":"20190408170125.124345-1-jonathantanmy@google.com","threadId":"50797","inReplyTo":"20190406113113.GA219876@google.com","subject":"Re: [PATCH v2] t5551: mark half-auth no-op fetch test as v0-only","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-04-08T17:01:25Z","receivedAt":"2019-04-08T17:01:30Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> > +\t# NEEDSWORK: When using HTTP(S), protocol v0 supports a \"half-auth\"\n> > +\t# configuration with authentication required only when downloading\n> > +\t# objects and not refs, by having the HTTP server only require\n> > +\t# authentication for the \"git-upload-pack\" path and not \"info/refs\".\n> > +\t# This is not possible with protocol v2, since both objects and refs\n> > +\t# are obtained from the \"git-upload-pack\" path. A solution to this is\n> > +\t# to teach the server and client to be able to inline ls-refs requests\n> > +\t# as an Extra Parameter (see pack-protocol.txt), so that \"info/refs\"\n> > +\t# can serve refs, just like it does in protocol v0.\n> > +\tGIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch &&\n> >  \texpect_askpass none\n> \n> I suspect it's fine if protocol v2 never supports this.  Can we change\n> the NEEDSWORK comment to say that the protocol v2 spec should document\n> the lack of support for half-auth?\n> \n> With or without such a change,\n> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks for your review. Junio brought up a possible workflow that uses\nthis feature [1] and while I don't know if we will ever get around to\nsupporting half-auth in v2, it seems better to me to leave the\npossibility open.\n\n[1] https://public-inbox.org/git/xmqq36nfsl8t.fsf@gitster-ct.c.googlers.com/\n"}]}