archive mirror
 help / color / mirror / Atom feed
From: "Johannes Schindelin via GitGitGadget" <>
Cc: Johannes Schindelin <>,
	Johannes Schindelin <>
Subject: [PATCH 2/2] Document how we do embargoed releases
Date: Fri, 26 Mar 2021 22:12:46 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Johannes Schindelin <>

Whenever we fix critical vulnerabilities, we follow some sort of
protocol (e.g. setting a coordinated release date, keeping the fix under
embargo until that time, coordinating with packagers and/or hosting
sites, etc).

Similar in spirit to `Documentation/howto/maintain-git.txt`, let's
formalize the details in a document.

Signed-off-by: Johannes Schindelin <>
 Documentation/Makefile                        |   1 +
 .../howto/coordinate-embargoed-releases.txt   | 131 ++++++++++++++++++
 2 files changed, 132 insertions(+)
 create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 81d1bf7a049b..874a01d7a86e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -76,6 +76,7 @@ SP_ARTICLES += howto/rebuild-from-update-hook
 SP_ARTICLES += howto/rebase-from-internal-branch
 SP_ARTICLES += howto/keep-canonical-history-correct
 SP_ARTICLES += howto/maintain-git
+SP_ARTICLES += howto/coordinate-embargoed-releases
 API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt
new file mode 100644
index 000000000000..601aae88e9a3
--- /dev/null
+++ b/Documentation/howto/coordinate-embargoed-releases.txt
@@ -0,0 +1,131 @@
+Content-type: text/asciidoc
+Abstract: When a critical vulnerability is discovered and fixed, we follow this
+ script to coordinate a public release.
+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
+releases with packagers, keeping the fixes under an embargo until the release
+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[open an
+advisory]. Technically, it is not necessary, but it is convenient and saves a
+bit of hassle. This advisory can also be used to obtain the CVE number and it
+will give us a private fork associated with it that can be used to collaborate
+on a fix.
+Release date of the embargoed version
+If the vulnerability affects Windows users, we want to have our friends over at
+Visual Studio on board. This means we need to target a "Patch Tuesday" (i.e. a
+second Tuesday of the month), at the minimum three weeks from heads-up to
+coordinated release.
+If the vulnerability affects the server side, or can benefit from scans on the
+server side (i.e. if `git fsck` can detect an attack), it is important to give
+all involved Git repository hosting sites enough time to scan all of those
+Notifying the Linux distributions
+At most two weeks before release date, we need to send a notification to, preferably less than 7 days before the release date.
+This will reach most (all?) Linux distributions. See an example below, and the
+guidelines for this mailing list at
+Once the version has been published, we send a note about that to oss-security.
+As an example, see[the
+v2.24.1 mail];
+[Here] are
+their guidelines.
+The mail to oss-security should also describe the exploit, and give credit to
+the reporter(s): security researchers still receive too little respect for the
+invaluable service they provide, and public credit goes a long way to keep them
+paid by their respective organizations.
+Technically, describing any exploit can be delayed up to 7 days, but we usually
+refrain from doing that, including it right away.
+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
+will drop `.bundle` attachments) in the mail to distros@ so that the involved
+parties can take care of integrating/backporting them. This bundle is typically
+created using a command like this:
+	git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
+	tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
+Example mail to
+Cc:, <other people involved in the report/fix>
+Subject: [vs] Upcoming Git security fix release
+The Git project will release new versions on <date> at 10am Pacific Time or
+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
+it being dropped) which you can fetch into a clone of
+ via `git fetch --tags /path/to/cve-xxx.bundle`,
+containing the tags for versions <versions>.
+You can verify with `git tag -v <tag>` that the versions were signed by
+the Git maintainer, using the same GPG key as e.g. v2.24.0.
+Please use these tags to prepare `git` packages for your various
+distributions, using the appropriate tagged versions. The added test cases
+help verify the correctness.
+The addressed issues are:
+<list of CVEs with a short description, typically copy/pasted from Git's
+release notes, usually demo exploit(s), too>
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+Example mail to
+Cc:, <other people involved in the report/fix>
+Subject: git: <copy from security advisory>
+The Git project released new versions on <date>, addressing <CVE>.
+All supported platforms are affected in one way or another, and all Git
+versions all the way back to <version> are affected. The fixed versions are:
+Link to the announcement: <link to>
+We highly recommend to upgrade.
+The addressed issues are:
+* <list of CVEs and their explanations, along with demo exploits>
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.

  parent reply	other threads:[~2021-03-26 22:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-27  0:00   ` Denton Liu
2021-03-29 13:37     ` Johannes Schindelin
2021-03-27  6:34   ` Bagas Sanjaya
2021-03-29 13:41     ` Johannes Schindelin
2021-03-26 22:12 ` Johannes Schindelin via GitGitGadget [this message]
2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
2021-04-20 19:50     ` [PATCH v2 2/2] Document how we do embargoed releases - improving mail template Robin H. Johnson
2021-04-20 21:51       ` Junio C Hamano
2021-04-20 22:45         ` Robin H. Johnson
2021-04-20 23:34           ` Junio C Hamano
2021-04-20 23:31         ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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.
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 NNTP newsgroup(s).