| Message ID | pull.1345.git.1662071998812.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | embargoed releases: also describe the git-security list and the process | expand |
"Julia Ramer via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Julia Ramer <gitprplr@gmail.com> > > With the recent turnover on the git-security list, questions came up how > things are usually run. Rather than answering questions individually, > extend Git's existing documentation about security vulnerabilities to > describe the git-security mailing list, how things are run on that list, > and what to expect throughout the process from the time a security bug > is reported all the way to the time when a fix is released. Thanks for writing this down. > +- Once the review has settled and everyone involved in the review agrees that > + the patches are ready, the Git maintainer determines a release date as well s/maintainer determines/& and others determine/ or "stakeholders discuss and agree on". You might want to mention that the schedule for disclosure and release tend to be constrained by so called patch Tuesday, which is the least flexible among various binary packagers. > +- Subsequently, branches with the fixes are pushed to private repositories that > + are owned by the Git project, with tightly controlled access. > + > +- The tags are created by the Git maintainer and pushed to the same > + repositories. Between this point in time when the tags are prepared and release materials are made available to packagers and ... > +- Less than a week before the release, a mail with the relevant information is > + sent to <distros@vs.openwall.org> (see below), a list used to pre-announce embargoed > + releases of open source projects to the stakeholders of all major Linux > + distributions. This includes a Git bundle of the tagged version(s), but no > + further specifics of the vulnerability. ... the time when we start to disclose to a bit wider audience, is when binary packagers are expected to prepare updates for their users. So ... > + > +- 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. ... the following two bullet items are better written before the "Less than a week before...". > +- The Git for Windows maintainer prepares the corresponding release artifacts, > + based on the tags created that have been prepared by the Git maintainer. > + > +- Git for Windows release artifacts are made available under embargo to > + stakeholders via a mail to the `git-security` list. It also is probably a good idea to avoid singling out GfW too much. Folks who package Git for macOS, BSD, Debian etc. are all expected to work on the same timeline. > +- On the day of the release, at around 10am Pacific Time, the Git maintainer > + pushes the tag and the `master` branch to the public repository, then sends > + out an announcement mail. OK. Thanks for being explicit about 10am Pacific. > +- 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). > + > +- 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. Ditto for various distro packagers. > +- A mail to <oss-security@lists.openwall.org> (see below for details) is sent as a > + follow-up to the <distros@vs.openwall.org> one, describing the vulnerability in > + detail, often including a proof of concept of an exploit. > + > +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. ;-)
"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. 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? Thanks.
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
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > 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? Thanks but no thanks. The contents change is needed so I will wait for an updated patch from the author.
Taking these responses one by one: All of Junio's edits and call-outs are reasonable and I'll incorporate them into the next version. Julia (she/her) On Fri, Sep 2, 2022 at 10:24 AM Junio C Hamano <gitster@pobox.com> wrote: > > "Julia Ramer via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > From: Julia Ramer <gitprplr@gmail.com> > > > > With the recent turnover on the git-security list, questions came up how > > things are usually run. Rather than answering questions individually, > > extend Git's existing documentation about security vulnerabilities to > > describe the git-security mailing list, how things are run on that list, > > and what to expect throughout the process from the time a security bug > > is reported all the way to the time when a fix is released. > > Thanks for writing this down. > > > +- Once the review has settled and everyone involved in the review agrees that > > + the patches are ready, the Git maintainer determines a release date as well > > s/maintainer determines/& and others determine/ or "stakeholders > discuss and agree on". You might want to mention that the schedule > for disclosure and release tend to be constrained by so called patch > Tuesday, which is the least flexible among various binary packagers. > > > +- Subsequently, branches with the fixes are pushed to private repositories that > > + are owned by the Git project, with tightly controlled access. > > + > > +- The tags are created by the Git maintainer and pushed to the same > > + repositories. > > Between this point in time when the tags are prepared and release > materials are made available to packagers and ... > > > +- Less than a week before the release, a mail with the relevant information is > > + sent to <distros@vs.openwall.org> (see below), a list used to pre-announce embargoed > > + releases of open source projects to the stakeholders of all major Linux > > + distributions. This includes a Git bundle of the tagged version(s), but no > > + further specifics of the vulnerability. > > ... the time when we start to disclose to a bit wider audience, is > when binary packagers are expected to prepare updates for their > users. So ... > > > + > > +- 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. > > ... the following two bullet items are better written before the > "Less than a week before...". > > > +- The Git for Windows maintainer prepares the corresponding release artifacts, > > + based on the tags created that have been prepared by the Git maintainer. > > + > > +- Git for Windows release artifacts are made available under embargo to > > + stakeholders via a mail to the `git-security` list. > > It also is probably a good idea to avoid singling out GfW too much. > Folks who package Git for macOS, BSD, Debian etc. are all expected > to work on the same timeline. > > > +- On the day of the release, at around 10am Pacific Time, the Git maintainer > > + pushes the tag and the `master` branch to the public repository, then sends > > + out an announcement mail. > > OK. Thanks for being explicit about 10am Pacific. > > > +- 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). > > + > > +- 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. > > Ditto for various distro packagers. > > > +- A mail to <oss-security@lists.openwall.org> (see below for details) is sent as a > > + follow-up to the <distros@vs.openwall.org> one, describing the vulnerability in > > + detail, often including a proof of concept of an exploit. > > + > > +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. > > ;-) > > -- > You received this message because you are subscribed to the Google Groups "Git Security" group. > To unsubscribe from this group and stop receiving emails from it, send an email to git-security+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/git-security/xmqqa67h8zac.fsf%40gitster.g.
[moving git-security@ to BCC; those who have been following the thread, please switch to the main list] > All of Junio's edits and call-outs are reasonable and I'll incorporate > them into the next version. Thanks. >> > +- Once the review has settled and everyone involved in the review agrees that >> > + the patches are ready, the Git maintainer determines a release date as well >> >> s/maintainer determines/& and others determine/ or "stakeholders >> discuss and agree on". You might want to mention that the schedule >> for disclosure and release tend to be constrained by so called patch >> Tuesday, which is the least flexible among various binary packagers. By the way, this "we account for patch Tuesday" is not "the only 800 pound gorilla in the room inherently has rights to dictate their terms". It is merely that "other packagers are being nice and extra accomodating", and when another even less flexible packager requests a prolonged schedule, we might accomodate their needs, depending on the nature of the issue. On the other hand, the git users community may not be able to wait for the next month to apply an unusually urgent fix, and a binary packager with a coarse release granularity may have to be creative on such an occasion. In this hypothetical timeline: A---B-B-B-B-B-B-B-B---C D0----E0 D1----E1 (next month) where A: problem reported B: solution proposed, discussed, and finalized C: public coordinated disclosure and release date Dn: cut-off date for "monthly security updates" for a packager En: date "monthly security updates" is issued by a packager the wider Git user community may not be able to afford to wait until date E1 of the next month by delaying C, even if date D0 for this month's "security updates" for a particular packager comes before the solution gets finalized. If the coordinated release C falls after the deadline D0 for the upcoming "monthly security updates" (not singling out Microsoft by mentioning "patch Tuesdays" anymore, as this applies generally to anybody whose release granularity is more coarse than other distros find comfortahble for security fixes) for a packager, but if an early round of proposed fix is seen, they can independently make their own judgement to include the non-final fix in their binary release at their cut-off date D0, while withholding the source at least to the agreed upon coordinate disclosure date C, for example. They may later want to update to the final fix by date D1 to be included in their next "monthly security updates" on date E1, which would be an extra work, but that is the cost of running a coarse release schedule. I do not know how to concisely phrase the above to fit in the framework of your document, but some of the above issues were brought up elsewhere, so I thought I'd better share it here. Thanks.
[adding Veronica and Bri to TO:] On Wed, Sep 28, 2022 at 10:12 AM Junio C Hamano <gitster@pobox.com> wrote: > > >> > +- Once the review has settled and everyone involved in the review agrees that > >> > + the patches are ready, the Git maintainer determines a release date as well > >> > >> s/maintainer determines/& and others determine/ or "stakeholders > >> discuss and agree on". You might want to mention that the schedule > >> for disclosure and release tend to be constrained by so called patch > >> Tuesday, which is the least flexible among various binary packagers. > > By the way, this "we account for patch Tuesday" is not "the only 800 > pound gorilla in the room inherently has rights to dictate their > terms". It is merely that "other packagers are being nice and extra > accomodating", and when another even less flexible packager requests > a prolonged schedule, we might accomodate their needs, depending on > the nature of the issue. > > On the other hand, the git users community may not be able to wait > for the next month to apply an unusually urgent fix, and a binary > packager with a coarse release granularity may have to be creative > on such an occasion. > > In this hypothetical timeline: > > A---B-B-B-B-B-B-B-B---C > > D0----E0 D1----E1 (next month) > > where > > A: problem reported > B: solution proposed, discussed, and finalized > C: public coordinated disclosure and release date > > Dn: cut-off date for "monthly security updates" for a packager > En: date "monthly security updates" is issued by a packager > > the wider Git user community may not be able to afford to wait until > date E1 of the next month by delaying C, even if date D0 for this > month's "security updates" for a particular packager comes before > the solution gets finalized. > > If the coordinated release C falls after the deadline D0 for the > upcoming "monthly security updates" (not singling out Microsoft by > mentioning "patch Tuesdays" anymore, as this applies generally to > anybody whose release granularity is more coarse than other distros > find comfortahble for security fixes) for a packager, but if an > early round of proposed fix is seen, they can independently make > their own judgement to include the non-final fix in their binary > release at their cut-off date D0, while withholding the source at > least to the agreed upon coordinate disclosure date C, for example. > If I am understanding this particular scenario, I believe you intended: s/coordinated release C/final B/ > They may later want to update to the final fix by date D1 to be > included in their next "monthly security updates" on date E1, which > would be an extra work, but that is the cost of running a coarse > release schedule. > > I do not know how to concisely phrase the above to fit in the > framework of your document, but some of the above issues were > brought up elsewhere, so I thought I'd better share it here. > I can take a stab at concisely phrasing this to fit within this framework, first paragraph for context, second is the addition: Once the review has settled and everyone involved in the review agrees that the patches are ready, 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 (e.g. operators of hosting sites who may want to analyze whether the given bug is exploited via any of the repositories they host). 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.
Julia Ramer <prplr@github.com> writes: >> In this hypothetical timeline: >> >> A---B-B-B-B-B-B-B-B---C >> >> D0----E0 D1----E1 (next month) >> ... >> If the coordinated release C falls after the deadline D0 for the >> upcoming "monthly security updates" (not singling out Microsoft by > ... > If I am understanding this particular scenario, I believe you intended: > > s/coordinated release C/final B/ Thanks for sharp eyes. You're correct. As long as the final B comes before the deadline of a packager, then they should be able to work within their own constraint. If the final B comes after their deadline, and they still want to include the fix in E0, then the package needs to be "creative". > I can take a stab at concisely phrasing this to fit within this framework, > first paragraph for context, second is the addition: > > Once the review has settled and everyone involved in the review agrees that > the patches are ready, 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 (e.g. operators > of hosting sites who may want to analyze whether the given bug is exploited > via any of the repositories they host). > > 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. Exellent. Thanks.
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 +=============================== + +Responsible disclosures of vulnerabilities, analysis, proposed fixes as +well as the orchestration of coordinated embargoed releases all happen on the +`git-security` mailing list at <git-security@googlegroups.com>. + +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. + +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 +public and only accessible to subscribed members. + +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). + +Most of the discussions revolve around assessing the severity of the reported +bugs (including the decision whether the report is security-relevant or can be +redirected to the public mailing list), how to remediate the bug, determining +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 +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. + +A bug's life: Typical timeline +============================== + +- A bug is reported to the `git-security` mailing list. + +- Within a couple of days, someone from the core Git team responds with an + initial assessment of the bug’s severity. + +- Other core developers - including the Git maintainer - chime in. + +- After discussion, if consensus is reached that the bug 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 `git-security` list. + +- If the bug is critical enough for an embargo, ideas are presented on how to + address the vulnerability. + +- Usually around that time, the Git maintainer or their delegate(s) open a draft + security advisory in the `git/git` repository on GitHub (see below for more + details). + +- Depending on the preferences of the involved contributors and reviewers, code + review then happens either on the `git-security` mailing list or in a private + fork associated with the draft security advisory. + +- Once the review has settled and everyone involved in the review agrees that + the patches are ready, the Git maintainer determines 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 (e.g. operators of hosting sites + who may want to analyze whether the given bug is exploited via any of the + repositories they host). + +- Subsequently, branches with the fixes are pushed to private repositories that + are owned by the Git project, with tightly controlled access. + +- The tags are created by the Git maintainer and pushed to the same + repositories. + +- Less than a week before the release, a mail with the relevant information is + sent to <distros@vs.openwall.org> (see below), a list used to pre-announce embargoed + releases of open source projects to the stakeholders of all major Linux + distributions. This includes a Git bundle of the tagged version(s), but no + further specifics of the vulnerability. + +- 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. + +- The Git for Windows maintainer prepares the corresponding release artifacts, + based on the tags created that have been prepared by the Git maintainer. + +- Git for Windows release artifacts are made available under embargo to + stakeholders via a mail to the `git-security` list. + +- On the day of the release, at around 10am Pacific Time, the Git maintainer + pushes the tag and the `master` branch to the public repository, then sends + out an announcement mail. + +- 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). + +- 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. + +- A mail to <oss-security@lists.openwall.org> (see below for details) is sent as a + follow-up to the <distros@vs.openwall.org> one, describing the vulnerability in + detail, often including a proof of concept of an exploit. + +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 ==================================== @@ -14,30 +129,16 @@ 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, 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 -repositories. +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 +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. +<distros@vs.openwall.org>, 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 https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].