| Message ID | 565d7982d870fb1b7644a9777aef6be7ee174dba.1617025385.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 09420b7648eecf681c5393e3690301897397b30d |
| Headers | show |
| Series | Describe Git's security policy | expand |
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 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"
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.
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.
"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.
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> +....