Taylor Blau <me@xxxxxxxxxxxx> writes: >> +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.
