On Wed, Oct 19, 2022 at 11:53:18AM -0700, Junio C Hamano wrote: > "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. > > > > Signed-off-by: Julia Ramer <gitprplr@xxxxxxxxx> > > --- > > Thanks for an update that is excellently written. Yes, indeed. > - Would a reader, who has "stake" in the healty and secure Git, be > helped if we spell out that they are welcome to ask joining the > security list and how? It feels a bit too obvious after reading > "anybody may contact", which is both the right way to self > nominate for the membership and the natural thing I expect such a > reader would do, so we may not need to. My personal feeling is in agreement with yours, which is that it is probably obvious, so I don't think it's worth spelling out explicitly here. > + The packager whose release artifacts can be exchanged among > security list participants under embargo is not limited to Git > for Windows, even though we've only seen exchanges between > Victoria and Veronica this cycle for that particular > distribution. > > - The world is not limited to only Windows, mac and Linux. Windows > is not all that special. I agree, I think that mentioning Git for Windows in this document is not strictly necessary (e.g., if there were a new "Git for Foo" that came out tomorrow, I would not consider this document out-of-date), but I likewise wouldn't object to it. > - I wonder if we want to record the name that is used to refer to > the "private repository controlled by the project" on the > security mailing list somewhere in the documentation. If you are > a stakeholder, being on the mailing list *and* having access to > that repository are two things we need to make sure you have to > partcipate in the coordinated embargoed releases. This repository (git/cabal) is already well-documented on the mailing list, so I would have no problem including its name here, too. > Here is a patch that summarises some of the above on top of your > patch. I only tried to address the bullet items with "+" in front > in the above list. All looks good to me, thanks. Thanks, Taylor
