Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
Date: Sat, 27 Mar 2021 13:34:28 +0700
Message-ID: <4f715120-3cd3-9f14-a291-0eb6e83a940e@gmail.com> (raw)
In-Reply-To: <2c9f5725d96fe45aa5d1a6bbc522f9ed6161173c.1616796767.git.gitgitgadget@gmail.com>

On 27/03/21 05.12, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> 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>
> ---
>   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@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).
What about using reference word (`... it is recommended to send the
report to that mailing list`)?
> +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).
Oops, s/case-sensitiv/case-sensitive/
> +- 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
The header should be `Supported Versions and How Maintenance
Releases are Made`.
> +
> +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.
AFAIK, maint branch are based on latest feature release (say v2.24),
and any bugfixes there are cherry-picked to relevant older releases,
but does it mean resetting maint branch to that older release, and
then resetting back to before that? Or how tagged maintenance release
are made without resetting maint?
> +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.
> 

-- 
An old man doll... just what I always wanted! - Clara

  parent reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-27  0:00   ` Denton Liu
2021-03-29 13:37     ` Johannes Schindelin
2021-03-27  6:34   ` Bagas Sanjaya [this message]
2021-03-29 13:41     ` Johannes Schindelin
2021-03-26 22:12 ` [PATCH 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
2021-04-20 19:50     ` [PATCH v2 2/2] Document how we do embargoed releases - improving mail template Robin H. Johnson
2021-04-20 21:51       ` Junio C Hamano
2021-04-20 22:45         ` Robin H. Johnson
2021-04-20 23:34           ` Junio C Hamano
2021-04-20 23:31         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f715120-3cd3-9f14-a291-0eb6e83a940e@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git