| Message ID | pull.1345.v2.git.1666142160427.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] 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. > > Signed-off-by: Julia Ramer <gitprplr@gmail.com> > --- Thanks for an update that is excellently written. I had only some minor points and random thoughts while reading it. I do not know if all of them need to result in further changes to the document, though. + The 'stakeholders' are explained twice in a bit different terms. The former (owners of products affected by vulnerabilities) description is more broad than the latter and would be more appropriate in general. Perhaps dropping the latter would give us more clarity? - Would a reader, who has "stake" in the healty and secure Git, be helped if we spell out that they are welcome to ask joining the security list and how? It feels a bit too obvious after reading "anybody may contact", which is both the right way to self nominate for the membership and the natural thing I expect such a reader would do, so we may not need to. + The packager whose release artifacts can be exchanged among security list participants under embargo is not limited to Git for Windows, even though we've only seen exchanges between Victoria and Veronica this cycle for that particular distribution. - The world is not limited to only Windows, mac and Linux. Windows is not all that special. + The project maintainer is special in only two ways (tagging and producing release tarballs); in all the other contexts, treat him just like any other contributors. - There may be ways to improve on the lack of formal process to record decisions (e.g. a capable project secretary can notice that stakeholders agreed on a proposed release date, and send a separate message summarizing only that fact so that it would not be missed by casual bystanders), but that is something we should work on elsewhere, not as part of the effort to document the current practice. - I wonder if we want to record the name that is used to refer to the "private repository controlled by the project" on the security mailing list somewhere in the documentation. If you are a stakeholder, being on the mailing list *and* having access to that repository are two things we need to make sure you have to partcipate in the coordinated embargoed releases. + Usually the fixes affect 'maint' and its tip is pointed by one of the tags for the security update release, and 'master' is updated to contain 'maint', but on the 'master' track there is no tag for the security update. Other integration branches like 'next' and 'seen' are also updated to contain the fix. + The "How we coordinate embargoed releases" section looked a bit odd to appear this late in the document. Shouldn't it be moved way higher, even before we start talking about the security list? After all, the security mailing list is a means to the end that the section talks about (i.e. we sometimes need embargoed release process working behind closed doors). Here is a patch that summarises some of the above on top of your patch. I only tried to address the bullet items with "+" in front in the above list. .../howto/coordinate-embargoed-releases.txt | 52 ++++++++++++---------- 1 file changed, 28 insertions(+), 24 deletions(-) diff --git c/Documentation/howto/coordinate-embargoed-releases.txt w/Documentation/howto/coordinate-embargoed-releases.txt index a01398c82b..80af5de297 100644 --- c/Documentation/howto/coordinate-embargoed-releases.txt +++ w/Documentation/howto/coordinate-embargoed-releases.txt @@ -3,6 +3,15 @@ Abstract: When a vulnerability is reported, we follow these guidelines to assess the vulnerability, create and review a fix, and coordinate embargoed security releases. +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. + The `git-security` mailing list ------------------------------- @@ -50,10 +59,11 @@ 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. +- Within a couple of days, someone from the core Git team, including + the Git maintainer, responds with an initial assessment of the + bug’s severity. -- Other core developers - including the Git maintainer - chime in. +- Other core developers 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 @@ -74,9 +84,11 @@ A bug's life: Typical timeline 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 + contributor who worked on the patches, and from stakeholders. Operators of hosting sites who may want to analyze whether the given bug is exploited - via any of the repositories they host). + 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. - 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 @@ -90,18 +102,19 @@ A bug's life: Typical timeline - The tags are created by the Git maintainer and pushed to the same repositories. -- The Git for Windows, Git for macOS, BSD, Debian, etc maintainers prepares the +- The Git for Windows, Git for macOS, BSD, Debian, etc. maintainers 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. +- The release artifacts prepared by various binary packagers can be + made available to stakeholders under embargo via a mail to the + `git-security` list. - 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. + distributions of Linux as well as other OSes. 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. @@ -117,8 +130,8 @@ A bug's life: Typical timeline - 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 Linux distribution packagers: their releases are announced via - their preferred channels. +- Ditto for distribution packagers for Linux and other platforms: + their releases are announced via their preferred channels. - 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 @@ -127,17 +140,8 @@ A bug's life: Typical timeline 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 -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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Opening 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 @@ -239,4 +243,4 @@ it goes to <developer>. Thanks, <name> -.... \ No newline at end of file +....
[-cc git-security] On Wed, Oct 19, 2022 at 01:16:00AM +0000, Julia Ramer via GitGitGadget wrote: > +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). Everything in this section looks good. Though I wonder whether readers will wonder how one subscribes to the list. You sort of address this earlier in the proposed document, but I think it's worth clarifying here to indicate the differences between subscribing to a public list like this one, and the invite-only git-security list. Perhaps something like: [...] the archive is closed to the public, and only accessible to invited members. There are a few dozen such members: [...] which is basically just s/subscribed/invited, but I think it adds some worthwhile clarity. > +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. Looks good, though I am unsure what "priorities and requirements" refers to specifically. Could you elaborate? > +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. A few nitpicks on this and the above bullet point: - The git-security list isn't for bug reports, though there can be a security component to something that looks like a bug report. Perhaps to be clearer we should swap "bug" for "potential vulnerability"? - On "within a couple of days", I think that this is aspirationally true, though not always the case. Perhaps, "as soon as possible" instead? That's vague enough that I wouldn't worry about somebody reading this document >2 days after submitting a potential vulnerability wondering why nobody has gotten back to them ;-). - Finally, consider replacing "core Git team" with "member of the git-security list". > +- 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. There's a third option, too, which is using the private git/cabal repository. Anybody who is a member of the @git/security team on GitHub has access to this repository. And it is often a convenient option for coordinating releases that contain fixes for more than one vulnerability. There aren't any hard and fast rules for which approach should be used in a given circumstance, but I think it's worth mentioning it as another option. For my own $.02, I often find it useful to *start* by sending patches to the git-security list inline with the thread so that the original reporter (who is more often than not *not* a member of the @git/security team) can participate in review (or at least look at the patches). The private forks tied to a security advisory are often convenient (assuming that the reporter has a GitHub account) since they provide a shared workspace. But I think we usually avoid them when working on preparing a release for more than one vulnerability. > +- 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. I strongly agree with the above two points. > +- 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. For what it's worth, GitHub does usually prepare a public blog post, but I don't think we've typically shared them with the git-security list ahead of time. Not because there's anything sensitive in there (I personally would have no problem sharing them with git-security ahead of time if there was interest), but just because nobody has asked. It may be worth clarifying which communications we expect to have reviewed by the git-security list during this period and which we do not. > +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. This is all good. I would add some of the things we need to figure out before opening a security advisory, too. By the time we want to open a security advisory, we need to have the following information decided upon: - Affected version(s) - Patched version(s) - Impact - Potential workaround(s), if any - Credit for finding and fixing the vulnerability Determining which versions to patch is more-or-less up to the person preparing those patches. Affected versions is usually "everything", or "everything since xyz patch was merged". Impact is up for debate, though usually whoever opens the security advisory writes this, and then discussion occurs on the git-security as to its accuracy ;-). Obtaining permission to give credit to the original reporter (and anybody that they wish to include who was also involved in the discovery) is important to do at this step, too. Thanks, Taylor
On Wed, Oct 19, 2022 at 11:53:18AM -0700, Junio C Hamano 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. > > > > Signed-off-by: Julia Ramer <gitprplr@gmail.com> > > --- > > Thanks for an update that is excellently written. Yes, indeed. > - Would a reader, who has "stake" in the healty and secure Git, be > helped if we spell out that they are welcome to ask joining the > security list and how? It feels a bit too obvious after reading > "anybody may contact", which is both the right way to self > nominate for the membership and the natural thing I expect such a > reader would do, so we may not need to. My personal feeling is in agreement with yours, which is that it is probably obvious, so I don't think it's worth spelling out explicitly here. > + The packager whose release artifacts can be exchanged among > security list participants under embargo is not limited to Git > for Windows, even though we've only seen exchanges between > Victoria and Veronica this cycle for that particular > distribution. > > - The world is not limited to only Windows, mac and Linux. Windows > is not all that special. I agree, I think that mentioning Git for Windows in this document is not strictly necessary (e.g., if there were a new "Git for Foo" that came out tomorrow, I would not consider this document out-of-date), but I likewise wouldn't object to it. > - I wonder if we want to record the name that is used to refer to > the "private repository controlled by the project" on the > security mailing list somewhere in the documentation. If you are > a stakeholder, being on the mailing list *and* having access to > that repository are two things we need to make sure you have to > partcipate in the coordinated embargoed releases. This repository (git/cabal) is already well-documented on the mailing list, so I would have no problem including its name here, too. > Here is a patch that summarises some of the above on top of your > patch. I only tried to address the bullet items with "+" in front > in the above list. All looks good to me, thanks. Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: >> +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. > > A few nitpicks on this and the above bullet point: > > - The git-security list isn't for bug reports, though there can be a > security component to something that looks like a bug report. > > Perhaps to be clearer we should swap "bug" for "potential > vulnerability"? Good point and good idea. > - On "within a couple of days", I think that this is aspirationally > true, though not always the case. Perhaps, "as soon as possible" > instead? That's vague enough that I wouldn't worry about somebody > reading this document >2 days after submitting a potential > vulnerability wondering why nobody has gotten back to them ;-). The purpose of giving a "Typical" timeline is primarily to guide readers what to expect once they raise an issue, and to bind us with at least "aspirational" deadline (which is not a bad thing), isn't it? Saying "As soon as possible" there is the same as not saying anything at all, even though in reality it sometimes may be "when somebody feels like it is worth looking into" ;-) Depending on the nature of vulnerability, the time it takes to reach a satisfactory conclusion may range from a few days to a few weeks, so we may not be able to give even a "Typical" timeline, but I do not think it is unreasonable to hold us to a few days turnaround time at least for an initial reaction. That's a roundabout way to say "I think the original text is good". > - Finally, consider replacing "core Git team" with "member of the > git-security list". I am torn. The folks who are deep into core git development may have better ability to assess the severity of a particular bug and the complexity of possible solutions than others, but platform stakeholders know how Git is used within their system and how old the target track they wish to be updated better than us. So in that sense, limiting assessment to core developers may not be ideal. But on the other hand, the initial report to the list are seen only by the security list participants and nobody else, so by definition, any response would come from them ;-) > The private forks tied to a security advisory are often convenient > (assuming that the reporter has a GitHub account) since they provide a > shared workspace. But I think we usually avoid them when working on > preparing a release for more than one vulnerability. Yes, it is convenient for simple things, but not necessarily the best option when we need to roll it upwards to produce releases for multiple maintenance tracks. The rest of your comments and suggestions address all good points. Thanks.
Junio C Hamano <gitster@pobox.com> writes: > -- Within a couple of days, someone from the core Git team responds with an > - initial assessment of the bug’s severity. > +- Within a couple of days, someone from the core Git team, including > + the Git maintainer, responds with an initial assessment of the > + bug’s severity. The "including" here looks even less clear. Does somebody other than me and I should respond? That is not what I wanted to say. Hence ... > -- Other core developers - including the Git maintainer - chime in. > +- Other core developers chime in. ... I wonder if it would be better to consolidate the above two into one bullet point, e.g. - The security-list members start a discussion to give an initial assessment of the severity of potential vulnerability reported. We aspire to do so within a few days. > -- The Git for Windows, Git for macOS, BSD, Debian, etc maintainers prepares the > +- The Git for Windows, Git for macOS, BSD, Debian, etc. maintainers prepares the > corresponding release artifacts, based on the tags created that have been > prepared by the Git maintainer. "prepares" -> "prepare". > - 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. > + distributions of Linux as well as other OSes. This includes a Git bundle > + of the tagged version(s), but no further specifics of the vulnerability. The bundle contains enough information to recreate these tagged versions under embargo, hence the release notes for these releases that discloses the vulnerability. Perhaps drop "but no further..."?
On Wed, Oct 19, 2022 at 05:15:03PM -0400, Taylor Blau wrote: > > +- 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. > > There's a third option, too, which is using the private git/cabal > repository. Anybody who is a member of the @git/security team on GitHub > has access to this repository. And it is often a convenient option for > coordinating releases that contain fixes for more than one > vulnerability. > > There aren't any hard and fast rules for which approach should be used > in a given circumstance, but I think it's worth mentioning it as another > option. > > For my own $.02, I often find it useful to *start* by sending patches to > the git-security list inline with the thread so that the original > reporter (who is more often than not *not* a member of the @git/security > team) can participate in review (or at least look at the patches). > > The private forks tied to a security advisory are often convenient > (assuming that the reporter has a GitHub account) since they provide a > shared workspace. But I think we usually avoid them when working on > preparing a release for more than one vulnerability. Here is some proposed language that I think would encompass everything both you and I wrote here: 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. Contributors working on a fix should consider beginning by sending patches on the list (inline with the original thread), since they are accessible to all subscribers, along with the original reporter. A typical review cycle often takes place here. Then, depending on if there are one or multiple security advisories, contributors should move their patches to either the private fork associated with the security advisory on GitHub, or the git/cabal repository. It is in either one of these locations that release branches (based on `maint`) are prepared. When there is a single security vulnerability, using the fork associated with the security advisory is convenient as it centralizes discussion, review, and release mechanics at a single location. When there are multiple such vulnerabilities, no single temporary fork is appropriate, so it is instead encouraged to use the private git/cabal repository (visibility of which is granted to members of the @git/security team on GitHub). Thanks, Taylor
diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt index 601aae88e9a..a01398c82b5 100644 --- a/Documentation/howto/coordinate-embargoed-releases.txt +++ b/Documentation/howto/coordinate-embargoed-releases.txt @@ -1,9 +1,134 @@ 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, 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. + +- 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. + +- The Git for Windows, Git for macOS, BSD, Debian, etc maintainers 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. + +- 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. + +- 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. + +- Ditto for Linux distribution packagers: their releases are announced via + their preferred channels. + +- 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 -==================================== +------------------------------------ To protect Git users from critical vulnerabilities, we do not just release fixed versions like regular maintenance releases. Instead, we coordinate @@ -12,32 +137,18 @@ 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, 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]. @@ -65,7 +176,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 @@ -101,7 +212,7 @@ Thanks, .... Example mail to oss-security@lists.openwall.com ------------------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .... To: oss-security@lists.openwall.com @@ -128,4 +239,4 @@ it goes to <developer>. Thanks, <name> -.... +.... \ No newline at end of file