git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [PATCH 0/2] Describe Git's security policy
@ 2021-03-26 22:12 Johannes Schindelin via GitGitGadget
  2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-26 22:12 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin

On GitHub, SECURITY.md files are the recommended way to describe how to
report vulnerabilities, and to set expectations how far back maintenance
tracks are updated with security bug fixes.

For example, when navigating to https://github.com/git/git/security/ users
would be guided to that SECURITY.md file. If it exists.

The purpose of this patch series is to add this file, describing Git's
security policy.

While at it, I also want to document the process how to coordinate the
ensuing embargoed releases. This is what the second patch is all about.

The reason for that is quite selfish, as I did two of them, and while I am
happy that such embargoed releases do not happen all that often, the
downside is that I keep forgetting all the details. So this document is not
only meant for knowledge sharing, but in particular to help me the next
time(s) I coordinate an embargoed release.

Many thanks to Junio who reviewed the first draft of this patch series
(where I had not yet separated out
Documentation/howto/coordinate-embargoed-releases.txt).

Johannes Schindelin (2):
  SECURITY: describe how to report vulnerabilities
  Document how we do embargoed releases

 Documentation/Makefile                        |   1 +
 .../howto/coordinate-embargoed-releases.txt   | 131 ++++++++++++++++++
 SECURITY.md                                   |  51 +++++++
 3 files changed, 183 insertions(+)
 create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt
 create mode 100644 SECURITY.md


base-commit: e6362826a0409539642a5738db61827e5978e2e4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-917%2Fdscho%2Fsecurity-policy-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-917/dscho/security-policy-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/917
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
@ 2021-03-26 22:12 ` Johannes Schindelin via GitGitGadget
  2021-03-27  0:00   ` Denton Liu
  2021-03-27  6:34   ` Bagas Sanjaya
  2021-03-26 22:12 ` [PATCH 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
  2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
  2 siblings, 2 replies; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-26 22:12 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In the same document, describe that Git does not have Long Term Support
(LTS) release trains, although security fixes are always applied to a
few of the most recent release trains.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000000000000..282790164e78
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,51 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Please send a detailed mail to git-security@googlegroups.com to
+report vulnerabilities in Git.
+
+Even when unsure whether the bug in question is an exploitable
+vulnerability, it is recommended to send the report to
+git-security@googlegroups.com (and obviously not to discuss the
+issue anywhere else).
+
+Vulnerabilities are expected to be discussed _only_ on that
+list, and not in public, until the official announcement on the
+Git mailing list on the release date.
+
+Examples for details to include:
+
+- Ideally a short description (or a script) to demonstrate an
+  exploit.
+- The affected platforms and scenarios (the vulnerability might
+  only affect setups with case-sensitiv file systems, for
+  example).
+- The name and affiliation of the security researchers who are
+  involved in the discovery, if any.
+- Whether the vulnerability has already been disclosed.
+- How long an embargo would be required to be safe.
+
+## Supported Versions
+
+There are no official "Long Term Support" versions in Git.
+Instead, the maintenance track (i.e. the versions based on the
+most recently published feature release, also known as ".0"
+version) sees occasional updates with bug fixes.
+
+Fixes to vulnerabilities are made for the maintenance track for
+the latest feature release and merged up to the in-development
+branches. The Git project makes no formal guarantee for any
+older maintenance tracks to receive updates. In practice,
+though, critical vulnerability fixes are applied not only to the
+most recent track, but to at least a couple more maintenance
+tracks.
+
+This is typically done by making the fix on the oldest and still
+relevant maintenance track, and merging it upwards to newer and
+newer maintenance tracks.
+
+For example, v2.24.1 was released to address a couple of
+[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,
+v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
+v2.22.2 and v2.23.1 were released.
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 2/2] Document how we do embargoed releases
  2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
  2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
@ 2021-03-26 22:12 ` Johannes Schindelin via GitGitGadget
  2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
  2 siblings, 0 replies; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-26 22:12 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Whenever we fix critical vulnerabilities, we follow some sort of
protocol (e.g. setting a coordinated release date, keeping the fix under
embargo until that time, coordinating with packagers and/or hosting
sites, etc).

Similar in spirit to `Documentation/howto/maintain-git.txt`, let's
formalize the details in a document.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/Makefile                        |   1 +
 .../howto/coordinate-embargoed-releases.txt   | 131 ++++++++++++++++++
 2 files changed, 132 insertions(+)
 create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 81d1bf7a049b..874a01d7a86e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -76,6 +76,7 @@ SP_ARTICLES += howto/rebuild-from-update-hook
 SP_ARTICLES += howto/rebase-from-internal-branch
 SP_ARTICLES += howto/keep-canonical-history-correct
 SP_ARTICLES += howto/maintain-git
+SP_ARTICLES += howto/coordinate-embargoed-releases
 API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
 SP_ARTICLES += $(API_DOCS)
 
diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt
new file mode 100644
index 000000000000..601aae88e9a3
--- /dev/null
+++ b/Documentation/howto/coordinate-embargoed-releases.txt
@@ -0,0 +1,131 @@
+Content-type: text/asciidoc
+Abstract: When a critical vulnerability is discovered and fixed, we follow this
+ script to coordinate a public release.
+
+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
+------------------------------
+
+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.
+
+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.
+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].
+
+Once the version has been published, we send a note about that to oss-security.
+As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the
+v2.24.1 mail];
+https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are
+their guidelines.
+
+The mail to oss-security should also describe the exploit, and give credit to
+the reporter(s): security researchers still receive too little respect for the
+invaluable service they provide, and public credit goes a long way to keep them
+paid by their respective organizations.
+
+Technically, describing any exploit can be delayed up to 7 days, but we usually
+refrain from doing that, including it right away.
+
+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
+will drop `.bundle` attachments) in the mail to distros@ so that the involved
+parties can take care of integrating/backporting them. This bundle is typically
+created using a command like this:
+
+	git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
+	tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
+
+Example mail to distros@vs.openwall.org
+---------------------------------------
+
+....
+To: distros@vs.openwall.org
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: [vs] Upcoming Git security fix release
+
+Team,
+
+The Git project will release new versions on <date> at 10am Pacific Time or
+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
+it being dropped) which you can fetch into a clone of
+https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
+containing the tags for versions <versions>.
+
+You can verify with `git tag -v <tag>` that the versions were signed by
+the Git maintainer, using the same GPG key as e.g. v2.24.0.
+
+Please use these tags to prepare `git` packages for your various
+distributions, using the appropriate tagged versions. The added test cases
+help verify the correctness.
+
+The addressed issues are:
+
+<list of CVEs with a short description, typically copy/pasted from Git's
+release notes, usually demo exploit(s), too>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+
+....
+
+Example mail to oss-security@lists.openwall.com
+-----------------------------------------------
+
+....
+To: oss-security@lists.openwall.com
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: git: <copy from security advisory>
+
+Team,
+
+The Git project released new versions on <date>, addressing <CVE>.
+
+All supported platforms are affected in one way or another, and all Git
+versions all the way back to <version> are affected. The fixed versions are:
+<versions>.
+
+Link to the announcement: <link to lore.kernel.org/git>
+
+We highly recommend to upgrade.
+
+The addressed issues are:
+* <list of CVEs and their explanations, along with demo exploits>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+....
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
@ 2021-03-27  0:00   ` Denton Liu
  2021-03-29 13:37     ` Johannes Schindelin
  2021-03-27  6:34   ` Bagas Sanjaya
  1 sibling, 1 reply; 15+ messages in thread
From: Denton Liu @ 2021-03-27  0:00 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin

Hi Dscho,

On Fri, Mar 26, 2021 at 10:12:45PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> In the same document, describe that Git does not have Long Term Support
> (LTS) release trains, although security fixes are always applied to a
> few of the most recent release trains.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 SECURITY.md
> 
> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 000000000000..282790164e78
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,51 @@
> +# Security Policy
> +
> +## Reporting a vulnerability
> +
> +Please send a detailed mail to git-security@googlegroups.com to
> +report vulnerabilities in Git.
> +
> +Even when unsure whether the bug in question is an exploitable
> +vulnerability, it is recommended to send the report to
> +git-security@googlegroups.com (and obviously not to discuss the
> +issue anywhere else).
> +
> +Vulnerabilities are expected to be discussed _only_ on that
> +list, and not in public, until the official announcement on the
> +Git mailing list on the release date.
> +
> +Examples for details to include:
> +
> +- Ideally a short description (or a script) to demonstrate an
> +  exploit.
> +- The affected platforms and scenarios (the vulnerability might
> +  only affect setups with case-sensitiv file systems, for

Small typo: s/sensitiv/&e/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
  2021-03-27  0:00   ` Denton Liu
@ 2021-03-27  6:34   ` Bagas Sanjaya
  2021-03-29 13:41     ` Johannes Schindelin
  1 sibling, 1 reply; 15+ messages in thread
From: Bagas Sanjaya @ 2021-03-27  6:34 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget; +Cc: Johannes Schindelin, git

On 27/03/21 05.12, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> In the same document, describe that Git does not have Long Term Support
> (LTS) release trains, although security fixes are always applied to a
> few of the most recent release trains.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>   SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 51 insertions(+)
>   create mode 100644 SECURITY.md
> 
> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 000000000000..282790164e78
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,51 @@
> +# Security Policy
> +
> +## Reporting a vulnerability
> +
> +Please send a detailed mail to git-security@googlegroups.com to
> +report vulnerabilities in Git.
> +
> +Even when unsure whether the bug in question is an exploitable
> +vulnerability, it is recommended to send the report to
> +git-security@googlegroups.com (and obviously not to discuss the
> +issue anywhere else).
What about using reference word (`... it is recommended to send the
report to that mailing list`)?
> +Vulnerabilities are expected to be discussed _only_ on that
> +list, and not in public, until the official announcement on the
> +Git mailing list on the release date.
> +
> +Examples for details to include:
> +
> +- Ideally a short description (or a script) to demonstrate an
> +  exploit.
> +- The affected platforms and scenarios (the vulnerability might
> +  only affect setups with case-sensitiv file systems, for
> +  example).
Oops, s/case-sensitiv/case-sensitive/
> +- The name and affiliation of the security researchers who are
> +  involved in the discovery, if any.
> +- Whether the vulnerability has already been disclosed.
> +- How long an embargo would be required to be safe.
> +
> +## Supported Versions
The header should be `Supported Versions and How Maintenance
Releases are Made`.
> +
> +There are no official "Long Term Support" versions in Git.
> +Instead, the maintenance track (i.e. the versions based on the
> +most recently published feature release, also known as ".0"
> +version) sees occasional updates with bug fixes.
> +
> +Fixes to vulnerabilities are made for the maintenance track for
> +the latest feature release and merged up to the in-development
> +branches. The Git project makes no formal guarantee for any
> +older maintenance tracks to receive updates. In practice,
> +though, critical vulnerability fixes are applied not only to the
> +most recent track, but to at least a couple more maintenance
> +tracks.
> +
> +This is typically done by making the fix on the oldest and still
> +relevant maintenance track, and merging it upwards to newer and
> +newer maintenance tracks.
AFAIK, maint branch are based on latest feature release (say v2.24),
and any bugfixes there are cherry-picked to relevant older releases,
but does it mean resetting maint branch to that older release, and
then resetting back to before that? Or how tagged maintenance release
are made without resetting maint?
> +For example, v2.24.1 was released to address a couple of
> +[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,
> +v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
> +v2.22.2 and v2.23.1 were released.
> 

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-27  0:00   ` Denton Liu
@ 2021-03-29 13:37     ` Johannes Schindelin
  0 siblings, 0 replies; 15+ messages in thread
From: Johannes Schindelin @ 2021-03-29 13:37 UTC (permalink / raw)
  To: Denton Liu; +Cc: Johannes Schindelin via GitGitGadget, git

Hi Denton,

On Fri, 26 Mar 2021, Denton Liu wrote:

> On Fri, Mar 26, 2021 at 10:12:45PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > [...]
> >
> > +
> > +Examples for details to include:
> > +
> > +- Ideally a short description (or a script) to demonstrate an
> > +  exploit.
> > +- The affected platforms and scenarios (the vulnerability might
> > +  only affect setups with case-sensitiv file systems, for
>
> Small typo: s/sensitiv/&e/

Thanks! Fixed in v2.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-27  6:34   ` Bagas Sanjaya
@ 2021-03-29 13:41     ` Johannes Schindelin
  0 siblings, 0 replies; 15+ messages in thread
From: Johannes Schindelin @ 2021-03-29 13:41 UTC (permalink / raw)
  To: Bagas Sanjaya; +Cc: Johannes Schindelin via GitGitGadget, git

Hi Bagas,

On Sat, 27 Mar 2021, Bagas Sanjaya wrote:

> On 27/03/21 05.12, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > In the same document, describe that Git does not have Long Term Support
> > (LTS) release trains, although security fixes are always applied to a
> > few of the most recent release trains.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >   SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 51 insertions(+)
> >   create mode 100644 SECURITY.md
> >
> > diff --git a/SECURITY.md b/SECURITY.md
> > new file mode 100644
> > index 000000000000..282790164e78
> > --- /dev/null
> > +++ b/SECURITY.md
> > @@ -0,0 +1,51 @@
> > +# Security Policy
> > +
> > +## Reporting a vulnerability
> > +
> > +Please send a detailed mail to git-security@googlegroups.com to
> > +report vulnerabilities in Git.
> > +
> > +Even when unsure whether the bug in question is an exploitable
> > +vulnerability, it is recommended to send the report to
> > +git-security@googlegroups.com (and obviously not to discuss the
> > +issue anywhere else).
>
> What about using reference word (`... it is recommended to send the
> report to that mailing list`)?

I would really like to repeat the email address here, to make really
certain that the reader uses the correct one.

> > +Vulnerabilities are expected to be discussed _only_ on that
> > +list, and not in public, until the official announcement on the
> > +Git mailing list on the release date.
> > +
> > +Examples for details to include:
> > +
> > +- Ideally a short description (or a script) to demonstrate an
> > +  exploit.
> > +- The affected platforms and scenarios (the vulnerability might
> > +  only affect setups with case-sensitiv file systems, for
> > +  example).
>
> Oops, s/case-sensitiv/case-sensitive/

Yes, thanks, it will be fixed in v2.

> > +- The name and affiliation of the security researchers who are
> > +  involved in the discovery, if any.
> > +- Whether the vulnerability has already been disclosed.
> > +- How long an embargo would be required to be safe.
> > +
> > +## Supported Versions
>
> The header should be `Supported Versions and How Maintenance
> Releases are Made`.

Not really. The maintenance is described in
Documentation/howto/maintain-git.txt. It is not the purpose of
`SECURITY.md` to document that, it just so happens that we hint a bit at
it while talking about which branches get security updates.

> > +
> > +There are no official "Long Term Support" versions in Git.
> > +Instead, the maintenance track (i.e. the versions based on the
> > +most recently published feature release, also known as ".0"
> > +version) sees occasional updates with bug fixes.
> > +
> > +Fixes to vulnerabilities are made for the maintenance track for
> > +the latest feature release and merged up to the in-development
> > +branches. The Git project makes no formal guarantee for any
> > +older maintenance tracks to receive updates. In practice,
> > +though, critical vulnerability fixes are applied not only to the
> > +most recent track, but to at least a couple more maintenance
> > +tracks.
> > +
> > +This is typically done by making the fix on the oldest and still
> > +relevant maintenance track, and merging it upwards to newer and
> > +newer maintenance tracks.
>
> AFAIK, maint branch are based on latest feature release (say v2.24),
> and any bugfixes there are cherry-picked to relevant older releases,
> but does it mean resetting maint branch to that older release, and
> then resetting back to before that? Or how tagged maintenance release
> are made without resetting maint?

There are `maint-<maintenance-track>` branches, e.g. `maint-2.30`,
`maint-2.29`, etc.

But it really is not even interesting in the context of security updates
how those maintenance branches are called, it is only interesting which
versions will receive updates (and the updates come in the form of a
newly-tagged version, not in the form of an updated `maint-<track>`
branch; The latter just _happens_ to also happen, for maintenance
reasons).

> > +For example, v2.24.1 was released to address a couple of
> > +[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,
> > +v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
> > +v2.22.2 and v2.23.1 were released.

Thank you for your review!
Johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v2 0/2] Describe Git's security policy
  2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
  2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
  2021-03-26 22:12 ` [PATCH 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
@ 2021-03-29 13:43 ` Johannes Schindelin via GitGitGadget
  2021-03-29 13:43   ` [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
  2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
  2 siblings, 2 replies; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-29 13:43 UTC (permalink / raw)
  To: git; +Cc: Denton Liu, Bagas Sanjaya, Johannes Schindelin

On GitHub, SECURITY.md files are the recommended way to describe how to
report vulnerabilities, and to set expectations how far back maintenance
tracks are updated with security bug fixes.

For example, when navigating to https://github.com/git/git/security/ users
would be guided to that SECURITY.md file. If it exists.

The purpose of this patch series is to add this file, describing Git's
security policy.

While at it, I also want to document the process how to coordinate the
ensuing embargoed releases. This is what the second patch is all about.

The reason for that is quite selfish, as I did two of them, and while I am
happy that such embargoed releases do not happen all that often, the
downside is that I keep forgetting all the details. So this document is not
only meant for knowledge sharing, but in particular to help me the next
time(s) I coordinate an embargoed release.

Many thanks to Junio who reviewed the first draft of this patch series
(where I had not yet separated out
Documentation/howto/coordinate-embargoed-releases.txt).

Changes since v1:

 * Fixed typo

Johannes Schindelin (2):
  SECURITY: describe how to report vulnerabilities
  Document how we do embargoed releases

 Documentation/Makefile                        |   1 +
 .../howto/coordinate-embargoed-releases.txt   | 131 ++++++++++++++++++
 SECURITY.md                                   |  51 +++++++
 3 files changed, 183 insertions(+)
 create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt
 create mode 100644 SECURITY.md


base-commit: e6362826a0409539642a5738db61827e5978e2e4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-917%2Fdscho%2Fsecurity-policy-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-917/dscho/security-policy-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/917

Range-diff vs v1:

 1:  2c9f5725d96f ! 1:  3f5d866de195 SECURITY: describe how to report vulnerabilities
     @@ SECURITY.md (new)
      +- Ideally a short description (or a script) to demonstrate an
      +  exploit.
      +- The affected platforms and scenarios (the vulnerability might
     -+  only affect setups with case-sensitiv file systems, for
     ++  only affect setups with case-sensitive file systems, for
      +  example).
      +- The name and affiliation of the security researchers who are
      +  involved in the discovery, if any.
 2:  41efaaf62864 = 2:  565d7982d870 Document how we do embargoed releases

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities
  2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
@ 2021-03-29 13:43   ` Johannes Schindelin via GitGitGadget
  2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
  1 sibling, 0 replies; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-29 13:43 UTC (permalink / raw)
  To: git; +Cc: Denton Liu, Bagas Sanjaya, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In the same document, describe that Git does not have Long Term Support
(LTS) release trains, although security fixes are always applied to a
few of the most recent release trains.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000000000000..c720c2ae7f95
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,51 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Please send a detailed mail to git-security@googlegroups.com to
+report vulnerabilities in Git.
+
+Even when unsure whether the bug in question is an exploitable
+vulnerability, it is recommended to send the report to
+git-security@googlegroups.com (and obviously not to discuss the
+issue anywhere else).
+
+Vulnerabilities are expected to be discussed _only_ on that
+list, and not in public, until the official announcement on the
+Git mailing list on the release date.
+
+Examples for details to include:
+
+- Ideally a short description (or a script) to demonstrate an
+  exploit.
+- The affected platforms and scenarios (the vulnerability might
+  only affect setups with case-sensitive file systems, for
+  example).
+- The name and affiliation of the security researchers who are
+  involved in the discovery, if any.
+- Whether the vulnerability has already been disclosed.
+- How long an embargo would be required to be safe.
+
+## Supported Versions
+
+There are no official "Long Term Support" versions in Git.
+Instead, the maintenance track (i.e. the versions based on the
+most recently published feature release, also known as ".0"
+version) sees occasional updates with bug fixes.
+
+Fixes to vulnerabilities are made for the maintenance track for
+the latest feature release and merged up to the in-development
+branches. The Git project makes no formal guarantee for any
+older maintenance tracks to receive updates. In practice,
+though, critical vulnerability fixes are applied not only to the
+most recent track, but to at least a couple more maintenance
+tracks.
+
+This is typically done by making the fix on the oldest and still
+relevant maintenance track, and merging it upwards to newer and
+newer maintenance tracks.
+
+For example, v2.24.1 was released to address a couple of
+[CVEs](https://cve.mitre.org/), and at the same time v2.14.6,
+v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
+v2.22.2 and v2.23.1 were released.
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v2 2/2] Document how we do embargoed releases
  2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
  2021-03-29 13:43   ` [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
@ 2021-03-29 13:43   ` Johannes Schindelin via GitGitGadget
  2021-04-20 19:50     ` [PATCH v2 2/2] Document how we do embargoed releases - improving mail template Robin H. Johnson
  1 sibling, 1 reply; 15+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2021-03-29 13:43 UTC (permalink / raw)
  To: git; +Cc: Denton Liu, Bagas Sanjaya, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Whenever we fix critical vulnerabilities, we follow some sort of
protocol (e.g. setting a coordinated release date, keeping the fix under
embargo until that time, coordinating with packagers and/or hosting
sites, etc).

Similar in spirit to `Documentation/howto/maintain-git.txt`, let's
formalize the details in a document.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/Makefile                        |   1 +
 .../howto/coordinate-embargoed-releases.txt   | 131 ++++++++++++++++++
 2 files changed, 132 insertions(+)
 create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 81d1bf7a049b..874a01d7a86e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -76,6 +76,7 @@ SP_ARTICLES += howto/rebuild-from-update-hook
 SP_ARTICLES += howto/rebase-from-internal-branch
 SP_ARTICLES += howto/keep-canonical-history-correct
 SP_ARTICLES += howto/maintain-git
+SP_ARTICLES += howto/coordinate-embargoed-releases
 API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
 SP_ARTICLES += $(API_DOCS)
 
diff --git a/Documentation/howto/coordinate-embargoed-releases.txt b/Documentation/howto/coordinate-embargoed-releases.txt
new file mode 100644
index 000000000000..601aae88e9a3
--- /dev/null
+++ b/Documentation/howto/coordinate-embargoed-releases.txt
@@ -0,0 +1,131 @@
+Content-type: text/asciidoc
+Abstract: When a critical vulnerability is discovered and fixed, we follow this
+ script to coordinate a public release.
+
+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
+------------------------------
+
+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.
+
+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.
+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].
+
+Once the version has been published, we send a note about that to oss-security.
+As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the
+v2.24.1 mail];
+https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are
+their guidelines.
+
+The mail to oss-security should also describe the exploit, and give credit to
+the reporter(s): security researchers still receive too little respect for the
+invaluable service they provide, and public credit goes a long way to keep them
+paid by their respective organizations.
+
+Technically, describing any exploit can be delayed up to 7 days, but we usually
+refrain from doing that, including it right away.
+
+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
+will drop `.bundle` attachments) in the mail to distros@ so that the involved
+parties can take care of integrating/backporting them. This bundle is typically
+created using a command like this:
+
+	git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
+	tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
+
+Example mail to distros@vs.openwall.org
+---------------------------------------
+
+....
+To: distros@vs.openwall.org
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: [vs] Upcoming Git security fix release
+
+Team,
+
+The Git project will release new versions on <date> at 10am Pacific Time or
+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
+it being dropped) which you can fetch into a clone of
+https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
+containing the tags for versions <versions>.
+
+You can verify with `git tag -v <tag>` that the versions were signed by
+the Git maintainer, using the same GPG key as e.g. v2.24.0.
+
+Please use these tags to prepare `git` packages for your various
+distributions, using the appropriate tagged versions. The added test cases
+help verify the correctness.
+
+The addressed issues are:
+
+<list of CVEs with a short description, typically copy/pasted from Git's
+release notes, usually demo exploit(s), too>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+
+....
+
+Example mail to oss-security@lists.openwall.com
+-----------------------------------------------
+
+....
+To: oss-security@lists.openwall.com
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: git: <copy from security advisory>
+
+Team,
+
+The Git project released new versions on <date>, addressing <CVE>.
+
+All supported platforms are affected in one way or another, and all Git
+versions all the way back to <version> are affected. The fixed versions are:
+<versions>.
+
+Link to the announcement: <link to lore.kernel.org/git>
+
+We highly recommend to upgrade.
+
+The addressed issues are:
+* <list of CVEs and their explanations, along with demo exploits>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+....
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
  2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
@ 2021-04-20 19:50     ` Robin H. Johnson
  2021-04-20 21:51       ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: Robin H. Johnson @ 2021-04-20 19:50 UTC (permalink / raw)
  To: Git Mailing List

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

On Mon, Mar 29, 2021 at 01:43:04PM +0000, Johannes Schindelin via GitGitGadget wrote:
> Whenever we fix critical vulnerabilities, we follow some sort of
> protocol (e.g. setting a coordinated release date, keeping the fix under
> embargo until that time, coordinating with packagers and/or hosting
> sites, etc).
> 
> Similar in spirit to `Documentation/howto/maintain-git.txt`, let's
> formalize the details in a document.
...
> +Notifying the Linux distributions
> +---------------------------------
As one of the Gentoo maintainer for Git, I was wondering if the
embargoed-releases process could be tweaked slightly.

Specifically, in the embargo email, could you please publishing the
exact size & digests of the to-be-released tarballs, esp. the htmldocs &
manpages tarballs.

Gentoo, as a source-based distribution, intends users to download the
upstream tarballs (we mirror them as well), and verify the digests of
the tarballs vs a signed copy of what the digests should be.

This has meant some delay at the end of embargoed releases because we
have to wait for the official files to be available, then update the
build instructions (specifically "Manifest" which contains the matching
digests), and get that out to users.

Fields in of the Gentoo side of the digests:
name, size, digests w/ prefix.

Example:
DIST git-2.31.1.tar.xz 6413368 BLAKE2B ...  SHA512 ...
DIST git-htmldocs-2.31.1.tar.xz 1357592 BLAKE2B ...  SHA512 ...
DIST git-manpages-2.31.1.tar.xz 487784 BLAKE2B ...  SHA512 ...

The minimum set of hash algorithms for this Gentoo code right now is
BLAKE2B, which should be easy to script into the announcement mail via:
openssl dgst -blake2b512 "$FILENAME"

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
  2021-04-20 19:50     ` [PATCH v2 2/2] Document how we do embargoed releases - improving mail template Robin H. Johnson
@ 2021-04-20 21:51       ` Junio C Hamano
  2021-04-20 22:45         ` Robin H. Johnson
  2021-04-20 23:31         ` Junio C Hamano
  0 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-04-20 21:51 UTC (permalink / raw)
  To: Robin H. Johnson; +Cc: Git Mailing List

"Robin H. Johnson" <robbat2@gentoo.org> writes:

> On Mon, Mar 29, 2021 at 01:43:04PM +0000, Johannes Schindelin via GitGitGadget wrote:
>> Whenever we fix critical vulnerabilities, we follow some sort of
>> protocol (e.g. setting a coordinated release date, keeping the fix under
>> embargo until that time, coordinating with packagers and/or hosting
>> sites, etc).
>> 
>> Similar in spirit to `Documentation/howto/maintain-git.txt`, let's
>> formalize the details in a document.
> ...
>> +Notifying the Linux distributions
>> +---------------------------------
> As one of the Gentoo maintainer for Git, I was wondering if the
> embargoed-releases process could be tweaked slightly.
>
> Specifically, in the embargo email, could you please publishing the
> exact size & digests of the to-be-released tarballs, esp. the htmldocs &
> manpages tarballs.

HTMLdocs and Manpages are as far as I am concerned part of SOURCES.

They are generated from the true sources, I do not give signed tags
to them, and as a source-based distribution, Gentoo shouldn't
consider them as such, either.  When release tags are signed, their
sizes or digests are simply unavailable, since they have not even
been generated yet (I tag the releases, run make in the tagged
release tarball extract and that is what is tarred up as HTMLdocs
and or Manpages).


> Gentoo, as a source-based distribution, intends users to download the
> upstream tarballs (we mirror them as well), and verify the digests of
> the tarballs vs a signed copy of what the digests should be.
>
> This has meant some delay at the end of embargoed releases because we
> have to wait for the official files to be available, then update the
> build instructions (specifically "Manifest" which contains the matching
> digests), and get that out to users.
>
> Fields in of the Gentoo side of the digests:
> name, size, digests w/ prefix.
>
> Example:
> DIST git-2.31.1.tar.xz 6413368 BLAKE2B ...  SHA512 ...
> DIST git-htmldocs-2.31.1.tar.xz 1357592 BLAKE2B ...  SHA512 ...
> DIST git-manpages-2.31.1.tar.xz 487784 BLAKE2B ...  SHA512 ...
>
> The minimum set of hash algorithms for this Gentoo code right now is
> BLAKE2B, which should be easy to script into the announcement mail via:
> openssl dgst -blake2b512 "$FILENAME"

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
  2021-04-20 21:51       ` Junio C Hamano
@ 2021-04-20 22:45         ` Robin H. Johnson
  2021-04-20 23:34           ` Junio C Hamano
  2021-04-20 23:31         ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Robin H. Johnson @ 2021-04-20 22:45 UTC (permalink / raw)
  To: Git Mailing List

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On Tue, Apr 20, 2021 at 02:51:02PM -0700, Junio C Hamano wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> writes:
> > As one of the Gentoo maintainer for Git, I was wondering if the
> > embargoed-releases process could be tweaked slightly.
> >
> > Specifically, in the embargo email, could you please publishing the
> > exact size & digests of the to-be-released tarballs, esp. the htmldocs &
> > manpages tarballs.
> 
> HTMLdocs and Manpages are as far as I am concerned part of SOURCES.
> 
> They are generated from the true sources, I do not give signed tags
> to them, and as a source-based distribution, Gentoo shouldn't
> consider them as such, either.  When release tags are signed, their
> sizes or digests are simply unavailable, since they have not even
> been generated yet (I tag the releases, run make in the tagged
> release tarball extract and that is what is tarred up as HTMLdocs
> and or Manpages).
I didn't say that those tarballs were tagged independently, as your mail
seems to imply.

As part of the embargo process, you're sending the tags out already.
All 3 tarballs are artifacts derived from those tags, directly or
indirectly, and you presumably have the same process to generate the
final tarballs if the tags are embargoed or not. I'm just asking that
the final tarballs are generated when the tags are, and the sizes &
digests of the tarballs are shared in the embargo email.

Alternatively, publish byte-exact reproduction steps from the tags to
the tarballs, so that we can generate them locally for co-ordinated
release.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
  2021-04-20 21:51       ` Junio C Hamano
  2021-04-20 22:45         ` Robin H. Johnson
@ 2021-04-20 23:31         ` Junio C Hamano
  1 sibling, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-04-20 23:31 UTC (permalink / raw)
  To: Robin H. Johnson; +Cc: Git Mailing List

Junio C Hamano <gitster@pobox.com> writes:

> HTMLdocs and Manpages are as far as I am concerned part of SOURCES.

Sorry, NOT part of sources.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
  2021-04-20 22:45         ` Robin H. Johnson
@ 2021-04-20 23:34           ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-04-20 23:34 UTC (permalink / raw)
  To: Robin H. Johnson; +Cc: Git Mailing List

"Robin H. Johnson" <robbat2@gentoo.org> writes:

> Alternatively, publish byte-exact reproduction steps from the tags to
> the tarballs, so that we can generate them locally for co-ordinated
> release.

What I meant to say was that there is no byte-exact reproduction
steps.  There is a build procedure but the design goal of the build
procedure for the doc tarballs does not include byte-exact
reproduction at all, as the doc tarballs are not considered as
sources.  It's meant as a mere convenience for those who lack the
asciidoc(tor) toolchain, a semi-binary distribution.


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-04-20 23:34 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-26 22:12 [PATCH 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-26 22:12 ` [PATCH 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-27  0:00   ` Denton Liu
2021-03-29 13:37     ` Johannes Schindelin
2021-03-27  6:34   ` Bagas Sanjaya
2021-03-29 13:41     ` Johannes Schindelin
2021-03-26 22:12 ` [PATCH 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
2021-03-29 13:43 ` [PATCH v2 0/2] Describe Git's security policy Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 1/2] SECURITY: describe how to report vulnerabilities Johannes Schindelin via GitGitGadget
2021-03-29 13:43   ` [PATCH v2 2/2] Document how we do embargoed releases Johannes Schindelin via GitGitGadget
2021-04-20 19:50     ` [PATCH v2 2/2] Document how we do embargoed releases - improving mail template Robin H. Johnson
2021-04-20 21:51       ` Junio C Hamano
2021-04-20 22:45         ` Robin H. Johnson
2021-04-20 23:34           ` Junio C Hamano
2021-04-20 23:31         ` Junio C Hamano

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).