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

Taylor Blau [off-list ref] writes:

quoted

+A bug's life: Typical timeline
+------------------------------
+
+- A bug is reported to the `git-security` mailing list.
+
+- Within a couple of days, someone from the core Git team responds with an
+  initial assessment of the bug’s severity.

A few nitpicks on this and the above bullet point:

  - The git-security list isn't for bug reports, though there can be a
    security component to something that looks like a bug report.

    Perhaps to be clearer we should swap "bug" for "potential
    vulnerability"?

Good point and good idea.

  - On "within a couple of days", I think that this is aspirationally
    true, though not always the case. Perhaps, "as soon as possible"
    instead? That's vague enough that I wouldn't worry about somebody
    reading this document >2 days after submitting a potential
    vulnerability wondering why nobody has gotten back to them ;-).

The purpose of giving a "Typical" timeline is primarily to guide
readers what to expect once they raise an issue, and to bind us with
at least "aspirational" deadline (which is not a bad thing), isn't
it?  Saying "As soon as possible" there is the same as not saying
anything at all, even though in reality it sometimes may be "when
somebody feels like it is worth looking into" ;-)

Depending on the nature of vulnerability, the time it takes to reach
a satisfactory conclusion may range from a few days to a few weeks,
so we may not be able to give even a "Typical" timeline, but I do
not think it is unreasonable to hold us to a few days turnaround
time at least for an initial reaction.

That's a roundabout way to say "I think the original text is good".

  - Finally, consider replacing "core Git team" with "member of the
    git-security list".

I am torn.

The folks who are deep into core git development may have better
ability to assess the severity of a particular bug and the
complexity of possible solutions than others, but platform
stakeholders know how Git is used within their system and how old
the target track they wish to be updated better than us.  So in that
sense, limiting assessment to core developers may not be ideal.

But on the other hand, the initial report to the list are seen only
by the security list participants and nobody else, so by definition,
any response would come from them ;-)

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.

Yes, it is convenient for simple things, but not necessarily the
best option when we need to roll it upwards to produce releases for
multiple maintenance tracks.

The rest of your comments and suggestions address all good points.

Thanks.