diff options
Diffstat (limited to 'howto/coordinate-embargoed-releases.html')
| -rw-r--r-- | howto/coordinate-embargoed-releases.html | 227 |
1 files changed, 196 insertions, 31 deletions
diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index de337a88e..9b449a171 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -5,7 +5,7 @@ <head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 10.2.0" />
-<title>How we coordinate embargoed releases</title>
+<title></title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@@ -734,10 +734,10 @@ asciidoc.install(); </head>
<body class="article">
<div id="header">
-<h1>How we coordinate embargoed releases</h1>
</div>
<div id="content">
-<div id="preamble">
+<div class="sect1">
+<h2 id="_how_we_coordinate_embargoed_releases">How we coordinate embargoed releases</h2>
<div class="sectionbody">
<div class="paragraph"><p>To protect Git users from critical vulnerabilities, we do not just release
fixed versions like regular maintenance releases. Instead, we coordinate
@@ -747,33 +747,201 @@ what Operating System or distribution they run.</p></div> </div>
</div>
<div class="sect1">
-<h2 id="_open_a_security_advisory_draft">Open a Security Advisory draft</h2>
+<h2 id="_the_code_git_security_code_mailing_list">The <code>git-security</code> mailing list</h2>
<div class="sectionbody">
-<div class="paragraph"><p>The first step is to <a href="https://github.com/git/git/security/advisories/new">open an
-advisory</a>. 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.</p></div>
+<div class="paragraph"><p>Responsible disclosures of vulnerabilities, analysis, proposed fixes as
+well as the orchestration of coordinated embargoed releases all happen on the
+<code>git-security</code> mailing list at <<a href="mailto:git-security@googlegroups.com">git-security@googlegroups.com</a>>.</p></div>
+<div class="paragraph"><p>In this context, the term "embargo" refers to the time period that information
+about a vulnerability is kept under wraps and only shared on a need-to-know
+basis. This is necessary to protect Git’s users from bad actors who would
+otherwise be made aware of attack vectors that could be exploited. "Lifting the
+embargo" refers to publishing the version that fixes the vulnerabilities.</p></div>
+<div class="sect2">
+<h3 id="_audience_of_the_code_git_security_code_mailing_list">Audience of the <code>git-security</code> mailing list</h3>
+<div class="paragraph"><p>Anybody may contact the <code>git-security</code> mailing list by sending an email
+to <<a href="mailto:git-security@googlegroups.com">git-security@googlegroups.com</a>>, though the archive is closed to the
+public and only accessible to subscribed members.</p></div>
+<div class="paragraph"><p>There are a few dozen subscribed members: core Git developers who are trusted
+with addressing vulnerabilities, and stakeholders (i.e. owners of products
+affected by security vulnerabilities in Git).</p></div>
+<div class="paragraph"><p>Most of the discussions revolve around assessing the severity of the reported
+issue (including the decision whether the report is security-relevant or can be
+redirected to the public mailing list), how to remediate the issue, determining
+the timeline of the disclosure as well as aligning priorities and
+requirements.</p></div>
</div>
+<div class="sect2">
+<h3 id="_communications">Communications</h3>
+<div class="paragraph"><p>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
+conversation that might not look relevant to your interests. For example, the
+tentative timeline might be agreed upon in the middle of discussing code
+comment formatting in one of the patches and whether or not to combine fixes
+for multiple, separate vulnerabilities into the same embargoed release. Most
+mail threads are not usually structured specifically to communicate
+agreements, assessments or timelines.</p></div>
</div>
-<div class="sect1">
-<h2 id="_release_date_of_the_embargoed_version">Release date of the embargoed version</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>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.</p></div>
-<div class="paragraph"><p>If the vulnerability affects the server side, or can benefit from scans on the
-server side (i.e. if <code>git fsck</code> can detect an attack), it is important to give
-all involved Git repository hosting sites enough time to scan all of those
-repositories.</p></div>
</div>
</div>
<div class="sect1">
-<h2 id="_notifying_the_linux_distributions">Notifying the Linux distributions</h2>
+<h2 id="_typical_timeline">Typical timeline</h2>
<div class="sectionbody">
+<div class="ulist"><ul>
+<li>
+<p>
+A potential vulnerability is reported to the <code>git-security</code> mailing list.
+</p>
+</li>
+<li>
+<p>
+The members of the git-security list start a discussion to give an initial
+ assessment of the severity of the reported potential vulnerability.
+ We aspire to do so within a few days.
+</p>
+</li>
+<li>
+<p>
+After discussion, if consensus is reached that it is not critical enough
+ to warrant any embargo, the reporter is redirected to the public Git mailing
+ list. This ends the reporter’s interaction with the <code>git-security</code> list.
+</p>
+</li>
+<li>
+<p>
+If it is deemed critical enough for an embargo, ideas are presented on how to
+ address the vulnerability.
+</p>
+</li>
+<li>
+<p>
+Usually around that time, the Git maintainer or their delegate(s) open a draft
+ security advisory in the <code>git/git</code> repository on GitHub (see below for more
+ details).
+</p>
+</li>
+<li>
+<p>
+Code review can take place in a variety of different locations,
+ depending on context. These are: patches sent inline on the git-security list,
+ a private fork on GitHub associated with the draft security advisory, or the
+ git/cabal repository.
+</p>
+</li>
+<li>
+<p>
+Contributors working on a fix should consider beginning by sending
+ patches to the git-security list (inline with the original thread), since they
+ are accessible to all subscribers, along with the original reporter.
+</p>
+</li>
+<li>
+<p>
+Once the review has settled and everyone involved in the review agrees that
+ the patches are nearing the finish line, the Git maintainer, and others
+ determine a release date as well as the release trains that are serviced. The
+ decision regarding which versions need a backported fix is based on input from
+ the reporter, the contributor who worked on the patches, and from
+ stakeholders. Operators of hosting sites who may want to analyze whether the
+ given issue is exploited via any of the repositories they host, and binary
+ packagers who want to make sure their product gets patched adequately against
+ the vulnerability, for example, may want to give their input at this stage.
+</p>
+</li>
+<li>
+<p>
+While the Git community does its best to accommodate the specific timeline
+ requests of the various binary packagers, the nature of the issue may preclude
+ a prolonged release schedule. For fixes deemed urgent, it may be in the best
+ interest of the Git users community to shorten the disclosure and release
+ timeline, and packagers may need to adapt accordingly.
+</p>
+</li>
+<li>
+<p>
+Subsequently, branches with the fixes are pushed to the git/cabal repository.
+</p>
+</li>
+<li>
+<p>
+The tags are created by the Git maintainer and pushed to the same repository.
+</p>
+</li>
+<li>
+<p>
+The Git for Windows, Git for macOS, BSD, Debian, etc. maintainers prepare the
+ corresponding release artifacts, based on the tags created that have been
+ prepared by the Git maintainer.
+</p>
+</li>
+<li>
+<p>
+The release artifacts prepared by various binary packagers can be
+ made available to stakeholders under embargo via a mail to the
+ <code>git-security</code> list.
+</p>
+</li>
+<li>
+<p>
+Less than a week before the release, a mail with the relevant information is
+ sent to <<a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a>> (see below), a list used to pre-announce
+ embargoed releases of open source projects to the stakeholders of all major
+ distributions of Linux as well as other OSes.
+</p>
+</li>
+<li>
+<p>
+Public communication is then prepared in advance of the release date. This
+ includes blog posts and mails to the Git and Git for Windows mailing lists.
+</p>
+</li>
+<li>
+<p>
+On the day of the release, at around 10am Pacific Time, the Git maintainer
+ pushes the tag and the <code>master</code> branch to the public repository, then sends
+ out an announcement mail.
+</p>
+</li>
+<li>
+<p>
+Once the tag is pushed, the Git for Windows maintainer publishes the
+ corresponding tag and creates a GitHub Release with the associated release
+ artifacts (Git for Windows installer, Portable Git, MinGit, etc).
+</p>
+</li>
+<li>
+<p>
+Git for Windows release is then announced via a mail to the public Git and
+ Git for Windows mailing lists as well as via a tweet.
+</p>
+</li>
+<li>
+<p>
+Ditto for distribution packagers for Linux and other platforms:
+ their releases are announced via their preferred channels.
+</p>
+</li>
+<li>
+<p>
+A mail to <<a href="mailto:oss-security@lists.openwall.org">oss-security@lists.openwall.org</a>> (see below for details) is sent
+ as a follow-up to the <<a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a>> one, describing the
+ vulnerability in detail, often including a proof of concept of an exploit.
+</p>
+</li>
+</ul></div>
+<div class="paragraph"><p>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.</p></div>
+<div class="sect2">
+<h3 id="_opening_a_security_advisory_draft">Opening a Security Advisory draft</h3>
+<div class="paragraph"><p>The first step is to <a href="https://github.com/git/git/security/advisories/new">open
+an advisory</a>. Technically, this is not necessary. However, it is the most
+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.</p></div>
+</div>
+<div class="sect2">
+<h3 id="_notifying_the_linux_distributions">Notifying the Linux distributions</h3>
<div class="paragraph"><p>At most two weeks before release date, we need to send a notification to
-<a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a>, preferably less than 7 days before the release date.
+<<a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a>>, 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
<a href="https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists">here</a>.</p></div>
@@ -798,10 +966,8 @@ created using a command like this:</p></div> tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle</code></pre>
</div></div>
</div>
-</div>
-<div class="sect1">
-<h2 id="_example_mail_to_a_href_mailto_distros_vs_openwall_org_distros_vs_openwall_org_a">Example mail to <a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a></h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_example_mail_to_a_href_mailto_distros_vs_openwall_org_distros_vs_openwall_org_a">Example mail to <a href="mailto:distros@vs.openwall.org">distros@vs.openwall.org</a></h3>
<div class="literalblock">
<div class="content">
<pre><code>To: distros@vs.openwall.org
@@ -835,10 +1001,8 @@ Thanks, <name></code></pre>
</div></div>
</div>
-</div>
-<div class="sect1">
-<h2 id="_example_mail_to_a_href_mailto_oss_security_lists_openwall_com_oss_security_lists_openwall_com_a">Example mail to <a href="mailto:oss-security@lists.openwall.com">oss-security@lists.openwall.com</a></h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_example_mail_to_a_href_mailto_oss_security_lists_openwall_com_oss_security_lists_openwall_com_a">Example mail to <a href="mailto:oss-security@lists.openwall.com">oss-security@lists.openwall.com</a></h3>
<div class="literalblock">
<div class="content">
<pre><code>To: oss-security@lists.openwall.com
@@ -869,11 +1033,12 @@ Thanks, </div>
</div>
</div>
+</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
- 2022-10-28 11:54:30 PDT
+ 2022-11-04 21:50:28 PDT
</div>
</div>
</body>
|