On Wed, Oct 19, 2022 at 05:15:03PM -0400, Taylor Blau wrote:
> > +- Depending on the preferences of the involved contributors and reviewers, code
> > + review then happens either on the `git-security` mailing list or in a private
> > + fork associated with the draft security advisory.
>
> There's a third option, too, which is using the private git/cabal
> repository. Anybody who is a member of the @git/security team on GitHub
> has access to this repository. And it is often a convenient option for
> coordinating releases that contain fixes for more than one
> vulnerability.
>
> There aren't any hard and fast rules for which approach should be used
> in a given circumstance, but I think it's worth mentioning it as another
> option.
>
> For my own $.02, I often find it useful to *start* by sending patches to
> the git-security list inline with the thread so that the original
> reporter (who is more often than not *not* a member of the @git/security
> team) can participate in review (or at least look at the patches).
>
> The private forks tied to a security advisory are often convenient
> (assuming that the reporter has a GitHub account) since they provide a
> shared workspace. But I think we usually avoid them when working on
> preparing a release for more than one vulnerability.
Here is some proposed language that I think would encompass everything
both you and I wrote here:
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.
Contributors working on a fix should consider beginning by sending
patches on the list (inline with the original thread), since they
are accessible to all subscribers, along with the original reporter.
A typical review cycle often takes place here.
Then, depending on if there are one or multiple security advisories,
contributors should move their patches to either the private fork
associated with the security advisory on GitHub, or the git/cabal
repository. It is in either one of these locations that release
branches (based on `maint`) are prepared.
When there is a single security vulnerability, using the fork
associated with the security advisory is convenient as it
centralizes discussion, review, and release mechanics at a single
location. When there are multiple such vulnerabilities, no single
temporary fork is appropriate, so it is instead encouraged to use
the private git/cabal repository (visibility of which is granted to
members of the @git/security team on GitHub).
Thanks,
Taylor
