git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
Date: Mon, 29 Mar 2021 15:41:42 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2103291537290.53@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <4f715120-3cd3-9f14-a291-0eb6e83a940e@gmail.com>

Hi Bagas,

On Sat, 27 Mar 2021, Bagas Sanjaya wrote:

> 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`)?

I would really like to repeat the email address here, to make really
certain that the reader uses the correct one.

> > +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/

Yes, thanks, it will be fixed in v2.

> > +- 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`.

Not really. The maintenance is described in
Documentation/howto/maintain-git.txt. It is not the purpose of
`SECURITY.md` to document that, it just so happens that we hint a bit at
it while talking about which branches get security updates.

> > +
> > +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?

There are `maint-<maintenance-track>` branches, e.g. `maint-2.30`,
`maint-2.29`, etc.

But it really is not even interesting in the context of security updates
how those maintenance branches are called, it is only interesting which
versions will receive updates (and the updates come in the form of a
newly-tagged version, not in the form of an updated `maint-<track>`
branch; The latter just _happens_ to also happen, for maintenance
reasons).

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

Thank you for your review!
Johannes

  reply	other threads:[~2021-03-29 13:42 UTC|newest]

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
2021-03-29 13:41     ` Johannes Schindelin [this message]
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=nycvar.QRO.7.76.6.2103291537290.53@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).