freshlybakedca.ke
Git fork
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>
authored by
Johannes Schindelin
and committed by
Junio C Hamano
2e99b1e3
48bf2fa8
+51
SECURITY.md
+51
SECURITY.md
···
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.