{"thread":{"id":"55393","subject":"[PATCH 0/2] Describe Git's security policy","startedAt":"2021-03-26T22:13:48Z","lastAt":"2021-04-20T23:34:33Z","messageCount":15,"participants":["Johannes Schindelin via GitGitGadget","Denton Liu","Bagas Sanjaya","Johannes Schindelin","Robin H. Johnson","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"420284","messageId":"pull.917.git.1616796767.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":null,"subject":"[PATCH 0/2] Describe Git's security policy","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-26T22:12:44Z","receivedAt":"2021-03-26T22:13:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On GitHub, SECURITY.md files are the recommended way to describe how to\nreport vulnerabilities, and to set expectations how far back maintenance\ntracks are updated with security bug fixes.\n\nFor example, when navigating to https://github.com/git/git/security/ users\nwould be guided to that SECURITY.md file. If it exists.\n\nThe purpose of this patch series is to add this file, describing Git's\nsecurity policy.\n\nWhile at it, I also want to document the process how to coordinate the\nensuing embargoed releases. This is what the second patch is all about.\n\nThe reason for that is quite selfish, as I did two of them, and while I am\nhappy that such embargoed releases do not happen all that often, the\ndownside is that I keep forgetting all the details. So this document is not\nonly meant for knowledge sharing, but in particular to help me the next\ntime(s) I coordinate an embargoed release.\n\nMany thanks to Junio who reviewed the first draft of this patch series\n(where I had not yet separated out\nDocumentation/howto/coordinate-embargoed-releases.txt).\n\nJohannes Schindelin (2):\n SECURITY: describe how to report vulnerabilities\n Document how we do embargoed releases\n\n Documentation/Makefile | 1 +\n .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++\n SECURITY.md | 51 +++++++\n 3 files changed, 183 insertions(+)\n create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt\n create mode 100644 SECURITY.md\n\n\nbase-commit: e6362826a0409539642a5738db61827e5978e2e4\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-917%2Fdscho%2Fsecurity-policy-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-917/dscho/security-policy-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/917\n-- \ngitgitgadget\n"},{"id":"420285","messageId":"41efaaf62864c353f828d1b6f0a8e4203c658e14.1616796767.git.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":"pull.917.git.1616796767.gitgitgadget@gmail.com","subject":"[PATCH 2/2] Document how we do embargoed releases","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-26T22:12:46Z","receivedAt":"2021-03-26T22:13:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nWhenever we fix critical vulnerabilities, we follow some sort of\nprotocol (e.g. setting a coordinated release date, keeping the fix under\nembargo until that time, coordinating with packagers and/or hosting\nsites, etc).\n\nSimilar in spirit to `Documentation/howto/maintain-git.txt`, let's\nformalize the details in a document.\n\nSigned-off-by: Johannes Schindelin \n---\n Documentation/Makefile | 1 +\n .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++\n 2 files changed, 132 insertions(+)\n create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 81d1bf7a049b..874a01d7a86e 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -76,6 +76,7 @@ SP_ARTICLES += howto/rebuild-from-update-hook\n SP_ARTICLES += howto/rebase-from-internal-branch\n SP_ARTICLES += howto/keep-canonical-history-correct\n SP_ARTICLES += howto/maintain-git\n+SP_ARTICLES += howto/coordinate-embargoed-releases\n API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))\n SP_ARTICLES += $(API_DOCS)\n \ndiff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt\nnew file mode 100644\nindex 000000000000..601aae88e9a3\n--- /dev/null\n+++ b/Documentation/howto/coordinate-embargoed-releases.txt\n@@ -0,0 +1,131 @@\n+Content-type: text/asciidoc\n+Abstract: When a critical vulnerability is discovered and fixed, we follow this\n+ script to coordinate a public release.\n+\n+How we coordinate embargoed releases\n+====================================\n+\n+To protect Git users from critical vulnerabilities, we do not just release\n+fixed versions like regular maintenance releases. Instead, we coordinate\n+releases with packagers, keeping the fixes under an embargo until the release\n+date. That way, users will have a chance to upgrade on that date, no matter\n+what Operating System or distribution they run.\n+\n+Open a Security Advisory draft\n+------------------------------\n+\n+The first step is to https://github.com/git/git/security/advisories/new[open an\n+advisory]. Technically, it is not necessary, but it is convenient and saves a\n+bit of hassle. This advisory can also be used to obtain the CVE number and it\n+will give us a private fork associated with it that can be used to collaborate\n+on a fix.\n+\n+Release date of the embargoed version\n+-------------------------------------\n+\n+If the vulnerability affects Windows users, we want to have our friends over at\n+Visual Studio on board. This means we need to target a \"Patch Tuesday\" (i.e. a\n+second Tuesday of the month), at the minimum three weeks from heads-up to\n+coordinated release.\n+\n+If the vulnerability affects the server side, or can benefit from scans on the\n+server side (i.e. if `git fsck` can detect an attack), it is important to give\n+all involved Git repository hosting sites enough time to scan all of those\n+repositories.\n+\n+Notifying the Linux distributions\n+---------------------------------\n+\n+At most two weeks before release date, we need to send a notification to\n+distros@vs.openwall.org, preferably less than 7 days before the release date.\n+This will reach most (all?) Linux distributions. See an example below, and the\n+guidelines for this mailing list at\n+https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].\n+\n+Once the version has been published, we send a note about that to oss-security.\n+As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the\n+v2.24.1 mail];\n+https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are\n+their guidelines.\n+\n+The mail to oss-security should also describe the exploit, and give credit to\n+the reporter(s): security researchers still receive too little respect for the\n+invaluable service they provide, and public credit goes a long way to keep them\n+paid by their respective organizations.\n+\n+Technically, describing any exploit can be delayed up to 7 days, but we usually\n+refrain from doing that, including it right away.\n+\n+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list\n+will drop `.bundle` attachments) in the mail to distros@ so that the involved\n+parties can take care of integrating/backporting them. This bundle is typically\n+created using a command like this:\n+\n+\tgit bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F\n+\ttar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle\n+\n+Example mail to distros@vs.openwall.org\n+---------------------------------------\n+\n+....\n+To: distros@vs.openwall.org\n+Cc: git-security@googlegroups.com, \n+Subject: [vs] Upcoming Git security fix release\n+\n+Team,\n+\n+The Git project will release new versions on at 10am Pacific Time or\n+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid\n+it being dropped) which you can fetch into a clone of\n+https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,\n+containing the tags for versions .\n+\n+You can verify with `git tag -v ` that the versions were signed by\n+the Git maintainer, using the same GPG key as e.g. v2.24.0.\n+\n+Please use these tags to prepare `git` packages for your various\n+distributions, using the appropriate tagged versions. The added test cases\n+help verify the correctness.\n+\n+The addressed issues are:\n+\n+\n+\n+Credit for finding the vulnerability goes to , credit for fixing\n+it goes to .\n+\n+Thanks,\n+\n+\n+....\n+\n+Example mail to oss-security@lists.openwall.com\n+-----------------------------------------------\n+\n+....\n+To: oss-security@lists.openwall.com\n+Cc: git-security@googlegroups.com, \n+Subject: git: \n+\n+Team,\n+\n+The Git project released new versions on , addressing .\n+\n+All supported platforms are affected in one way or another, and all Git\n+versions all the way back to are affected. The fixed versions are:\n+.\n+\n+Link to the announcement: \n+\n+We highly recommend to upgrade.\n+\n+The addressed issues are:\n+* \n+\n+Credit for finding the vulnerability goes to , credit for fixing\n+it goes to .\n+\n+Thanks,\n+\n+....\n-- \ngitgitgadget\n"},{"id":"420286","messageId":"2c9f5725d96fe45aa5d1a6bbc522f9ed6161173c.1616796767.git.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":"pull.917.git.1616796767.gitgitgadget@gmail.com","subject":"[PATCH 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-26T22:12:45Z","receivedAt":"2021-03-26T22:13:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIn the same document, describe that Git does not have Long Term Support\n(LTS) release trains, although security fixes are always applied to a\nfew of the most recent release trains.\n\nSigned-off-by: Johannes Schindelin \n---\n SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 51 insertions(+)\n create mode 100644 SECURITY.md\n\ndiff --git a/SECURITY.md b/SECURITY.md\nnew file mode 100644\nindex 000000000000..282790164e78\n--- /dev/null\n+++ b/SECURITY.md\n@@ -0,0 +1,51 @@\n+# Security Policy\n+\n+## Reporting a vulnerability\n+\n+Please send a detailed mail to git-security@googlegroups.com to\n+report vulnerabilities in Git.\n+\n+Even when unsure whether the bug in question is an exploitable\n+vulnerability, it is recommended to send the report to\n+git-security@googlegroups.com (and obviously not to discuss the\n+issue anywhere else).\n+\n+Vulnerabilities are expected to be discussed _only_ on that\n+list, and not in public, until the official announcement on the\n+Git mailing list on the release date.\n+\n+Examples for details to include:\n+\n+- Ideally a short description (or a script) to demonstrate an\n+ exploit.\n+- The affected platforms and scenarios (the vulnerability might\n+ only affect setups with case-sensitiv file systems, for\n+ example).\n+- The name and affiliation of the security researchers who are\n+ involved in the discovery, if any.\n+- Whether the vulnerability has already been disclosed.\n+- How long an embargo would be required to be safe.\n+\n+## Supported Versions\n+\n+There are no official \"Long Term Support\" versions in Git.\n+Instead, the maintenance track (i.e. the versions based on the\n+most recently published feature release, also known as \".0\"\n+version) sees occasional updates with bug fixes.\n+\n+Fixes to vulnerabilities are made for the maintenance track for\n+the latest feature release and merged up to the in-development\n+branches. The Git project makes no formal guarantee for any\n+older maintenance tracks to receive updates. In practice,\n+though, critical vulnerability fixes are applied not only to the\n+most recent track, but to at least a couple more maintenance\n+tracks.\n+\n+This is typically done by making the fix on the oldest and still\n+relevant maintenance track, and merging it upwards to newer and\n+newer maintenance tracks.\n+\n+For example, v2.24.1 was released to address a couple of\n+[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,\n+v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,\n+v2.22.2 and v2.23.1 were released.\n-- \ngitgitgadget\n\n"},{"id":"420290","messageId":"YF51hOQlNlBRQRcl@generichostname","threadId":"55393","inReplyTo":"2c9f5725d96fe45aa5d1a6bbc522f9ed6161173c.1616796767.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2021-03-27T00:00:04Z","receivedAt":"2021-03-27T00:01:06Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Dscho,\n\nOn Fri, Mar 26, 2021 at 10:12:45PM +0000, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin \n> \n> In the same document, describe that Git does not have Long Term Support\n> (LTS) release trains, although security fixes are always applied to a\n> few of the most recent release trains.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 51 insertions(+)\n> create mode 100644 SECURITY.md\n> \n> diff --git a/SECURITY.md b/SECURITY.md\n> new file mode 100644\n> index 000000000000..282790164e78\n> --- /dev/null\n> +++ b/SECURITY.md\n> @@ -0,0 +1,51 @@\n> +# Security Policy\n> +\n> +## Reporting a vulnerability\n> +\n> +Please send a detailed mail to git-security@googlegroups.com to\n> +report vulnerabilities in Git.\n> +\n> +Even when unsure whether the bug in question is an exploitable\n> +vulnerability, it is recommended to send the report to\n> +git-security@googlegroups.com (and obviously not to discuss the\n> +issue anywhere else).\n> +\n> +Vulnerabilities are expected to be discussed _only_ on that\n> +list, and not in public, until the official announcement on the\n> +Git mailing list on the release date.\n> +\n> +Examples for details to include:\n> +\n> +- Ideally a short description (or a script) to demonstrate an\n> + exploit.\n> +- The affected platforms and scenarios (the vulnerability might\n> + only affect setups with case-sensitiv file systems, for\n\nSmall typo: s/sensitiv/&e/\n"},{"id":"420293","messageId":"4f715120-3cd3-9f14-a291-0eb6e83a940e@gmail.com","threadId":"55393","inReplyTo":"2c9f5725d96fe45aa5d1a6bbc522f9ed6161173c.1616796767.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-03-27T06:34:28Z","receivedAt":"2021-03-27T06:35:31Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 27/03/21 05.12, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin \n> \n> In the same document, describe that Git does not have Long Term Support\n> (LTS) release trains, although security fixes are always applied to a\n> few of the most recent release trains.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 51 insertions(+)\n> create mode 100644 SECURITY.md\n> \n> diff --git a/SECURITY.md b/SECURITY.md\n> new file mode 100644\n> index 000000000000..282790164e78\n> --- /dev/null\n> +++ b/SECURITY.md\n> @@ -0,0 +1,51 @@\n> +# Security Policy\n> +\n> +## Reporting a vulnerability\n> +\n> +Please send a detailed mail to git-security@googlegroups.com to\n> +report vulnerabilities in Git.\n> +\n> +Even when unsure whether the bug in question is an exploitable\n> +vulnerability, it is recommended to send the report to\n> +git-security@googlegroups.com (and obviously not to discuss the\n> +issue anywhere else).\nWhat about using reference word (`... it is recommended to send the\nreport to that mailing list`)?\n> +Vulnerabilities are expected to be discussed _only_ on that\n> +list, and not in public, until the official announcement on the\n> +Git mailing list on the release date.\n> +\n> +Examples for details to include:\n> +\n> +- Ideally a short description (or a script) to demonstrate an\n> + exploit.\n> +- The affected platforms and scenarios (the vulnerability might\n> + only affect setups with case-sensitiv file systems, for\n> + example).\nOops, s/case-sensitiv/case-sensitive/\n> +- The name and affiliation of the security researchers who are\n> + involved in the discovery, if any.\n> +- Whether the vulnerability has already been disclosed.\n> +- How long an embargo would be required to be safe.\n> +\n> +## Supported Versions\nThe header should be `Supported Versions and How Maintenance\nReleases are Made`.\n> +\n> +There are no official \"Long Term Support\" versions in Git.\n> +Instead, the maintenance track (i.e. the versions based on the\n> +most recently published feature release, also known as \".0\"\n> +version) sees occasional updates with bug fixes.\n> +\n> +Fixes to vulnerabilities are made for the maintenance track for\n> +the latest feature release and merged up to the in-development\n> +branches. The Git project makes no formal guarantee for any\n> +older maintenance tracks to receive updates. In practice,\n> +though, critical vulnerability fixes are applied not only to the\n> +most recent track, but to at least a couple more maintenance\n> +tracks.\n> +\n> +This is typically done by making the fix on the oldest and still\n> +relevant maintenance track, and merging it upwards to newer and\n> +newer maintenance tracks.\nAFAIK, maint branch are based on latest feature release (say v2.24),\nand any bugfixes there are cherry-picked to relevant older releases,\nbut does it mean resetting maint branch to that older release, and\nthen resetting back to before that? Or how tagged maintenance release\nare made without resetting maint?\n> +For example, v2.24.1 was released to address a couple of\n> +[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,\n> +v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,\n> +v2.22.2 and v2.23.1 were released.\n> \n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"420469","messageId":"nycvar.QRO.7.76.6.2103291536440.53@tvgsbejvaqbjf.bet","threadId":"55393","inReplyTo":"YF51hOQlNlBRQRcl@generichostname","subject":"Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-03-29T13:37:23Z","receivedAt":"2021-03-29T13:38:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Denton,\n\nOn Fri, 26 Mar 2021, Denton Liu wrote:\n\n> On Fri, Mar 26, 2021 at 10:12:45PM +0000, Johannes Schindelin via GitGitGadget wrote:\n> > [...]\n> >\n> > +\n> > +Examples for details to include:\n> > +\n> > +- Ideally a short description (or a script) to demonstrate an\n> > + exploit.\n> > +- The affected platforms and scenarios (the vulnerability might\n> > + only affect setups with case-sensitiv file systems, for\n>\n> Small typo: s/sensitiv/&e/\n\nThanks! Fixed in v2.\n\nCiao,\nDscho\n"},{"id":"420470","messageId":"nycvar.QRO.7.76.6.2103291537290.53@tvgsbejvaqbjf.bet","threadId":"55393","inReplyTo":"4f715120-3cd3-9f14-a291-0eb6e83a940e@gmail.com","subject":"Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-03-29T13:41:42Z","receivedAt":"2021-03-29T13:42:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bagas,\n\nOn Sat, 27 Mar 2021, Bagas Sanjaya wrote:\n\n> On 27/03/21 05.12, Johannes Schindelin via GitGitGadget wrote:\n> > From: Johannes Schindelin \n> >\n> > In the same document, describe that Git does not have Long Term Support\n> > (LTS) release trains, although security fixes are always applied to a\n> > few of the most recent release trains.\n> >\n> > Signed-off-by: Johannes Schindelin \n> > ---\n> > SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n> > 1 file changed, 51 insertions(+)\n> > create mode 100644 SECURITY.md\n> >\n> > diff --git a/SECURITY.md b/SECURITY.md\n> > new file mode 100644\n> > index 000000000000..282790164e78\n> > --- /dev/null\n> > +++ b/SECURITY.md\n> > @@ -0,0 +1,51 @@\n> > +# Security Policy\n> > +\n> > +## Reporting a vulnerability\n> > +\n> > +Please send a detailed mail to git-security@googlegroups.com to\n> > +report vulnerabilities in Git.\n> > +\n> > +Even when unsure whether the bug in question is an exploitable\n> > +vulnerability, it is recommended to send the report to\n> > +git-security@googlegroups.com (and obviously not to discuss the\n> > +issue anywhere else).\n>\n> What about using reference word (`... it is recommended to send the\n> report to that mailing list`)?\n\nI would really like to repeat the email address here, to make really\ncertain that the reader uses the correct one.\n\n> > +Vulnerabilities are expected to be discussed _only_ on that\n> > +list, and not in public, until the official announcement on the\n> > +Git mailing list on the release date.\n> > +\n> > +Examples for details to include:\n> > +\n> > +- Ideally a short description (or a script) to demonstrate an\n> > + exploit.\n> > +- The affected platforms and scenarios (the vulnerability might\n> > + only affect setups with case-sensitiv file systems, for\n> > + example).\n>\n> Oops, s/case-sensitiv/case-sensitive/\n\nYes, thanks, it will be fixed in v2.\n\n> > +- The name and affiliation of the security researchers who are\n> > + involved in the discovery, if any.\n> > +- Whether the vulnerability has already been disclosed.\n> > +- How long an embargo would be required to be safe.\n> > +\n> > +## Supported Versions\n>\n> The header should be `Supported Versions and How Maintenance\n> Releases are Made`.\n\nNot really. The maintenance is described in\nDocumentation/howto/maintain-git.txt. It is not the purpose of\n`SECURITY.md` to document that, it just so happens that we hint a bit at\nit while talking about which branches get security updates.\n\n> > +\n> > +There are no official \"Long Term Support\" versions in Git.\n> > +Instead, the maintenance track (i.e. the versions based on the\n> > +most recently published feature release, also known as \".0\"\n> > +version) sees occasional updates with bug fixes.\n> > +\n> > +Fixes to vulnerabilities are made for the maintenance track for\n> > +the latest feature release and merged up to the in-development\n> > +branches. The Git project makes no formal guarantee for any\n> > +older maintenance tracks to receive updates. In practice,\n> > +though, critical vulnerability fixes are applied not only to the\n> > +most recent track, but to at least a couple more maintenance\n> > +tracks.\n> > +\n> > +This is typically done by making the fix on the oldest and still\n> > +relevant maintenance track, and merging it upwards to newer and\n> > +newer maintenance tracks.\n>\n> AFAIK, maint branch are based on latest feature release (say v2.24),\n> and any bugfixes there are cherry-picked to relevant older releases,\n> but does it mean resetting maint branch to that older release, and\n> then resetting back to before that? Or how tagged maintenance release\n> are made without resetting maint?\n\nThere are `maint-` branches, e.g. `maint-2.30`,\n`maint-2.29`, etc.\n\nBut it really is not even interesting in the context of security updates\nhow those maintenance branches are called, it is only interesting which\nversions will receive updates (and the updates come in the form of a\nnewly-tagged version, not in the form of an updated `maint-`\nbranch; The latter just _happens_ to also happen, for maintenance\nreasons).\n\n> > +For example, v2.24.1 was released to address a couple of\n> > +[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,\n> > +v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,\n> > +v2.22.2 and v2.23.1 were released.\n\nThank you for your review!\nJohannes\n"},{"id":"420471","messageId":"pull.917.v2.git.1617025385.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":"pull.917.git.1616796767.gitgitgadget@gmail.com","subject":"[PATCH v2 0/2] Describe Git's security policy","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-29T13:43:02Z","receivedAt":"2021-03-29T13:43:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On GitHub, SECURITY.md files are the recommended way to describe how to\nreport vulnerabilities, and to set expectations how far back maintenance\ntracks are updated with security bug fixes.\n\nFor example, when navigating to https://github.com/git/git/security/ users\nwould be guided to that SECURITY.md file. If it exists.\n\nThe purpose of this patch series is to add this file, describing Git's\nsecurity policy.\n\nWhile at it, I also want to document the process how to coordinate the\nensuing embargoed releases. This is what the second patch is all about.\n\nThe reason for that is quite selfish, as I did two of them, and while I am\nhappy that such embargoed releases do not happen all that often, the\ndownside is that I keep forgetting all the details. So this document is not\nonly meant for knowledge sharing, but in particular to help me the next\ntime(s) I coordinate an embargoed release.\n\nMany thanks to Junio who reviewed the first draft of this patch series\n(where I had not yet separated out\nDocumentation/howto/coordinate-embargoed-releases.txt).\n\nChanges since v1:\n\n * Fixed typo\n\nJohannes Schindelin (2):\n SECURITY: describe how to report vulnerabilities\n Document how we do embargoed releases\n\n Documentation/Makefile | 1 +\n .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++\n SECURITY.md | 51 +++++++\n 3 files changed, 183 insertions(+)\n create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt\n create mode 100644 SECURITY.md\n\n\nbase-commit: e6362826a0409539642a5738db61827e5978e2e4\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-917%2Fdscho%2Fsecurity-policy-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-917/dscho/security-policy-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/917\n\nRange-diff vs v1:\n\n 1: 2c9f5725d96f ! 1: 3f5d866de195 SECURITY: describe how to report vulnerabilities\n @@ SECURITY.md (new)\n +- Ideally a short description (or a script) to demonstrate an\n + exploit.\n +- The affected platforms and scenarios (the vulnerability might\n -+ only affect setups with case-sensitiv file systems, for\n ++ only affect setups with case-sensitive file systems, for\n + example).\n +- The name and affiliation of the security researchers who are\n + involved in the discovery, if any.\n 2: 41efaaf62864 = 2: 565d7982d870 Document how we do embargoed releases\n\n-- \ngitgitgadget\n"},{"id":"420472","messageId":"565d7982d870fb1b7644a9777aef6be7ee174dba.1617025385.git.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":"pull.917.v2.git.1617025385.gitgitgadget@gmail.com","subject":"[PATCH v2 2/2] Document how we do embargoed releases","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-29T13:43:04Z","receivedAt":"2021-03-29T13:43:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nWhenever we fix critical vulnerabilities, we follow some sort of\nprotocol (e.g. setting a coordinated release date, keeping the fix under\nembargo until that time, coordinating with packagers and/or hosting\nsites, etc).\n\nSimilar in spirit to `Documentation/howto/maintain-git.txt`, let's\nformalize the details in a document.\n\nSigned-off-by: Johannes Schindelin \n---\n Documentation/Makefile | 1 +\n .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++\n 2 files changed, 132 insertions(+)\n create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 81d1bf7a049b..874a01d7a86e 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -76,6 +76,7 @@ SP_ARTICLES += howto/rebuild-from-update-hook\n SP_ARTICLES += howto/rebase-from-internal-branch\n SP_ARTICLES += howto/keep-canonical-history-correct\n SP_ARTICLES += howto/maintain-git\n+SP_ARTICLES += howto/coordinate-embargoed-releases\n API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))\n SP_ARTICLES += $(API_DOCS)\n \ndiff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt\nnew file mode 100644\nindex 000000000000..601aae88e9a3\n--- /dev/null\n+++ b/Documentation/howto/coordinate-embargoed-releases.txt\n@@ -0,0 +1,131 @@\n+Content-type: text/asciidoc\n+Abstract: When a critical vulnerability is discovered and fixed, we follow this\n+ script to coordinate a public release.\n+\n+How we coordinate embargoed releases\n+====================================\n+\n+To protect Git users from critical vulnerabilities, we do not just release\n+fixed versions like regular maintenance releases. Instead, we coordinate\n+releases with packagers, keeping the fixes under an embargo until the release\n+date. That way, users will have a chance to upgrade on that date, no matter\n+what Operating System or distribution they run.\n+\n+Open a Security Advisory draft\n+------------------------------\n+\n+The first step is to https://github.com/git/git/security/advisories/new[open an\n+advisory]. Technically, it is not necessary, but it is convenient and saves a\n+bit of hassle. This advisory can also be used to obtain the CVE number and it\n+will give us a private fork associated with it that can be used to collaborate\n+on a fix.\n+\n+Release date of the embargoed version\n+-------------------------------------\n+\n+If the vulnerability affects Windows users, we want to have our friends over at\n+Visual Studio on board. This means we need to target a \"Patch Tuesday\" (i.e. a\n+second Tuesday of the month), at the minimum three weeks from heads-up to\n+coordinated release.\n+\n+If the vulnerability affects the server side, or can benefit from scans on the\n+server side (i.e. if `git fsck` can detect an attack), it is important to give\n+all involved Git repository hosting sites enough time to scan all of those\n+repositories.\n+\n+Notifying the Linux distributions\n+---------------------------------\n+\n+At most two weeks before release date, we need to send a notification to\n+distros@vs.openwall.org, preferably less than 7 days before the release date.\n+This will reach most (all?) Linux distributions. See an example below, and the\n+guidelines for this mailing list at\n+https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].\n+\n+Once the version has been published, we send a note about that to oss-security.\n+As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the\n+v2.24.1 mail];\n+https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are\n+their guidelines.\n+\n+The mail to oss-security should also describe the exploit, and give credit to\n+the reporter(s): security researchers still receive too little respect for the\n+invaluable service they provide, and public credit goes a long way to keep them\n+paid by their respective organizations.\n+\n+Technically, describing any exploit can be delayed up to 7 days, but we usually\n+refrain from doing that, including it right away.\n+\n+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list\n+will drop `.bundle` attachments) in the mail to distros@ so that the involved\n+parties can take care of integrating/backporting them. This bundle is typically\n+created using a command like this:\n+\n+\tgit bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F\n+\ttar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle\n+\n+Example mail to distros@vs.openwall.org\n+---------------------------------------\n+\n+....\n+To: distros@vs.openwall.org\n+Cc: git-security@googlegroups.com, \n+Subject: [vs] Upcoming Git security fix release\n+\n+Team,\n+\n+The Git project will release new versions on at 10am Pacific Time or\n+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid\n+it being dropped) which you can fetch into a clone of\n+https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,\n+containing the tags for versions .\n+\n+You can verify with `git tag -v ` that the versions were signed by\n+the Git maintainer, using the same GPG key as e.g. v2.24.0.\n+\n+Please use these tags to prepare `git` packages for your various\n+distributions, using the appropriate tagged versions. The added test cases\n+help verify the correctness.\n+\n+The addressed issues are:\n+\n+\n+\n+Credit for finding the vulnerability goes to , credit for fixing\n+it goes to .\n+\n+Thanks,\n+\n+\n+....\n+\n+Example mail to oss-security@lists.openwall.com\n+-----------------------------------------------\n+\n+....\n+To: oss-security@lists.openwall.com\n+Cc: git-security@googlegroups.com, \n+Subject: git: \n+\n+Team,\n+\n+The Git project released new versions on , addressing .\n+\n+All supported platforms are affected in one way or another, and all Git\n+versions all the way back to are affected. The fixed versions are:\n+.\n+\n+Link to the announcement: \n+\n+We highly recommend to upgrade.\n+\n+The addressed issues are:\n+* \n+\n+Credit for finding the vulnerability goes to , credit for fixing\n+it goes to .\n+\n+Thanks,\n+\n+....\n-- \ngitgitgadget\n"},{"id":"420473","messageId":"3f5d866de1954cce0b12b83d99f5a5f814998db5.1617025385.git.gitgitgadget@gmail.com","threadId":"55393","inReplyTo":"pull.917.v2.git.1617025385.gitgitgadget@gmail.com","subject":"[PATCH v2 1/2] SECURITY: describe how to report vulnerabilities","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-03-29T13:43:03Z","receivedAt":"2021-03-29T13:43:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIn the same document, describe that Git does not have Long Term Support\n(LTS) release trains, although security fixes are always applied to a\nfew of the most recent release trains.\n\nSigned-off-by: Johannes Schindelin \n---\n SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 51 insertions(+)\n create mode 100644 SECURITY.md\n\ndiff --git a/SECURITY.md b/SECURITY.md\nnew file mode 100644\nindex 000000000000..c720c2ae7f95\n--- /dev/null\n+++ b/SECURITY.md\n@@ -0,0 +1,51 @@\n+# Security Policy\n+\n+## Reporting a vulnerability\n+\n+Please send a detailed mail to git-security@googlegroups.com to\n+report vulnerabilities in Git.\n+\n+Even when unsure whether the bug in question is an exploitable\n+vulnerability, it is recommended to send the report to\n+git-security@googlegroups.com (and obviously not to discuss the\n+issue anywhere else).\n+\n+Vulnerabilities are expected to be discussed _only_ on that\n+list, and not in public, until the official announcement on the\n+Git mailing list on the release date.\n+\n+Examples for details to include:\n+\n+- Ideally a short description (or a script) to demonstrate an\n+ exploit.\n+- The affected platforms and scenarios (the vulnerability might\n+ only affect setups with case-sensitive file systems, for\n+ example).\n+- The name and affiliation of the security researchers who are\n+ involved in the discovery, if any.\n+- Whether the vulnerability has already been disclosed.\n+- How long an embargo would be required to be safe.\n+\n+## Supported Versions\n+\n+There are no official \"Long Term Support\" versions in Git.\n+Instead, the maintenance track (i.e. the versions based on the\n+most recently published feature release, also known as \".0\"\n+version) sees occasional updates with bug fixes.\n+\n+Fixes to vulnerabilities are made for the maintenance track for\n+the latest feature release and merged up to the in-development\n+branches. The Git project makes no formal guarantee for any\n+older maintenance tracks to receive updates. In practice,\n+though, critical vulnerability fixes are applied not only to the\n+most recent track, but to at least a couple more maintenance\n+tracks.\n+\n+This is typically done by making the fix on the oldest and still\n+relevant maintenance track, and merging it upwards to newer and\n+newer maintenance tracks.\n+\n+For example, v2.24.1 was released to address a couple of\n+[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,\n+v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,\n+v2.22.2 and v2.23.1 were released.\n-- \ngitgitgadget\n\n"},{"id":"422468","messageId":"robbat2-20210420T193302-520335089Z@orbis-terrarum.net","threadId":"55393","inReplyTo":"565d7982d870fb1b7644a9777aef6be7ee174dba.1617025385.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2021-04-20T19:50:44Z","receivedAt":"2021-04-20T19:50:48Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Mon, Mar 29, 2021 at 01:43:04PM +0000, Johannes Schindelin via GitGitGadget wrote:\n> Whenever we fix critical vulnerabilities, we follow some sort of\n> protocol (e.g. setting a coordinated release date, keeping the fix under\n> embargo until that time, coordinating with packagers and/or hosting\n> sites, etc).\n> \n> Similar in spirit to `Documentation/howto/maintain-git.txt`, let's\n> formalize the details in a document.\n...\n> +Notifying the Linux distributions\n> +---------------------------------\nAs one of the Gentoo maintainer for Git, I was wondering if the\nembargoed-releases process could be tweaked slightly.\n\nSpecifically, in the embargo email, could you please publishing the\nexact size & digests of the to-be-released tarballs, esp. the htmldocs &\nmanpages tarballs.\n\nGentoo, as a source-based distribution, intends users to download the\nupstream tarballs (we mirror them as well), and verify the digests of\nthe tarballs vs a signed copy of what the digests should be.\n\nThis has meant some delay at the end of embargoed releases because we\nhave to wait for the official files to be available, then update the\nbuild instructions (specifically \"Manifest\" which contains the matching\ndigests), and get that out to users.\n\nFields in of the Gentoo side of the digests:\nname, size, digests w/ prefix.\n\nExample:\nDIST git-2.31.1.tar.xz 6413368 BLAKE2B ... SHA512 ...\nDIST git-htmldocs-2.31.1.tar.xz 1357592 BLAKE2B ... SHA512 ...\nDIST git-manpages-2.31.1.tar.xz 487784 BLAKE2B ... SHA512 ...\n\nThe minimum set of hash algorithms for this Gentoo code right now is\nBLAKE2B, which should be easy to script into the announcement mail via:\nopenssl dgst -blake2b512 \"$FILENAME\"\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Dev, Infra Lead, Foundation Treasurer\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\nGnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136\n"},{"id":"422481","messageId":"xmqq5z0g4oc9.fsf@gitster.g","threadId":"55393","inReplyTo":"robbat2-20210420T193302-520335089Z@orbis-terrarum.net","subject":"Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-20T21:51:02Z","receivedAt":"2021-04-20T21:52:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robin H. Johnson\" writes:\n\n> On Mon, Mar 29, 2021 at 01:43:04PM +0000, Johannes Schindelin via GitGitGadget wrote:\n>> Whenever we fix critical vulnerabilities, we follow some sort of\n>> protocol (e.g. setting a coordinated release date, keeping the fix under\n>> embargo until that time, coordinating with packagers and/or hosting\n>> sites, etc).\n>> \n>> Similar in spirit to `Documentation/howto/maintain-git.txt`, let's\n>> formalize the details in a document.\n> ...\n>> +Notifying the Linux distributions\n>> +---------------------------------\n> As one of the Gentoo maintainer for Git, I was wondering if the\n> embargoed-releases process could be tweaked slightly.\n>\n> Specifically, in the embargo email, could you please publishing the\n> exact size & digests of the to-be-released tarballs, esp. the htmldocs &\n> manpages tarballs.\n\nHTMLdocs and Manpages are as far as I am concerned part of SOURCES.\n\nThey are generated from the true sources, I do not give signed tags\nto them, and as a source-based distribution, Gentoo shouldn't\nconsider them as such, either. When release tags are signed, their\nsizes or digests are simply unavailable, since they have not even\nbeen generated yet (I tag the releases, run make in the tagged\nrelease tarball extract and that is what is tarred up as HTMLdocs\nand or Manpages).\n\n\n> Gentoo, as a source-based distribution, intends users to download the\n> upstream tarballs (we mirror them as well), and verify the digests of\n> the tarballs vs a signed copy of what the digests should be.\n>\n> This has meant some delay at the end of embargoed releases because we\n> have to wait for the official files to be available, then update the\n> build instructions (specifically \"Manifest\" which contains the matching\n> digests), and get that out to users.\n>\n> Fields in of the Gentoo side of the digests:\n> name, size, digests w/ prefix.\n>\n> Example:\n> DIST git-2.31.1.tar.xz 6413368 BLAKE2B ... SHA512 ...\n> DIST git-htmldocs-2.31.1.tar.xz 1357592 BLAKE2B ... SHA512 ...\n> DIST git-manpages-2.31.1.tar.xz 487784 BLAKE2B ... SHA512 ...\n>\n> The minimum set of hash algorithms for this Gentoo code right now is\n> BLAKE2B, which should be easy to script into the announcement mail via:\n> openssl dgst -blake2b512 \"$FILENAME\"\n"},{"id":"422488","messageId":"robbat2-20210420T223619-939869983Z@orbis-terrarum.net","threadId":"55393","inReplyTo":"xmqq5z0g4oc9.fsf@gitster.g","subject":"Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2021-04-20T22:45:32Z","receivedAt":"2021-04-20T22:45:35Z","isPatch":true,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Tue, Apr 20, 2021 at 02:51:02PM -0700, Junio C Hamano wrote:\n> \"Robin H. Johnson\" writes:\n> > As one of the Gentoo maintainer for Git, I was wondering if the\n> > embargoed-releases process could be tweaked slightly.\n> >\n> > Specifically, in the embargo email, could you please publishing the\n> > exact size & digests of the to-be-released tarballs, esp. the htmldocs &\n> > manpages tarballs.\n> \n> HTMLdocs and Manpages are as far as I am concerned part of SOURCES.\n> \n> They are generated from the true sources, I do not give signed tags\n> to them, and as a source-based distribution, Gentoo shouldn't\n> consider them as such, either. When release tags are signed, their\n> sizes or digests are simply unavailable, since they have not even\n> been generated yet (I tag the releases, run make in the tagged\n> release tarball extract and that is what is tarred up as HTMLdocs\n> and or Manpages).\nI didn't say that those tarballs were tagged independently, as your mail\nseems to imply.\n\nAs part of the embargo process, you're sending the tags out already.\nAll 3 tarballs are artifacts derived from those tags, directly or\nindirectly, and you presumably have the same process to generate the\nfinal tarballs if the tags are embargoed or not. I'm just asking that\nthe final tarballs are generated when the tags are, and the sizes &\ndigests of the tarballs are shared in the embargo email.\n\nAlternatively, publish byte-exact reproduction steps from the tags to\nthe tarballs, so that we can generate them locally for co-ordinated\nrelease.\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Dev, Infra Lead, Foundation Treasurer\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\nGnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136\n"},{"id":"422500","messageId":"xmqqwnsw1qk0.fsf@gitster.g","threadId":"55393","inReplyTo":"xmqq5z0g4oc9.fsf@gitster.g","subject":"Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-20T23:31:27Z","receivedAt":"2021-04-20T23:31:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> HTMLdocs and Manpages are as far as I am concerned part of SOURCES.\n\nSorry, NOT part of sources.\n"},{"id":"422501","messageId":"xmqqsg3k1qf2.fsf@gitster.g","threadId":"55393","inReplyTo":"robbat2-20210420T223619-939869983Z@orbis-terrarum.net","subject":"Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-20T23:34:25Z","receivedAt":"2021-04-20T23:34:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robin H. Johnson\" writes:\n\n> Alternatively, publish byte-exact reproduction steps from the tags to\n> the tarballs, so that we can generate them locally for co-ordinated\n> release.\n\nWhat I meant to say was that there is no byte-exact reproduction\nsteps. There is a build procedure but the design goal of the build\nprocedure for the doc tarballs does not include byte-exact\nreproduction at all, as the doc tarballs are not considered as\nsources. It's meant as a mere convenience for those who lack the\nasciidoc(tor) toolchain, a semi-binary distribution.\n\n"}]}