projects / thirdparty / git.git / blame
| Commit | Line | Data |
|---|---|---|
| 2e99b1e3 JS |
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. |