SECURITY: describe how to report vulnerabilities

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>
This commit is contained in:
Johannes Schindelin 2021-03-26 22:12:45 +00:00 committed by Junio C Hamano
parent 48bf2fa8ba
commit 2e99b1e383
1 changed files with 51 additions and 0 deletions

51
SECURITY.md Normal file
View File

@ -0,0 +1,51 @@
# 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.