Toon ClaesandJohannes Schindelin
8bfbb74442
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.e69ac42fcc(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.779ea9303a(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 underlies4cd1cf31ef(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".a1d4f67c12(transport: make protocol.file.allow be user by default, 2022-07-29) likewise contrasts direct user action with recursion lacking user input.e4930e86c0(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.873a466ea3(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,8d1a744820(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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2.1 KiB
Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable vulnerability, it is recommended to send the report to git-security@googlegroups.com (and obviously not to discuss the issue anywhere else).
See the security boundary documentation for a discussion of what Git considers to be within its security boundary.
Vulnerabilities are expected to be discussed only on that list, and not in public, until the official announcement on the Git mailing list on the release date.
Examples for details to include:
- Ideally a short description (or a script) to demonstrate an exploit.
- The affected platforms and scenarios (the vulnerability might only affect setups with case-sensitive file systems, for example).
- The name and affiliation of the security researchers who are involved in the discovery, if any.
- Whether the vulnerability has already been disclosed.
- How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git. Instead, the maintenance track (i.e. the versions based on the most recently published feature release, also known as ".0" version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for the latest feature release and merged up to the in-development branches. The Git project makes no formal guarantee for any older maintenance tracks to receive updates. In practice, though, critical vulnerability fixes are applied not only to the most recent track, but to at least a couple more maintenance tracks.
This is typically done by making the fix on the oldest and still relevant maintenance track, and merging it upwards to newer and newer maintenance tracks.
For example, v2.24.1 was released to address a couple of CVEs, and at the same time v2.14.6, v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1, v2.22.2 and v2.23.1 were released.