1 Content-type: text/asciidoc
2 Abstract: When a critical vulnerability is discovered and fixed, we follow this
3 script to coordinate a public release.
5 How we coordinate embargoed releases
6 ====================================
8 To protect Git users from critical vulnerabilities, we do not just release
9 fixed versions like regular maintenance releases. Instead, we coordinate
10 releases with packagers, keeping the fixes under an embargo until the release
11 date. That way, users will have a chance to upgrade on that date, no matter
12 what Operating System or distribution they run.
14 Open a Security Advisory draft
15 ------------------------------
17 The first step is to https://github.com/git/git/security/advisories/new[open an
18 advisory]. Technically, it is not necessary, but it is convenient and saves a
19 bit of hassle. This advisory can also be used to obtain the CVE number and it
20 will give us a private fork associated with it that can be used to collaborate
23 Release date of the embargoed version
24 -------------------------------------
26 If the vulnerability affects Windows users, we want to have our friends over at
27 Visual Studio on board. This means we need to target a "Patch Tuesday" (i.e. a
28 second Tuesday of the month), at the minimum three weeks from heads-up to
31 If the vulnerability affects the server side, or can benefit from scans on the
32 server side (i.e. if `git fsck` can detect an attack), it is important to give
33 all involved Git repository hosting sites enough time to scan all of those
36 Notifying the Linux distributions
37 ---------------------------------
39 At most two weeks before release date, we need to send a notification to
40 distros@vs.openwall.org, preferably less than 7 days before the release date.
41 This will reach most (all?) Linux distributions. See an example below, and the
42 guidelines for this mailing list at
43 https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].
45 Once the version has been published, we send a note about that to oss-security.
46 As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the
48 https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are
51 The mail to oss-security should also describe the exploit, and give credit to
52 the reporter(s): security researchers still receive too little respect for the
53 invaluable service they provide, and public credit goes a long way to keep them
54 paid by their respective organizations.
56 Technically, describing any exploit can be delayed up to 7 days, but we usually
57 refrain from doing that, including it right away.
59 As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
60 will drop `.bundle` attachments) in the mail to distros@ so that the involved
61 parties can take care of integrating/backporting them. This bundle is typically
62 created using a command like this:
64 git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
65 tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
67 Example mail to distros@vs.openwall.org
68 ---------------------------------------
71 To: distros@vs.openwall.org
72 Cc: git-security@googlegroups.com, <other people involved in the report/fix>
73 Subject: [vs] Upcoming Git security fix release
77 The Git project will release new versions on <date> at 10am Pacific Time or
78 soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
79 it being dropped) which you can fetch into a clone of
80 https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
81 containing the tags for versions <versions>.
83 You can verify with `git tag -v <tag>` that the versions were signed by
84 the Git maintainer, using the same GPG key as e.g. v2.24.0.
86 Please use these tags to prepare `git` packages for your various
87 distributions, using the appropriate tagged versions. The added test cases
88 help verify the correctness.
90 The addressed issues are:
92 <list of CVEs with a short description, typically copy/pasted from Git's
93 release notes, usually demo exploit(s), too>
95 Credit for finding the vulnerability goes to <reporter>, credit for fixing
96 it goes to <developer>.
103 Example mail to oss-security@lists.openwall.com
104 -----------------------------------------------
107 To: oss-security@lists.openwall.com
108 Cc: git-security@googlegroups.com, <other people involved in the report/fix>
109 Subject: git: <copy from security advisory>
113 The Git project released new versions on <date>, addressing <CVE>.
115 All supported platforms are affected in one way or another, and all Git
116 versions all the way back to <version> are affected. The fixed versions are:
119 Link to the announcement: <link to lore.kernel.org/git>
121 We highly recommend to upgrade.
123 The addressed issues are:
124 * <list of CVEs and their explanations, along with demo exploits>
126 Credit for finding the vulnerability goes to <reporter>, credit for fixing
127 it goes to <developer>.