# [PATCH 0/4] some v2 capability advertisement cleanups 15 messages from 2024-02-28 to 2024-03-04. Participants: Jeff King, Junio C Hamano, Patrick Steinhardt. Thread: https://gitlist.dev/t/61026 ## Jeff King, 2024-02-28 22:46 Subject: [PATCH 0/4] some v2 capability advertisement cleanups Message-ID: <20240228224625.GA1158651@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240228224625.GA1158651%40coredump.intra.peff.net ``` While working on another series, I noticed that upload-pack will accept the "packfile-uris" directive even if we didn't advertise it. That's not a huge deal in practice, but the spec says we're not supposed to. And while cleaning that up, I noticed a bit of duplication in the existing advertisement/allow code. So patches 1-3 clean up the situation a bit, and then patch 4 tightens up the packfile-uris handling. There are some small textual conflicts with the series I just posted in: https://lore.kernel.org/git/20240228223700.GA1157826@coredump.intra.peff.net/ I'm happy to prepare this on top of that if it's easier. [1/4]: upload-pack: use repository struct to get config [2/4]: upload-pack: centralize setup of sideband-all config [3/4]: upload-pack: use existing config mechanism for advertisement [4/4]: upload-pack: only accept packfile-uris if we advertised it t/t5702-protocol-v2.sh | 18 +++++++++++++ upload-pack.c | 58 +++++++++++++++++++----------------------- 2 files changed, 44 insertions(+), 32 deletions(-) -Peff ``` ## Jeff King, 2024-02-28 22:46 Subject: [PATCH 1/4] upload-pack: use repository struct to get config Message-ID: <20240228224647.GA1158898@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240228224647.GA1158898%40coredump.intra.peff.net In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` Our upload_pack_v2() function gets a repository struct, but we ignore it totally. In practice this doesn't cause any problems, as it will never differ from the_repository. But in the spirit of taking a small step towards getting rid of the_repository, let's at least starting using it to grab config. There are probably other spots that could benefit, but it's a start. Note that we don't need to pass the repo for protected_config(); the whole point there is that we are not looking at repo config, so there is no repo-specific version of the function. For the v0 version of the protocol, we're not passed a repository struct, so we'll continue to use the_repository there. Signed-off-by: Jeff King --- upload-pack.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 2537affa90..e156c1e472 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -1385,9 +1385,10 @@ static int upload_pack_protected_config(const char *var, const char *value, return 0; } -static void get_upload_pack_config(struct upload_pack_data *data) +static void get_upload_pack_config(struct repository *r, + struct upload_pack_data *data) { - git_config(upload_pack_config, data); + repo_config(r, upload_pack_config, data); git_protected_config(upload_pack_protected_config, data); } @@ -1398,7 +1399,7 @@ void upload_pack(const int advertise_refs, const int stateless_rpc, struct upload_pack_data data; upload_pack_data_init(&data); - get_upload_pack_config(&data); + get_upload_pack_config(the_repository, &data); data.stateless_rpc = stateless_rpc; data.timeout = timeout; @@ -1771,7 +1772,7 @@ enum fetch_state { FETCH_DONE, }; -int upload_pack_v2(struct repository *r UNUSED, struct packet_reader *request) +int upload_pack_v2(struct repository *r, struct packet_reader *request) { enum fetch_state state = FETCH_PROCESS_ARGS; struct upload_pack_data data; @@ -1780,7 +1781,7 @@ int upload_pack_v2(struct repository *r UNUSED, struct packet_reader *request) upload_pack_data_init(&data); data.use_sideband = LARGE_PACKET_MAX; - get_upload_pack_config(&data); + get_upload_pack_config(r, &data); while (state != FETCH_DONE) { switch (state) { -- 2.44.0.rc2.424.gbdbf4d014b ``` ## Jeff King, 2024-02-28 22:47 Subject: [PATCH 2/4] upload-pack: centralize setup of sideband-all config Message-ID: <20240228224718.GB1158898@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240228224718.GB1158898%40coredump.intra.peff.net In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` We read uploadpack.allowsidebandall to set a matching flag in our upload_pack_data struct. But for our tests, we also respect GIT_TEST_SIDEBAND_ALL from the environment, and anybody looking at the flag in the struct needs to remember to check both. There's only one such piece of code now, but we're about to add another. So let's have the config step actually fold the environment value into the struct, letting the rest of the code use the flag in the obvious way. Signed-off-by: Jeff King --- upload-pack.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index e156c1e472..6bda20754d 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -1390,6 +1390,8 @@ static void get_upload_pack_config(struct repository *r, { repo_config(r, upload_pack_config, data); git_protected_config(upload_pack_protected_config, data); + + data->allow_sideband_all |= git_env_bool("GIT_TEST_SIDEBAND_ALL", 0); } void upload_pack(const int advertise_refs, const int stateless_rpc, @@ -1639,8 +1641,7 @@ static void process_args(struct packet_reader *request, continue; } - if ((git_env_bool("GIT_TEST_SIDEBAND_ALL", 0) || - data->allow_sideband_all) && + if (data->allow_sideband_all && !strcmp(arg, "sideband-all")) { data->writer.use_sideband = 1; continue; -- 2.44.0.rc2.424.gbdbf4d014b ``` ## Jeff King, 2024-02-28 22:48 Subject: [PATCH 3/4] upload-pack: use existing config mechanism for advertisement Message-ID: <20240228224818.GA1158952@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240228224818.GA1158952%40coredump.intra.peff.net In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` When serving a v2 capabilities request, we call upload_pack_advertise() to tell us the set of features we can advertise to the client. That involves looking at various config options, all of which need to be kept in sync with the rules we use in upload_pack_config to set flags like allow_filter, allow_sideband_all, and so on. If these two pieces of code get out of sync then we may refuse to respect a capability we advertised, or vice versa accept one that we should not. Instead, let's call the same config helper that we'll use for processing the actual client request, and then just pick the values out of the resulting struct. This is only a little bit shorter than the current code, but we don't repeat any policy logic (e.g., we don't have to worry about the magic sideband-all environment variable here anymore). And this reveals a gap in the existing code: there is no struct flag for the packfile-uris capability (we accept it even if it is not advertised, which we should not). We'll leave the advertisement code for now and deal with it in the next patch. Signed-off-by: Jeff King --- upload-pack.c | 26 ++++++++++---------------- 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 6bda20754d..491ef51daa 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -1841,41 +1841,35 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request) int upload_pack_advertise(struct repository *r, struct strbuf *value) { + struct upload_pack_data data; + + upload_pack_data_init(&data); + get_upload_pack_config(r, &data); + if (value) { - int allow_filter_value; - int allow_ref_in_want; - int allow_sideband_all_value; char *str = NULL; strbuf_addstr(value, "shallow wait-for-done"); - if (!repo_config_get_bool(r, - "uploadpack.allowfilter", - &allow_filter_value) && - allow_filter_value) + if (data.allow_filter) strbuf_addstr(value, " filter"); - if (!repo_config_get_bool(r, - "uploadpack.allowrefinwant", - &allow_ref_in_want) && - allow_ref_in_want) + if (data.allow_ref_in_want) strbuf_addstr(value, " ref-in-want"); - if (git_env_bool("GIT_TEST_SIDEBAND_ALL", 0) || - (!repo_config_get_bool(r, - "uploadpack.allowsidebandall", - &allow_sideband_all_value) && - allow_sideband_all_value)) + if (data.allow_sideband_all) strbuf_addstr(value, " sideband-all"); if (!repo_config_get_string(r, "uploadpack.blobpackfileuri", &str) && str) { strbuf_addstr(value, " packfile-uris"); free(str); } } + upload_pack_data_clear(&data); + return 1; } -- 2.44.0.rc2.424.gbdbf4d014b ``` ## Jeff King, 2024-02-28 22:50 Subject: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: <20240228225050.GA1159078@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240228225050.GA1159078%40coredump.intra.peff.net In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` Clients are only supposed to request particular capabilities or features if the server advertised them. For the "packfile-uris" feature, we only advertise it if uploadpack.blobpacfileuri is set, but we always accept a request from the client regardless. In practice this doesn't really hurt anything, as we'd pass the client's protocol list on to pack-objects, which ends up ignoring it. But we should try to follow the protocol spec, and tightening this up may catch buggy or misbehaving clients more easily. Thanks to recent refactoring, we can hoist the config check from upload_pack_advertise() into upload_pack_config(). Note the subtle handling of a value-less bool (which does not count for triggering an advertisement). Signed-off-by: Jeff King --- I suspect in the long term that we may have other ways to trigger this feature than the static blobpackfileuri config (e.g., a hook that knows about site-specific packfiles "somehow"). So we may need to update the test later for that, but presumably in the vanilla config we'll continue to skip advertising it. t/t5702-protocol-v2.sh | 18 ++++++++++++++++++ upload-pack.c | 16 +++++++--------- 2 files changed, 25 insertions(+), 9 deletions(-) diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index 6ef4971845..902e42c1c0 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -778,6 +778,24 @@ test_expect_success 'archive with custom path does not request v2' ' ! grep ^GIT_PROTOCOL env.trace ' +test_expect_success 'reject client packfile-uris if not advertised' ' + { + packetize command=fetch && + printf 0001 && + packetize packfile-uris https && + packetize done && + printf 0000 + } >input && + test_must_fail env GIT_PROTOCOL=version=2 \ + git upload-pack client allow_ref_in_want = git_config_bool(var, value); } else if (!strcmp("uploadpack.allowsidebandall", var)) { data->allow_sideband_all = git_config_bool(var, value); + } else if (!strcmp("uploadpack.blobpackfileuri", var)) { + if (value) + data->allow_packfile_uris = 1; } else if (!strcmp("core.precomposeunicode", var)) { precomposed_unicode = git_config_bool(var, value); } else if (!strcmp("transfer.advertisesid", var)) { @@ -1647,7 +1651,8 @@ static void process_args(struct packet_reader *request, continue; } - if (skip_prefix(arg, "packfile-uris ", &p)) { + if (data->allow_packfile_uris && + skip_prefix(arg, "packfile-uris ", &p)) { string_list_split(&data->uri_protocols, p, ',', -1); continue; } @@ -1847,8 +1852,6 @@ int upload_pack_advertise(struct repository *r, get_upload_pack_config(r, &data); if (value) { - char *str = NULL; - strbuf_addstr(value, "shallow wait-for-done"); if (data.allow_filter) @@ -1860,13 +1863,8 @@ int upload_pack_advertise(struct repository *r, if (data.allow_sideband_all) strbuf_addstr(value, " sideband-all"); - if (!repo_config_get_string(r, - "uploadpack.blobpackfileuri", - &str) && - str) { + if (data.allow_packfile_uris) strbuf_addstr(value, " packfile-uris"); - free(str); - } } upload_pack_data_clear(&data); -- 2.44.0.rc2.424.gbdbf4d014b ``` ## Junio C Hamano, 2024-02-28 23:43 Subject: Re: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: URL: https://gitlist.dev/e/xmqq5xy8jgtn.fsf%40gitster.g In-Reply-To: <20240228225050.GA1159078@coredump.intra.peff.net> ``` Jeff King writes: > I suspect in the long term that we may have other ways to trigger this > feature than the static blobpackfileuri config (e.g., a hook that knows > about site-specific packfiles "somehow"). So we may need to update the > test later for that, but presumably in the vanilla config we'll continue > to skip advertising it. Sounds quite sensible. Thanks for a series that is very pleasant to read. > > t/t5702-protocol-v2.sh | 18 ++++++++++++++++++ > upload-pack.c | 16 +++++++--------- > 2 files changed, 25 insertions(+), 9 deletions(-) > > diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh > index 6ef4971845..902e42c1c0 100755 > --- a/t/t5702-protocol-v2.sh > +++ b/t/t5702-protocol-v2.sh > @@ -778,6 +778,24 @@ test_expect_success 'archive with custom path does not request v2' ' > ! grep ^GIT_PROTOCOL env.trace > ' > > +test_expect_success 'reject client packfile-uris if not advertised' ' > + { > + packetize command=fetch && > + printf 0001 && > + packetize packfile-uris https && > + packetize done && > + printf 0000 > + } >input && > + test_must_fail env GIT_PROTOCOL=version=2 \ > + git upload-pack client + test_must_fail env GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri \ > + upload-pack client + GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri=anything \ > + upload-pack client +' > + > # Test protocol v2 with 'http://' transport > # > . "$TEST_DIRECTORY"/lib-httpd.sh > diff --git a/upload-pack.c b/upload-pack.c > index 491ef51daa..66f4de9d87 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -113,6 +113,7 @@ struct upload_pack_data { > unsigned done : 1; /* v2 only */ > unsigned allow_ref_in_want : 1; /* v2 only */ > unsigned allow_sideband_all : 1; /* v2 only */ > + unsigned allow_packfile_uris : 1; /* v2 only */ > unsigned advertise_sid : 1; > unsigned sent_capabilities : 1; > }; > @@ -1362,6 +1363,9 @@ static int upload_pack_config(const char *var, const char *value, > data->allow_ref_in_want = git_config_bool(var, value); > } else if (!strcmp("uploadpack.allowsidebandall", var)) { > data->allow_sideband_all = git_config_bool(var, value); > + } else if (!strcmp("uploadpack.blobpackfileuri", var)) { > + if (value) > + data->allow_packfile_uris = 1; > } else if (!strcmp("core.precomposeunicode", var)) { > precomposed_unicode = git_config_bool(var, value); > } else if (!strcmp("transfer.advertisesid", var)) { > @@ -1647,7 +1651,8 @@ static void process_args(struct packet_reader *request, > continue; > } > > - if (skip_prefix(arg, "packfile-uris ", &p)) { > + if (data->allow_packfile_uris && > + skip_prefix(arg, "packfile-uris ", &p)) { > string_list_split(&data->uri_protocols, p, ',', -1); > continue; > } > @@ -1847,8 +1852,6 @@ int upload_pack_advertise(struct repository *r, > get_upload_pack_config(r, &data); > > if (value) { > - char *str = NULL; > - > strbuf_addstr(value, "shallow wait-for-done"); > > if (data.allow_filter) > @@ -1860,13 +1863,8 @@ int upload_pack_advertise(struct repository *r, > if (data.allow_sideband_all) > strbuf_addstr(value, " sideband-all"); > > - if (!repo_config_get_string(r, > - "uploadpack.blobpackfileuri", > - &str) && > - str) { > + if (data.allow_packfile_uris) > strbuf_addstr(value, " packfile-uris"); > - free(str); > - } > } > > upload_pack_data_clear(&data); ``` ## Junio C Hamano, 2024-02-28 23:51 Subject: Re: [PATCH 0/4] some v2 capability advertisement cleanups Message-ID: URL: https://gitlist.dev/e/xmqq1q8wjgft.fsf%40gitster.g In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` Jeff King writes: > There are some small textual conflicts with the series I just posted in: > > https://lore.kernel.org/git/20240228223700.GA1157826@coredump.intra.peff.net/ > > I'm happy to prepare this on top of that if it's easier. Thanks for a heads-up. The other one merged first and then this one does give the following, which does not look like a huge deal. diff --cc upload-pack.c index 281bdf85c9,66f4de9d87..0000000000 --- i/upload-pack.c +++ w/upload-pack.c @@@ -113,7 -113,7 +113,8 @@@ struct upload_pack_data unsigned done : 1; /* v2 only */ unsigned allow_ref_in_want : 1; /* v2 only */ unsigned allow_sideband_all : 1; /* v2 only */ + unsigned seen_haves : 1; /* v2 only */ + unsigned allow_packfile_uris : 1; /* v2 only */ unsigned advertise_sid : 1; unsigned sent_capabilities : 1; }; @@@ -1648,10 -1651,8 +1654,11 @@@ static void process_args(struct packet_ continue; } - if (skip_prefix(arg, "packfile-uris ", &p)) { + if (data->allow_packfile_uris && + skip_prefix(arg, "packfile-uris ", &p)) { + if (data->uri_protocols.nr) + send_err_and_die(data, + "multiple packfile-uris lines forbidden"); string_list_split(&data->uri_protocols, p, ',', -1); continue; } ``` ## Jeff King, 2024-02-29 00:44 Subject: Re: [PATCH 0/4] some v2 capability advertisement cleanups Message-ID: <20240229004446.GA1654078@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240229004446.GA1654078%40coredump.intra.peff.net In-Reply-To: ``` On Wed, Feb 28, 2024 at 03:51:34PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > There are some small textual conflicts with the series I just posted in: > > > > https://lore.kernel.org/git/20240228223700.GA1157826@coredump.intra.peff.net/ > > > > I'm happy to prepare this on top of that if it's easier. > > Thanks for a heads-up. > > The other one merged first and then this one does give the > following, which does not look like a huge deal. Yep, that matches the resolution I did locally. -Peff ``` ## Jeff King, 2024-02-29 05:42 Subject: Re: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: <20240229054239.GA1669526@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240229054239.GA1669526%40coredump.intra.peff.net In-Reply-To: <20240228225050.GA1159078@coredump.intra.peff.net> ``` On Wed, Feb 28, 2024 at 05:50:50PM -0500, Jeff King wrote: > diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh > index 6ef4971845..902e42c1c0 100755 > --- a/t/t5702-protocol-v2.sh > +++ b/t/t5702-protocol-v2.sh > @@ -778,6 +778,24 @@ test_expect_success 'archive with custom path does not request v2' ' > ! grep ^GIT_PROTOCOL env.trace > ' > > +test_expect_success 'reject client packfile-uris if not advertised' ' > + { > + packetize command=fetch && > + printf 0001 && > + packetize packfile-uris https && > + packetize done && > + printf 0000 > + } >input && > + test_must_fail env GIT_PROTOCOL=version=2 \ > + git upload-pack client + test_must_fail env GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri \ > + upload-pack client + GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri=anything \ > + upload-pack client +' Sorry, this needs one tweak to pass under the sha256 CI job: diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index 902e42c1c0..1ef540f73d 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -781,6 +781,7 @@ test_expect_success 'archive with custom path does not request v2' ' test_expect_success 'reject client packfile-uris if not advertised' ' { packetize command=fetch && + packetize object-format=$(test_oid algo) && printf 0001 && packetize packfile-uris https && packetize done && Otherwise the server complains that the other side did not respect its advertised object-format (I sure am glad to have included the final "hey, this input works, right?" test there, as that is what caught it). -Peff ``` ## Junio C Hamano, 2024-02-29 16:34 Subject: Re: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: URL: https://gitlist.dev/e/xmqqmsrji5zr.fsf%40gitster.g In-Reply-To: <20240229054239.GA1669526@coredump.intra.peff.net> ``` Jeff King writes: > Sorry, this needs one tweak to pass under the sha256 CI job: > > diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh > index 902e42c1c0..1ef540f73d 100755 > --- a/t/t5702-protocol-v2.sh > +++ b/t/t5702-protocol-v2.sh > @@ -781,6 +781,7 @@ test_expect_success 'archive with custom path does not request v2' ' > test_expect_success 'reject client packfile-uris if not advertised' ' > { > packetize command=fetch && > + packetize object-format=$(test_oid algo) && > printf 0001 && > packetize packfile-uris https && > packetize done && > > Otherwise the server complains that the other side did not respect its > advertised object-format (I sure am glad to have included the final > "hey, this input works, right?" test there, as that is what caught it). Ah, good finding. Will use it to amend. I wonder if it is still worth testing if the command is happy with an input that lacks object-format capability under SHA-1 mode. This test piece is primarily about packfile-uris, so in that sense, we are not all that interested in that unspecified client object-format defaults to the initial value of serve.c:client_hash_algo (which is SHA-1), and not testing that here is perfectly fine, I guess. Thanks. ``` ## Jeff King, 2024-03-01 07:10 Subject: Re: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: <20240301071041.GA2682168@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240301071041.GA2682168%40coredump.intra.peff.net In-Reply-To: ``` On Thu, Feb 29, 2024 at 08:34:48AM -0800, Junio C Hamano wrote: > > Otherwise the server complains that the other side did not respect its > > advertised object-format (I sure am glad to have included the final > > "hey, this input works, right?" test there, as that is what caught it). > > Ah, good finding. Will use it to amend. > > I wonder if it is still worth testing if the command is happy with > an input that lacks object-format capability under SHA-1 mode. This > test piece is primarily about packfile-uris, so in that sense, we > are not all that interested in that unspecified client object-format > defaults to the initial value of serve.c:client_hash_algo (which is > SHA-1), and not testing that here is perfectly fine, I guess. Yeah, if we want to test it, I'd prefer to do so separately as its own test rather than keeping it as a subtle side effect of this one. I looked around to see if it might exist already, but I didn't find one (OTOH, it is hard to grep for since we are looking for the _absence_ of an object-format line in hand-crafted input). But taking a step back, why do we care about this case? It is because older clients that speak v2 but do not yet know about object-format will make a request without it, and they should still work in sha1 mode. So the more general thing to test here is whether those older versions can successfully fetch from a newer server. There are tests in t/interop for cloning and fetching from a different version. I kind of doubt anybody runs them regularly, though (and picking the interesting versions to find this case isn't entirely trivial). So I dunno. -Peff ``` ## Patrick Steinhardt, 2024-03-04 07:44 Subject: Re: [PATCH 0/4] some v2 capability advertisement cleanups Message-ID: URL: https://gitlist.dev/e/ZeV7-NkUwT53IvIa%40tanuki In-Reply-To: <20240228224625.GA1158651@coredump.intra.peff.net> ``` On Wed, Feb 28, 2024 at 05:46:25PM -0500, Jeff King wrote: > While working on another series, I noticed that upload-pack will accept > the "packfile-uris" directive even if we didn't advertise it. That's not > a huge deal in practice, but the spec says we're not supposed to. And > while cleaning that up, I noticed a bit of duplication in the existing > advertisement/allow code. > > So patches 1-3 clean up the situation a bit, and then patch 4 tightens > up the packfile-uris handling. This patch series was really easy to follow and feels like the right thing to do. I've got a couple of nits, but none of them are important enough to warrant a reroll. Thanks! Patrick > There are some small textual conflicts with the series I just posted in: > > https://lore.kernel.org/git/20240228223700.GA1157826@coredump.intra.peff.net/ > > I'm happy to prepare this on top of that if it's easier. > > [1/4]: upload-pack: use repository struct to get config > [2/4]: upload-pack: centralize setup of sideband-all config > [3/4]: upload-pack: use existing config mechanism for advertisement > [4/4]: upload-pack: only accept packfile-uris if we advertised it > > t/t5702-protocol-v2.sh | 18 +++++++++++++ > upload-pack.c | 58 +++++++++++++++++++----------------------- > 2 files changed, 44 insertions(+), 32 deletions(-) > > -Peff > ``` ## Patrick Steinhardt, 2024-03-04 07:45 Subject: Re: [PATCH 1/4] upload-pack: use repository struct to get config Message-ID: URL: https://gitlist.dev/e/ZeV7_obKou-jtyA-%40tanuki In-Reply-To: <20240228224647.GA1158898@coredump.intra.peff.net> ``` On Wed, Feb 28, 2024 at 05:46:47PM -0500, Jeff King wrote: > Our upload_pack_v2() function gets a repository struct, but we ignore it > totally. In practice this doesn't cause any problems, as it will never > differ from the_repository. But in the spirit of taking a small step > towards getting rid of the_repository, let's at least starting using it Nit: s/starting/start Patrick > to grab config. There are probably other spots that could benefit, but > it's a start. > > Note that we don't need to pass the repo for protected_config(); the > whole point there is that we are not looking at repo config, so there is > no repo-specific version of the function. > > For the v0 version of the protocol, we're not passed a repository > struct, so we'll continue to use the_repository there. > > Signed-off-by: Jeff King > --- > upload-pack.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/upload-pack.c b/upload-pack.c > index 2537affa90..e156c1e472 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -1385,9 +1385,10 @@ static int upload_pack_protected_config(const char *var, const char *value, > return 0; > } > > -static void get_upload_pack_config(struct upload_pack_data *data) > +static void get_upload_pack_config(struct repository *r, > + struct upload_pack_data *data) > { > - git_config(upload_pack_config, data); > + repo_config(r, upload_pack_config, data); > git_protected_config(upload_pack_protected_config, data); > } > > @@ -1398,7 +1399,7 @@ void upload_pack(const int advertise_refs, const int stateless_rpc, > struct upload_pack_data data; > > upload_pack_data_init(&data); > - get_upload_pack_config(&data); > + get_upload_pack_config(the_repository, &data); > > data.stateless_rpc = stateless_rpc; > data.timeout = timeout; > @@ -1771,7 +1772,7 @@ enum fetch_state { > FETCH_DONE, > }; > > -int upload_pack_v2(struct repository *r UNUSED, struct packet_reader *request) > +int upload_pack_v2(struct repository *r, struct packet_reader *request) > { > enum fetch_state state = FETCH_PROCESS_ARGS; > struct upload_pack_data data; > @@ -1780,7 +1781,7 @@ int upload_pack_v2(struct repository *r UNUSED, struct packet_reader *request) > > upload_pack_data_init(&data); > data.use_sideband = LARGE_PACKET_MAX; > - get_upload_pack_config(&data); > + get_upload_pack_config(r, &data); > > while (state != FETCH_DONE) { > switch (state) { > -- > 2.44.0.rc2.424.gbdbf4d014b > > ``` ## Patrick Steinhardt, 2024-03-04 07:45 Subject: Re: [PATCH 4/4] upload-pack: only accept packfile-uris if we advertised it Message-ID: URL: https://gitlist.dev/e/ZeV8BNCr0QN84ZQE%40tanuki In-Reply-To: <20240228225050.GA1159078@coredump.intra.peff.net> ``` On Wed, Feb 28, 2024 at 05:50:50PM -0500, Jeff King wrote: > Clients are only supposed to request particular capabilities or features > if the server advertised them. For the "packfile-uris" feature, we only > advertise it if uploadpack.blobpacfileuri is set, but we always accept a Nit: s/uploadpack.blobpackfileuri. I noticed that this isn't actually documented in git-config(1), but that's not a problem of this commit. > request from the client regardless. > > In practice this doesn't really hurt anything, as we'd pass the client's > protocol list on to pack-objects, which ends up ignoring it. But we > should try to follow the protocol spec, and tightening this up may catch > buggy or misbehaving clients more easily. > > Thanks to recent refactoring, we can hoist the config check from Nit: s/refactoring/&s. Patrick > upload_pack_advertise() into upload_pack_config(). Note the subtle > handling of a value-less bool (which does not count for triggering an > advertisement). > > Signed-off-by: Jeff King > --- > I suspect in the long term that we may have other ways to trigger this > feature than the static blobpackfileuri config (e.g., a hook that knows > about site-specific packfiles "somehow"). So we may need to update the > test later for that, but presumably in the vanilla config we'll continue > to skip advertising it. > > t/t5702-protocol-v2.sh | 18 ++++++++++++++++++ > upload-pack.c | 16 +++++++--------- > 2 files changed, 25 insertions(+), 9 deletions(-) > > diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh > index 6ef4971845..902e42c1c0 100755 > --- a/t/t5702-protocol-v2.sh > +++ b/t/t5702-protocol-v2.sh > @@ -778,6 +778,24 @@ test_expect_success 'archive with custom path does not request v2' ' > ! grep ^GIT_PROTOCOL env.trace > ' > > +test_expect_success 'reject client packfile-uris if not advertised' ' > + { > + packetize command=fetch && > + printf 0001 && > + packetize packfile-uris https && > + packetize done && > + printf 0000 > + } >input && > + test_must_fail env GIT_PROTOCOL=version=2 \ > + git upload-pack client + test_must_fail env GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri \ > + upload-pack client + GIT_PROTOCOL=version=2 \ > + git -c uploadpack.blobpackfileuri=anything \ > + upload-pack client +' > + > # Test protocol v2 with 'http://' transport > # > . "$TEST_DIRECTORY"/lib-httpd.sh > diff --git a/upload-pack.c b/upload-pack.c > index 491ef51daa..66f4de9d87 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -113,6 +113,7 @@ struct upload_pack_data { > unsigned done : 1; /* v2 only */ > unsigned allow_ref_in_want : 1; /* v2 only */ > unsigned allow_sideband_all : 1; /* v2 only */ > + unsigned allow_packfile_uris : 1; /* v2 only */ > unsigned advertise_sid : 1; > unsigned sent_capabilities : 1; > }; > @@ -1362,6 +1363,9 @@ static int upload_pack_config(const char *var, const char *value, > data->allow_ref_in_want = git_config_bool(var, value); > } else if (!strcmp("uploadpack.allowsidebandall", var)) { > data->allow_sideband_all = git_config_bool(var, value); > + } else if (!strcmp("uploadpack.blobpackfileuri", var)) { > + if (value) > + data->allow_packfile_uris = 1; > } else if (!strcmp("core.precomposeunicode", var)) { > precomposed_unicode = git_config_bool(var, value); > } else if (!strcmp("transfer.advertisesid", var)) { > @@ -1647,7 +1651,8 @@ static void process_args(struct packet_reader *request, > continue; > } > > - if (skip_prefix(arg, "packfile-uris ", &p)) { > + if (data->allow_packfile_uris && > + skip_prefix(arg, "packfile-uris ", &p)) { > string_list_split(&data->uri_protocols, p, ',', -1); > continue; > } > @@ -1847,8 +1852,6 @@ int upload_pack_advertise(struct repository *r, > get_upload_pack_config(r, &data); > > if (value) { > - char *str = NULL; > - > strbuf_addstr(value, "shallow wait-for-done"); > > if (data.allow_filter) > @@ -1860,13 +1863,8 @@ int upload_pack_advertise(struct repository *r, > if (data.allow_sideband_all) > strbuf_addstr(value, " sideband-all"); > > - if (!repo_config_get_string(r, > - "uploadpack.blobpackfileuri", > - &str) && > - str) { > + if (data.allow_packfile_uris) > strbuf_addstr(value, " packfile-uris"); > - free(str); > - } > } > > upload_pack_data_clear(&data); > -- > 2.44.0.rc2.424.gbdbf4d014b > ``` ## Jeff King, 2024-03-04 10:02 Subject: Re: [PATCH 0/4] some v2 capability advertisement cleanups Message-ID: <20240304100202.GC3723539@coredump.intra.peff.net> URL: https://gitlist.dev/e/20240304100202.GC3723539%40coredump.intra.peff.net In-Reply-To: ``` On Mon, Mar 04, 2024 at 08:44:56AM +0100, Patrick Steinhardt wrote: > On Wed, Feb 28, 2024 at 05:46:25PM -0500, Jeff King wrote: > > While working on another series, I noticed that upload-pack will accept > > the "packfile-uris" directive even if we didn't advertise it. That's not > > a huge deal in practice, but the spec says we're not supposed to. And > > while cleaning that up, I noticed a bit of duplication in the existing > > advertisement/allow code. > > > > So patches 1-3 clean up the situation a bit, and then patch 4 tightens > > up the packfile-uris handling. > > This patch series was really easy to follow and feels like the right > thing to do. I've got a couple of nits, but none of them are important > enough to warrant a reroll. Thanks for reviewing. The typos you found are definitely all wrong, but I think the topic is in 'next' already (and they were all just in the commit messages). -Peff ```