Describe Git's security policy
cover Describe Git's security policy
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
Signature · 1 line
gitgitgadget
PATCH 1/2 SECURITY: describe how to report vulnerabilities
From: Johannes Schindelin <[email protected]>
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.
--- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 SECURITY.md
SECURITY.md new file +51 -0
@@ -0,0 +1,51 @@ +# Security Policy + +## Reporting a vulnerability + +Please send a detailed mail to [email protected] 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 [email protected] (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.
Signature · 1 line
gitgitgadget
Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
Hi Dscho,
Quoted 30 lines · Johannes Schindelin via GitGitGadget
From: Johannes Schindelin <[email protected]>
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 <[email protected]>--- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 SECURITY.mdSECURITY.md new file +12
-0@@ -0,0 +1,51 @@ +# Security Policy + +## Reporting a vulnerability + +Please send a detailed mail to [email protected] 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 [email protected] (and obviously not to discuss the +issue anywhere else). +
SECURITY.md line 22
Quoted 10 lines
SECURITY.md new file +10
-0+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/
Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
Hi Denton,
Quoted 12 lines · Denton Liu
SECURITY.md line 22
Quoted 9 lines · Johannes Schindelin via GitGitGadget
[...]
SECURITY.md new file +7
-0+ +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, forSmall typo: s/sensitiv/&e/
Thanks! Fixed in v2.
Ciao,
Dscho
Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
In reply to Johannes Schindelin via GitGitGadgetQuoted 19 lines · Johannes Schindelin via GitGitGadget
From: Johannes Schindelin <[email protected]>
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 <[email protected]>--- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)create mode 100644 SECURITY.md
SECURITY.md new file +1
-0@@ -0,0 +1,51 @@ +# Security Policy
SECURITY.md line 11
Quoted 10 lines
SECURITY.md new file +10
-0+ +## Reporting a vulnerability + +Please send a detailed mail to [email protected] 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 [email protected] (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)?
SECURITY.md line 23
Quoted 11 lines
SECURITY.md new file +11
-0+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/
SECURITY.md line 29
Quoted 6 lines
SECURITY.md new file +6
-0+- 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.
Quoted 7 lines
SECURITY.md new file +7
-0+ +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
SECURITY.md line 46
Quoted 10 lines
SECURITY.md new file +10
-0+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?
Quoted 5 lines
SECURITY.md new file +4
-0+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.
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Re: [PATCH 1/2] SECURITY: describe how to report vulnerabilities
Hi Bagas,
Quoted 25 lines · Bagas Sanjaya
Quoted 24 lines · Johannes Schindelin via GitGitGadget
From: Johannes Schindelin <[email protected]>
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 <[email protected]>--- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)create mode 100644 SECURITY.md
SECURITY.md new file +6
-0@@ -0,0 +1,51 @@ +# Security Policy + +## Reporting a vulnerability + +Please send a detailed mail to [email protected] to +report vulnerabilities in Git.
Quoted 8 lines
SECURITY.md line 11
Quoted 5 lines
SECURITY.md new file +5
-0+ +Even when unsure whether the bug in question is an exploitable +vulnerability, it is recommended to send the report to [email protected] (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.
Quoted 5 lines
Quoted 5 lines
SECURITY.md new file +5
-0+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:
Quoted 8 lines
SECURITY.md line 23
Quoted 6 lines
SECURITY.md new file +6
-0+ +- 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.
Quoted 9 lines
SECURITY.md line 29
Quoted 6 lines
SECURITY.md new file +6
-0+- 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 VersionsThe 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.
Quoted 15 lines
Quoted 15 lines
SECURITY.md new file +15
-0+ +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
Quoted 8 lines
SECURITY.md line 46
Quoted 2 lines
SECURITY.md new file +2
-0+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).
Quoted 4 lines
SECURITY.md line 51
Quoted 4 lines
SECURITY.md new file +4
-0+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
PATCH 2/2 Document how we do embargoed releases
In reply to Johannes Schindelin via GitGitGadgetFrom: Johannes Schindelin <[email protected]>
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.
--- Documentation/Makefile | 1 + .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++ 2 files changed, 132 insertions(+) create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt
Documentation/Makefile +1 -0
@@ -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)
Documentation/howto/coordinate-embargoed-releases.txt new file +131 -0
131 lines not on this page · raw message
Signature · 1 line
gitgitgadget
v2 cover Describe Git's security policy
In reply to Johannes Schindelin via GitGitGadgetOn 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
Signature · 1 line
gitgitgadget
PATCH v2 1/2 SECURITY: describe how to report vulnerabilities
From: Johannes Schindelin <[email protected]>
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.
--- SECURITY.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 SECURITY.md
SECURITY.md new file +51 -0
@@ -0,0 +1,51 @@ +# Security Policy + +## Reporting a vulnerability + +Please send a detailed mail to [email protected] 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 [email protected] (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.
Signature · 1 line
gitgitgadget
PATCH v2 2/2 Document how we do embargoed releases
In reply to Johannes Schindelin via GitGitGadgetFrom: Johannes Schindelin <[email protected]>
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.
--- Documentation/Makefile | 1 + .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++ 2 files changed, 132 insertions(+) create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt
Documentation/Makefile +1 -0
@@ -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)
Documentation/howto/coordinate-embargoed-releases.txt new file +131 -0
131 lines not on this page · raw message
Signature · 1 line
gitgitgadget
Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
Quoted 7 lines · Johannes Schindelin via GitGitGadget
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.
...
Quoted 2 lines
+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"
Signature · 5 lines
Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : [email protected] GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
Quoted 9 lines · Robin H. Johnson
Quoted 7 lines · Johannes Schindelin via GitGitGadget
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....
Quoted 8 lines
Quoted 2 lines
+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).
Quoted 20 lines
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"
Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
Quoted 10 lines · Junio C Hamano
Quoted 6 lines · Robin H. Johnson
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.
Quoted 7 lines
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.
Signature · 5 lines
Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : [email protected] GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
Quoted 3 lines · Robin H. Johnson
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.
Re: [PATCH v2 2/2] Document how we do embargoed releases - improving mail template
In reply to Junio C HamanoQuoted 1 line · Junio C Hamano
HTMLdocs and Manpages are as far as I am concerned part of SOURCES.
Sorry, NOT part of sources.