[PATCH v2 0/5] Introduce 'uploadpack.lazyFetchTrusted'
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Aug 13, 2026, 15:47 UTC
- Message-ID
- <20260813154748.2378747-1-christian.couder@gmail.com>
- In-Reply-To
- <20260807135511.1818458-1-christian.couder@gmail.com>
Recently the "promisor-remote" capability was added to protocol v2, allowing servers and clients to agree on the promisor remotes they can safely use.
The more servers use promisor remotes, the more it is important to properly control if they can lazy fetch when responding to a clone or fetch request from the client.
For example, in the context of large object promisors (see "Documentation/technical/large-object-promisors.adoc"), if a client clones with a filter set to 100kB while the server has moved all of the blobs >= 10kB to a promisor remote, the server will not be able to provide blobs between 10kB and 100kB to the client, which will make the clone fail.
Even if the `--filter=auto` option is available since ef2f1845ec (fetch-pack: wire up and enable auto filter logic, 2026-02-16) it's still a good idea to provide more control over lazy fetching on the server side to server operators, as lazy fetching on the server side could be useful in corporate environments.
Since 7b70e9efb1 (upload-pack: disable lazy-fetching by default, 2024-04-16), lazy fetching has been controlled by the `GIT_NO_LAZY_FETCH` environment variable. This is a boolean that is set to 'true' by default when calling `git upload-pack` for security reasons.
The main security issue on the server side is making sure the served repo itself is also trusted, as lazily fetching runs `git fetch`, which may execute arbitrary commands specified in the configuration and hooks of the served repo. The operator of the server should decide and mark that trust, not the served repo itself, nor the client.
This series introduces a new 'uploadpack.lazyFetchTrusted' protected configuration variable similar to 'safe.directory' (see "Documentation/config/safe.adoc") to mark trusted repos where lazy fetching is allowed. As it is protected, this config variable will only take effect if it is set in global or system scope, so only server operators can control it.
Previous related work =====================
A previous series called "Introduce a 'fromAccepted' option to GIT_NO_LAZY_FETCH" [1] took a different approach as it wanted to make it easier to allow lazy fetching from accepted promisor remotes. But after brian replied that he didn't think it was a good idea, and after thinking about this more, my opinion now is that some promisor remotes being accepted or not is not really relevant to the issue.
In my reply to brian, I said:
"""
Different features could be developed (in future work) to improve on
the current state:
- a way for lazy fetching to work without reading config files,
triggering hooks, or doing potentially sensitive things,
- an explicit way for operators to mark trusted repos (like
perhaps a server-side config the operator sets per-repo),
- operator-defined allow/deny rules, or maybe
- some ways/scripts/commands to scan repos and check configuration
information, remote settings and everything potentially sensitive to
decide if a repo looks safe enough to allow lazy fetching or not.
"""So I decided to go with "an explicit way for operators to mark trusted repos" and this series is an implementation of that.
Note that the feature developed in this series applies to protocol v0/v1 as well as v2 while the previous one was only related to v2.
[1]: https://lore.kernel.org/git/CAP8UFD0_S9eg_w42tcNRnT9E2ntLr_eHLnzE4c2dSu67DzZoXg@mail.gmail.com/
Overview of the patches =======================
- Patch 1/5 is the only patch saved from the "Introduce a
'fromAccepted' option to GIT_NO_LAZY_FETCH" series. It's not
necessary for the rest of this series and its main feature to
work, but I think it's a nice refactoring related to lazy
fetching, so it might as well be part of this series. There is a
small change in the commit message (to not mention following
commits) compared to the version in the previous series. - Patches 2/5 and 3/5 extract and modify code used by the
'safe.directory' config variable in a path_allowlist_apply()
function, so that this function can be reused to process
'uploadpack.lazyFetchTrusted' in the next patch. - Patch 4/5 actually uses path_allowlist_apply() from a new
upload_pack_lazy_fetch_trusted() function to process
'uploadpack.lazyFetchTrusted', but the result from that processing
isn't actually used to have a practical effect. - Patch 5/5 wires up the new upload_pack_lazy_fetch_trusted()
function to decide if lazy fetching can actually be enabled.Changes since v1 ================
The only change is that the Signed-off-by email address has been fixed to "christian.couder@gmail.com", which is my primary address in ".mailmap" since 6375b40aea (mailmap: change primary address for Christian Couder, 2026-08-03).
This version is also sent as a separate 'v2' iteration in reply to v1, instead of being threaded onto the previous "Introduce a 'fromAccepted' option to GIT_NO_LAZY_FETCH" series, and it now contains a 'base-commit' trailer, so that 'b4' and other tools can find the right base and the right patches.
CI tests ========
I didn't run them as only commit messages changed since v1.
Range diff with v1 ==================
1: b5b0836d19 ! 1: 1605740203 promisor-remote: factor out lazy_fetch_objects()
@@ Commit message
'bool' instead of 'int', as it just returns whether all the objects
could be fetched, and document its return value.
- Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
+ Signed-off-by: Christian Couder <christian.couder@gmail.com>
## promisor-remote.c ##
@@ promisor-remote.c: static int fetch_objects(struct repository *repo,
2: 879e3a34e3 ! 2: 5f226b6508 setup: extract path_allowlist_apply()
@@ Commit message
While at it let's make the helper's code simpler and more generic.
- Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
+ Signed-off-by: Christian Couder <christian.couder@gmail.com>
## setup.c ##
@@ setup.c: static int canonicalize_ceiling_entry(struct string_list_item *item,
3: 98431ab7b3 ! 3: 051aa11fc9 setup: add 'allow_dot' arg to path_allowlist_apply()
@@ Commit message
While at it let's document it properly in "setup.h".
- Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
+ Signed-off-by: Christian Couder <christian.couder@gmail.com>
## setup.c ##
@@ setup.c: static int canonicalize_ceiling_entry(struct string_list_item *item,
4: a46f4c1bb8 ! 4: 045b5e647b upload-pack: read uploadpack.lazyFetchTrusted
@@ Commit message
Note that the new config variable should be read only from protected
configuration files.
- Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
+ Signed-off-by: Christian Couder <christian.couder@gmail.com>
## upload-pack.c ##
@@
5: 4063f233aa ! 5: c116661202 builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo
@@ Commit message
Now that "uploadpack.lazyFetchTrusted" is actually doing something,
let's document it and reference it from GIT_NO_LAZY_FETCH's docs.
- Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
+ Signed-off-by: Christian Couder <christian.couder@gmail.com>
## Documentation/config/uploadpack.adoc ##
@@ Documentation/config/uploadpack.adoc: uploadpack.allowRefInWant::Christian Couder (5): promisor-remote: factor out lazy_fetch_objects() setup: extract path_allowlist_apply() setup: add 'allow_dot' arg to path_allowlist_apply() upload-pack: read uploadpack.lazyFetchTrusted builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo
Documentation/config/uploadpack.adoc | 42 ++++++++++ Documentation/git-upload-pack.adoc | 5 ++ Documentation/git.adoc | 4 +- builtin/upload-pack.c | 11 +++ promisor-remote.c | 76 ++++++++++-------- setup.c | 108 ++++++++++++++------------ setup.h | 28 +++++++ t/t5710-promisor-remote-capability.sh | 70 +++++++++++++++++ upload-pack.c | 37 +++++++++ upload-pack.h | 3 + 10 files changed, 304 insertions(+), 80 deletions(-)
base-commit: 745601a9a94110d74769ab605ccd4f61339758d2
-- 2.55.0.565.gc116661202