Hi Junio, On Fri, 2 Sep 2022, Junio C Hamano wrote: > "Julia Ramer via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt > > index 601aae88e9a..43400fd6025 100644 > > --- a/Documentation/howto/coordinate-embargoed-releases.txt > > +++ b/Documentation/howto/coordinate-embargoed-releases.txt > > @@ -1,6 +1,121 @@ > > Content-type: text/asciidoc > > -Abstract: When a critical vulnerability is discovered and fixed, we follow this > > - script to coordinate a public release. > > +Abstract: When a vulnerability is reported, we follow these guidelines to > > + assess the vulnerability, create and review a fix, and coordinate embargoed > > + security releases. > > + > > +The `git-security` mailing list > > +=============================== > > Dissapointingly, addition of these two new "=====" underlined > sections breaks the documentation build, which broke mi build > locally as well as GitHub CI [*1*] > > * https://github.com/git/git/runs/8162258928?check_suite_focus=true#step:4:658 > > Fix should hopefully be trivial, keep the original title line > > How we coordinate embargoed releases > ==================================== > > intact, and make these two new sections underlined with "-----", > demoting their subsections one level down accordingly. Here is a fixup, could you please apply this to the `jr/embargoed-releases-doc` branch? -- snip -- >From 32927af92e9ee7a0e22f90d8c162fca317ad6f6e Mon Sep 17 00:00:00 2001 From: Johannes Schindelin <johannes.schindelin@xxxxxx> Date: Sat, 3 Sep 2022 11:23:03 +0200 Subject: [PATCH] fixup! embargoed releases: also describe the git-security list and the process This fixes the build. Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> --- .../howto/coordinate-embargoed-releases.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt index 43400fd6025..b6799647536 100644 --- a/Documentation/howto/coordinate-embargoed-releases.txt +++ b/Documentation/howto/coordinate-embargoed-releases.txt @@ -4,7 +4,7 @@ Abstract: When a vulnerability is reported, we follow these guidelines to security releases. The `git-security` mailing list -=============================== +------------------------------- Responsible disclosures of vulnerabilities, analysis, proposed fixes as well as the orchestration of coordinated embargoed releases all happen on the @@ -17,7 +17,7 @@ otherwise be made aware of attack vectors that could be exploited. "Lifting the embargo" refers to publishing the version that fixes the vulnerabilities. Audience of the `git-security` mailing list -------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anybody may contact the `git-security` mailing list by sending an email to <git-security@xxxxxxxxxxxxxxxx>, though the archive is closed to the @@ -34,7 +34,7 @@ the timeline of the disclosure as well as aligning priorities and requirements. Communications --------------- +~~~~~~~~~~~~~~ If you are a stakeholder, it is a good idea to pay close attention to the discussions, as pertinent information may be buried in the middle of a lively @@ -46,7 +46,7 @@ mail threads are not usually structured specifically to communicate agreements, assessments or timelines. A bug's life: Typical timeline -============================== +------------------------------ - A bug is reported to the `git-security` mailing list. @@ -118,7 +118,7 @@ Note: The Git project makes no guarantees about timelines, but aims to keep embargoes reasonably short in the interest of keeping Git's users safe. How we coordinate embargoed releases -==================================== +------------------------------------ To protect Git users from critical vulnerabilities, we do not just release fixed versions like regular maintenance releases. Instead, we coordinate @@ -127,7 +127,7 @@ date. That way, users will have a chance to upgrade on that date, no matter what Operating System or distribution they run. Open a Security Advisory draft ------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The first step is to https://github.com/git/git/security/advisories/new[open an advisory]. Technically, this is not necessary. However, it is the most @@ -135,7 +135,7 @@ convenient way to obtain the CVE number and it give us a private repository associated with it that can be used to collaborate on a fix. Notifying the Linux distributions ---------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At most two weeks before release date, we need to send a notification to <distros@xxxxxxxxxxxxxxx>, preferably less than 7 days before the release date. @@ -166,7 +166,7 @@ created using a command like this: tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle Example mail to distros@xxxxxxxxxxxxxxx ---------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .... To: distros@xxxxxxxxxxxxxxx @@ -202,7 +202,7 @@ Thanks, .... Example mail to oss-security@xxxxxxxxxxxxxxxxxx ------------------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .... To: oss-security@xxxxxxxxxxxxxxxxxx -- 2.37.0.rc2.windows.1.7.g45a475aeb84 -- snap -- > But I care more about procedural gap because this should have been > something the submitter could have noticed at their end. I somehow > trusted that GitGitGadget would run preflight CI tests before > accepting /submit, but if not, perhaps we should? Sadly, our CI definitions are too flaky to enforce that. We had looked into that, but even though the Perforce situation seems to be a _lot_ better these days than it used to be, even the several weeks of broken FreeBSD builds simply preclude making them a prerequisite. In this instance, it is still my fault that the breakage was ignored before submitting: Julia had asked me whether she should wait for the PR build to finish, and I claimed that there is no need to wait because it is a documentation-only change (and I erroneously assumed that this document would not be built because it is not shown on https://git-scm.com/docs). Ciao, Dscho
