From: Toon Claes <toon@iotcl.com>

Like so many other open source projects, the Git project has seen an
ever-increasing flood of security reports. Many of those reports
describe valid bugs yet are redirected from the git-security mailing
list because they are deemed "not vulnerabilities". While some Git
contributors seem to have a very concrete idea how to discern between
bugs that constitute vulnerabilities (and hence must be fixed in secret,
to keep Git users safe) from bugs that can be fixed in the open, most
reporters must be quite puzzled because the Git project provides no
clear document to help define the security boundaries Git tries to
guarantee.

Of course, there _are_ hints and bits and pieces of documentation: Git's
security guidance has accumulated across individual fixes. Some might be
tempted to describe the boundary as "before clone" versus "after clone",
but history establishes a more precise distinction. e69ac42fcc8 (docs:
document security issues around untrusted .git dirs, 2024-04-16)
explains why cloned content can generally be inspected with `git log`:
repository-local hooks and configuration are not copied, whereas an
untrusted `.git` directory remains unsafe. 779ea9303a7 (Documentation:
define protected configuration, 2022-07-14) likewise ties trust to
configuration scope rather than timing alone.

State the governing principle in one place: Git's security boundary
concerns unexpected or implicit execution of attacker-controlled code. A
theoretical opportunity to inspect repository contents is not consent to
execute them. Conversely, explicitly choosing an execution-capable
mechanism is materially different. Execution after clone is therefore
not inherently a vulnerability.

This distinction underlies 4cd1cf31efe (Git 2.20.2, 2019-12-04), which
describes CVE-2019-19604 as code running during recursive clone plus a
submodule update "without the user explicitly having asked for that".
a1d4f67c12ac (transport: make protocol.file.allow be user by default,
2022-07-29) likewise contrasts direct user action with recursion lacking
user input. e4930e86c0d (t5510: verify that D/F confusion cannot lead to
an RCE, 2024-03-24) similarly frames remote code execution as code run
by an operation not expected to run it.

Timing remains relevant when it removes any meaningful choice.
873a466ea3f (clone: drop the protections where hooks aren't run,
2024-05-20) notes that clone-time hook execution leaves no chance to
inspect first. Conversely, 8d1a7448206 (setup.c: create
safe.bareRepository, 2022-07-14) addresses post-clone use of embedded
bare repositories. Together these cases show why timing alone cannot
define the boundary.

Assisted-by: GPT-5.6 Sol
Helped-by: Patrick Steinhardt <ps@pks.im>
Helped-by: Junio C Hamano <gitster@pobox.com>
Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Toon Claes <toon@iotcl.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Submitted-As: https://lore.kernel.org/git/pull.2286.git.1793362370899.gitgitgadget@gmail.com