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

From

Johannes Schindelin <johannes.schindelin@gmx.de>

Date

Sep 3, 2022, 09:29 UTC

Message-ID

<161877q5-843n-q73q-6q3q-sq2664s6q340@tzk.qr>

In-Reply-To

<xmqqwnal7gc9.fsf@gitster.g>

Hi Junio,

On Fri, 2 Sep 2022, Junio C Hamano wrote:

> "Julia Ramer via GitGitGadget" <gitgitgadget@gmail.com> 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.

-- snip --
From 32927af92e9ee7a0e22f90d8c162fca317ad6f6e Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
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@gmx.de>
---
 .../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@googlegroups.com>, 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@vs.openwall.org>, 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@vs.openwall.org
----------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 ....
 To: distros@vs.openwall.org
@@ -202,7 +202,7 @@ Thanks,
 ....

 Example mail to oss-security@lists.openwall.com
------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 ....
 To: oss-security@lists.openwall.com
--
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