Files
git/Documentation/git-upload-pack.adoc
T
Christian Couder 85c7f5e7da builtin/upload-pack: don't disable lazy fetching on trusted repo
A previous commit added a new "uploadpack.lazyFetchTrusted" protected
config variable that can contain an allowlist of repos, as well as
functions to check if the current repo is in that list. But when the
current repo is in that list, we currently do nothing.

Since 7b70e9efb1 (upload-pack: disable lazy-fetching by default,
2024-04-16), `upload-pack` sets `GIT_NO_LAZY_FETCH` to 1 itself,
unconditionally, because by default it shouldn't trust the repositories
it serves. Lazily fetching runs `git fetch`, which may execute
arbitrary commands specified in the configuration and hooks of the
served repo.

The new "uploadpack.lazyFetchTrusted" protected config variable is not
about overriding an environment variable. It's rather about teaching
the code that automatically sets `GIT_NO_LAZY_FETCH` (because it had no
way to know if the served repo could be trusted) to look at the new
config variable to find out if a server operator actually vouched for
that repo.

Let's implement that, so we now have the following cases:

  - if `GIT_NO_LAZY_FETCH` is already set, we honor it and leave it
    alone, as it comes from the server operator,

  - otherwise, if the served repo is in the
    "uploadpack.lazyFetchTrusted" allowlist, we don't disable lazy
    fetching,

  - otherwise, we disable lazy fetching, as we used to.

This allows `upload-pack` and its `pack-objects` child process to
lazily fetch the objects they need to serve a client, for example when
the filter used by the client and the one used by the server don't
match.

Note that what a server operator vouches for by listing a repo there
is that the promisor remotes this repo is configured to lazily fetch
from, as well as its configuration and hooks, are trustworthy. Whether
a client trusts the repo it fetches from is a separate matter, and up
to the client.

As `pack-objects`, which performs the lazy fetch when serving a
client, is a child process of `upload-pack`, not setting
`GIT_NO_LAZY_FETCH` in `upload-pack` is enough for it to be allowed to
lazily fetch, without any further plumbing.

On the other hand, as we leave `GIT_NO_LAZY_FETCH` unset for a trusted
repo instead of setting it to 0, the trust doesn't propagate: if a
trusted repo lazily fetches from a promisor remote that is itself
served by `upload-pack` on the same machine, that nested `upload-pack`
decides for its own repo. This is unlike when a server operator sets
`GIT_NO_LAZY_FETCH` to 0, as that is inherited by all child processes.

Now that "uploadpack.lazyFetchTrusted" is actually doing something,
let's document it (including this difference with `GIT_NO_LAZY_FETCH`),
let's reference it from `GIT_NO_LAZY_FETCH`'s docs, and let's add tests
for it.

Signed-off-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-10-02 07:40:34 -07:00

104 lines
3.3 KiB
Plaintext

git-upload-pack(1)
==================
NAME
----
git-upload-pack - Send objects packed back to git-fetch-pack
SYNOPSIS
--------
[verse]
'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
[--advertise-refs] <directory>
DESCRIPTION
-----------
Invoked by 'git fetch-pack', learns what
objects the other side is missing, and sends them after packing.
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git fetch-pack' side, and the
program pair is meant to be used to pull updates from a remote
repository. For push operations, see 'git send-pack'.
OPTIONS
-------
--strict::
--no-strict::
Do not try <directory>/.git/ if <directory> is not a Git directory.
--timeout=<n>::
Interrupt transfer after <n> seconds of inactivity.
--stateless-rpc::
Perform only a single read-write cycle with stdin and stdout.
This fits with the HTTP POST request processing model where
a program may read the request, write a response, and must exit.
--http-backend-info-refs::
Used by linkgit:git-http-backend[1] to serve up
`$GIT_URL/info/refs?service=git-upload-pack` requests. See
"Smart Clients" in linkgit:gitprotocol-http[5] and "HTTP
Transport" in the linkgit:gitprotocol-v2[5]
documentation. Also understood by
linkgit:git-receive-pack[1].
<directory>::
The repository to sync from.
ENVIRONMENT
-----------
`GIT_PROTOCOL`::
Internal variable used for handshaking the wire protocol. Server
admins may need to configure some transports to allow this
variable to be passed. See the discussion in linkgit:git[1].
`GIT_NO_LAZY_FETCH`::
When cloning or fetching from a partial repository (i.e., one
itself cloned with `--filter`), the server-side `upload-pack`
may need to fetch extra objects from its upstream in order to
complete the request. By default, `upload-pack` will refuse to
perform such a lazy fetch, because `git fetch` may run arbitrary
commands specified in configuration and hooks of the source
repository (and `upload-pack` tries to be safe to run even in
untrusted `.git` directories).
+
This is implemented by having `upload-pack` internally set the
`GIT_NO_LAZY_FETCH` variable to `1`. If you want to override it
(because you are fetching from a partial clone, and you are sure
you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to
`0`. As it is an environment variable, it is also inherited by child
processes, including any `upload-pack` run to lazily fetch from a
promisor remote on the same machine.
+
Instead of setting `GIT_NO_LAZY_FETCH` to `0` in the environment, a
server operator can allow lazy fetching on a per-repository basis by
listing trusted repositories in the `uploadpack.lazyFetchTrusted`
configuration variable. See linkgit:git-config[1].
SECURITY
--------
Most Git commands should not be run in an untrusted `.git` directory
(see the section `SECURITY` in linkgit:git[1]). `upload-pack` tries to
avoid any dangerous configuration options or hooks from the repository
it's serving, making it safe to clone an untrusted directory and run
commands on the resulting clone.
For an extra level of safety, you may be able to run `upload-pack` as an
alternate user. The details will be platform dependent, but on many
systems you can run:
git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
SEE ALSO
--------
linkgit:gitnamespaces[7]
GIT
---
Part of the linkgit:git[1] suite