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

From: Taylor Blau <me@ttaylorr.com>
Date: Oct 20, 2022, 17:06 UTC
Message-ID: <Y1GAK+y8a2lc9Kq6@nand.local>
In-Reply-To: <Y1Bo18aU7YKKX9yh@nand.local>

On Wed, Oct 19, 2022 at 05:15:03PM -0400, Taylor Blau wrote:

Show 23 quoted lines

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