mirror of
https://github.com/git/git
synced 2024-08-24 18:26:02 +00:00
![Johannes Schindelin](/assets/img/avatar_default.png)
In the same document, describe that Git does not have Long Term Support (LTS) release trains, although security fixes are always applied to a few of the most recent release trains. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
52 lines
1.9 KiB
Markdown
52 lines
1.9 KiB
Markdown
# 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).
|
|
|
|
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](https://cve.mitre.org/), 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.
|