"Julia Ramer via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Julia Ramer <gitprplr@xxxxxxxxx>
>
> With the recent turnover on the git-security list, questions came up how
> things are usually run. Rather than answering questions individually,
> extend Git's existing documentation about security vulnerabilities to
> describe the git-security mailing list, how things are run on that list,
> and what to expect throughout the process from the time a security bug
> is reported all the way to the time when a fix is released.
>
> Helped-by: Junio C Hamano <gitster@xxxxxxxxx>
> Helped-by: Taylor Blau <me@xxxxxxxxxxxx>
> Signed-off-by: Julia Ramer <gitprplr@xxxxxxxxx>
> ---
Thanks. Everything looks good, except for a few minor things.
> +Typical timeline
> +----------------
A much better section title; I like it.
> +- 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.
Mark-up glitch. This one is formatted as a <pre>...text...</pre>
under the above bullet point. Logically this is still a part of the
above bullet point (i.e. its second paragraph), so we'd need to
replace the blank line above this second paragraph with a line with
single '+' and nothing else on it, and de-dent this second paragraph.
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.
> +- While the Git community does its best to accommodate the specific timeline
> + requests of the various binary packagers, the nature of the issue may preclude
> + a prolonged release schedule. For fixes deemed urgent, it may be in the best
> + interest of the Git users community to shorten the disclosure and release
> + timeline, and packagers may need to adapt accordingly.
I briefly wondered if we need to say something about stakeholders
other than packagers (e.g. hosting sites), but it would probably be
obvious to readers that those who can deploy before releasing their
version of the sources have enough flexibility to cope better, so
the above would be fine.
> +- Subsequently, branches with the fixes are pushed to private repositories that
> + are owned by the Git project, with tightly controlled access.
... with the fixes are pushed to the git/cabal repository.
> +- The tags are created by the Git maintainer and pushed to the same
> + repositories.
Just like "review can take place in multiple places; contributors
are encouraged to start from ..." was made into a single bullet
point, "branches are privately published to git/cabal; tags are
added to the same repository." may flow well in the same single
bullet. I dunno.
> +- Less than a week before the release, a mail with the relevant information is
> + sent to <distros@xxxxxxxxxxxxxxx> (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.
... This includes a Git bundle of the tagged version(s), using
which the full source code for the releases can be created by
the recipients to prepare their release artifacts in a clone of
the public Git repository.
