SECURITY.md - git - Git at Google


            
            # 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.
	# 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.