From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Julia Ramer via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Julia Ramer <gitprplr@gmail.com>
Subject: Re: [PATCH] embargoed releases: also describe the git-security list and the process
Date: Sat, 3 Sep 2022 11:29:35 +0200 (CEST) [thread overview]
Message-ID: <161877q5-843n-q73q-6q3q-sq2664s6q340@tzk.qr> (raw)
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.
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@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
next prev parent reply other threads:[~2022-09-03 9:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 22:39 [PATCH] embargoed releases: also describe the git-security list and the process Julia Ramer via GitGitGadget
2022-09-02 17:24 ` Junio C Hamano
2022-09-27 22:56 ` Julia Ramer
2022-09-28 17:12 ` Junio C Hamano
2022-10-18 20:43 ` Julia Ramer
2022-10-19 15:47 ` Junio C Hamano
2022-09-02 18:59 ` Junio C Hamano
2022-09-03 9:29 ` Johannes Schindelin [this message]
2022-09-05 20:28 ` Junio C Hamano
2022-10-19 1:16 ` [PATCH v2] " Julia Ramer via GitGitGadget
2022-10-19 18:53 ` Junio C Hamano
2022-10-19 21:22 ` Taylor Blau
2022-10-19 22:01 ` Junio C Hamano
2022-10-19 21:15 ` Taylor Blau
2022-10-19 21:50 ` Junio C Hamano
2022-10-20 17:06 ` Taylor Blau
2022-10-21 7:41 ` [PATCH v3] " Julia Ramer via GitGitGadget
2022-10-21 16:42 ` Junio C Hamano
2022-10-24 20:18 ` Julia Ramer
2022-10-24 22:56 ` Junio C Hamano
2022-10-22 0:11 ` Taylor Blau
2022-10-24 20:19 ` Julia Ramer
2022-10-24 22:07 ` [PATCH v4] " Julia Ramer via GitGitGadget
2022-10-24 23:08 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=161877q5-843n-q73q-6q3q-sq2664s6q340@tzk.qr \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitprplr@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).