Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities

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