From: Johannes Schindelin <johannes.schindelin@xxxxxx> 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@xxxxxx> --- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000000..282790164e78 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,51 @@ +# Security Policy + +## Reporting a vulnerability + +Please send a detailed mail to git-security@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxx (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-sensitiv 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. -- gitgitgadget
