Re: [PATCH 0/3] Introduce a 'fromAccepted' option to GIT_NO_LAZY_FETCH

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 10, 2026, 19:50 UTC
Message-ID: <alFM-4FJQfaEjyju@fruit.crustytoothpaste.net>
In-Reply-To: <20260710085137.4171240-1-christian.couder@gmail.com>

On 2026-07-10 at 08:51:34, Christian Couder wrote:

Show 25 quoted lines

> 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 currently an "all or
> nothing" boolean that is set to 'true' by default when calling `git
> upload-pack` for security reasons.
> 
> Recently the "promisor-remote" capability was added to protocol v2,
> allowing servers and clients to agree on the promisor remotes they
> can safely use.
> 
> This series leverages that capability to implement a pragmatic middle
> ground. By setting `GIT_NO_LAZY_FETCH` to 'fromAccepted', lazy
> fetching is allowed only when fetching from promisor remotes that are
> both advertised by the server and accepted by the client.
> 
> Note that using an environment variable for this is probably not the
> best from a usability perspective. An `upload-pack.allowLazyFetch`
> configuration variable would likely be better.
> 
> Unfortunately the `GIT_NO_LAZY_FETCH` environment variable is the way
> things currently work. It would be a much bigger and more invasive
> change to implement `upload-pack.allowLazyFetch` in a way that is
> compatible with `GIT_NO_LAZY_FETCH` which has to stay anyway for
> backward compatibility. Therefore, transitioning to a configuration
> variable is left for future work.

I don't think this is a good idea. We get a lot of reports on the security list involving various tooling that isn't within the scope of our threat model. This substantially increases the amount of code which is now subject to that threat model and therefore our security guarantees and I don't think we should do that as it stands, very especially while so much of our network-facing code is written in C.

The fetch code by default reads lots of configuration information from the repository, including remote settings and information and we really want absolutely none of that code running in the context of an untrusted repository.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA