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>
Johannes Schindelin committed
Mar 26, 2021 at 22:12 UTC
2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0
1 file changed
+51
SECURITY.md
new
+51
@@ -0,0 +1,51 @@
1
+# Security Policy
2
+
3
+## Reporting a vulnerability
4
+
5
+Please send a detailed mail to git-security@googlegroups.com to
6
+report vulnerabilities in Git.
7
+
8
+Even when unsure whether the bug in question is an exploitable
9
+vulnerability, it is recommended to send the report to
10
+git-security@googlegroups.com (and obviously not to discuss the
11
+issue anywhere else).
12
+
13
+Vulnerabilities are expected to be discussed _only_ on that
14
+list, and not in public, until the official announcement on the
15
+Git mailing list on the release date.
16
+
17
+Examples for details to include:
18
+
19
+- Ideally a short description (or a script) to demonstrate an
20
+ exploit.
21
+- The affected platforms and scenarios (the vulnerability might
22
+ only affect setups with case-sensitive file systems, for
23
+ example).
24
+- The name and affiliation of the security researchers who are
25
+ involved in the discovery, if any.
26
+- Whether the vulnerability has already been disclosed.
27
+- How long an embargo would be required to be safe.
28
+
29
+## Supported Versions
30
+
31
+There are no official "Long Term Support" versions in Git.
32
+Instead, the maintenance track (i.e. the versions based on the
33
+most recently published feature release, also known as ".0"
34
+version) sees occasional updates with bug fixes.
35
+
36
+Fixes to vulnerabilities are made for the maintenance track for
37
+the latest feature release and merged up to the in-development
38
+branches. The Git project makes no formal guarantee for any
39
+older maintenance tracks to receive updates. In practice,
40
+though, critical vulnerability fixes are applied not only to the
41
+most recent track, but to at least a couple more maintenance
42
+tracks.
43
+
44
+This is typically done by making the fix on the oldest and still
45
+relevant maintenance track, and merging it upwards to newer and
46
+newer maintenance tracks.
47
+
48
+For example, v2.24.1 was released to address a couple of
49
+[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,
50
+v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
51
+v2.22.2 and v2.23.1 were released.