"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. Thanks for writing this down. > +- Once the review has settled and everyone involved in the review agrees that > + the patches are ready, the Git maintainer determines a release date as well s/maintainer determines/& and others determine/ or "stakeholders discuss and agree on". You might want to mention that the schedule for disclosure and release tend to be constrained by so called patch Tuesday, which is the least flexible among various binary packagers. > +- Subsequently, branches with the fixes are pushed to private repositories that > + are owned by the Git project, with tightly controlled access. > + > +- The tags are created by the Git maintainer and pushed to the same > + repositories. Between this point in time when the tags are prepared and release materials are made available to packagers and ... > +- 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 Linux > + distributions. This includes a Git bundle of the tagged version(s), but no > + further specifics of the vulnerability. ... the time when we start to disclose to a bit wider audience, is when binary packagers are expected to prepare updates for their users. So ... > + > +- Public communication is then prepared in advance of the release date. This > + includes blog posts and mails to the Git and Git for Windows mailing lists. ... the following two bullet items are better written before the "Less than a week before...". > +- The Git for Windows maintainer prepares the corresponding release artifacts, > + based on the tags created that have been prepared by the Git maintainer. > + > +- Git for Windows release artifacts are made available under embargo to > + stakeholders via a mail to the `git-security` list. It also is probably a good idea to avoid singling out GfW too much. Folks who package Git for macOS, BSD, Debian etc. are all expected to work on the same timeline. > +- On the day of the release, at around 10am Pacific Time, the Git maintainer > + pushes the tag and the `master` branch to the public repository, then sends > + out an announcement mail. OK. Thanks for being explicit about 10am Pacific. > +- Once the tag is pushed, the Git for Windows maintainer publishes the > + corresponding tag and creates a GitHub Release with the associated release > + artifacts (Git for Windows installer, Portable Git, MinGit, etc). > + > +- Git for Windows release is then announced via a mail to the public Git and > + Git for Windows mailing lists as well as via a tweet. Ditto for various distro packagers. > +- A mail to <oss-security@xxxxxxxxxxxxxxxxxx> (see below for details) is sent as a > + follow-up to the <distros@xxxxxxxxxxxxxxx> one, describing the vulnerability in > + detail, often including a proof of concept of an exploit. > + > +Note: The Git project makes no guarantees about timelines, but aims to keep > +embargoes reasonably short in the interest of keeping Git's users safe. ;-)
