Re: [PATCH v3] embargoed releases: also describe the git-security list and the process

>
> > +- Code review can take place in a variety of different locations,
> > +  depending on context. These are: patches sent inline on the
> > +  git-security list, a private fork on GitHub associated with the
> > +  draft security advisory, or the git/cabal repository.
>
> Here, we name "the git/cabal repository" but the word never appears
> again in the document, we later refer to the same thing "private
> repositories that are owned by the Git project, with tightly
> controlled access", but to outsiders, it is not clear that they are
> the same thing.  Perhaps writing
>
>     ..., or the git/cabal repository (private repository owned by
>     the Git project with tightly controlled access).
>
> here, and replacing the later reference with just "the git/cabal
> repository", would be sufficient.

> > +  Contributors working on a fix should consider beginning by sending
> > +  patches to the git-security list (inline with the original thread),
> > +  since they are accessible to all subscribers, along with the original
> > +  reporter.
>
> Or we can make it a separate bullet point, which may make it simpler
> to read in the source form.

> > +- Once the review has settled and everyone involved in the review agrees that
> > +  the patches are ready, the Git maintainer, and others determine a release date
> > +  as well as the release trains that are serviced. The decision regarding which
>
> We typically know how involved the final changes would be (i.e. the
> minimum time it would take for us and involved others to prepare the
> release) way before all the t's are crossed and i's are dotted in
> the patches, so setting the release date may be done much earlier.

>
> > +- Less than a week before the release, a mail with the relevant information is
> > +  sent to <distros@vs.openwall.org> (see below), a list used to pre-announce
> > +  embargoed releases of open source projects to the stakeholders of all major
> > +  distributions of Linux as well as other OSes. This includes a Git bundle
> > +  of the tagged version(s), but no further specifics of the vulnerability.
>
> I am not sure how much value it adds to have ", but no further..."
> at the end.  Anybody who sees this e-mail has the Git bundle, which
> is relative to the last stable release, and can be used to create
> the full source of the releases by anybody who has access to the
> public Git repositories.  The source includes the release notes in
> the Documentation/RelNotes/ directory that describe everything to
> know about the vulnerabilities the releases address.