docs: document security issues around untrusted .git dirs

For a long time our general philosophy has been that it's unsafe to run
arbitrary Git commands if you don't trust the hooks or config in .git,
but that running upload-pack should be OK. E.g., see 1456b043fc (Remove
post-upload-hook, 2009-12-10), or the design of uploadpack.packObjectsHook.

But we never really documented this (and even the discussions that led
to 1456b043fc were not on the public list!). Let's try to make our
approach more clear, but also be realistic that even upload-pack carries
some risk.

Helped-by: Filip Hejsek <filip.hejsek@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit is contained in:
Jeff King
2024-04-16 04:52:13 -04:00
committed by Johannes Schindelin
parent 7b70e9efb1
commit e69ac42fcc
2 changed files with 46 additions and 0 deletions

View File

@ -71,6 +71,21 @@ This is implemented by having `upload-pack` internally set the
you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to
`0`.
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]