From 07e1d7fe163852943cf49d735ca52e2989155825 Mon Sep 17 00:00:00 2001 From: Cohen Robinson Date: Mon, 11 May 2026 00:26:31 +1000 Subject: [PATCH] docs: bake CI hardening into a 2.2.1 release MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cuts a 2.2.1 patch so the in-toto provenance file (PR #28) and the SHA-pinned OSS-Fuzz base image (PR #29) ship in a tagged GitHub Release. Both were ``ci:`` commits that release-please skipped. Practical effect: Scorecard's Signed-Releases check will see the provenance bundle in v2.2.1's release assets and lift from 8/10 to 10/10. No source/behaviour change versus v2.2.0 — the wheel and sdist bytes are identical apart from version metadata. Body change: extend the release-pipeline diagram in CONTRIBUTING.md to mention the new provenance asset. Release-As: 2.2.1 Co-Authored-By: Claude Opus 4.7 (1M context) --- CONTRIBUTING.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 66f5131..00ee840 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -151,7 +151,11 @@ Maintainers do not run `git tag` by hand for normal releases. build → SLSA build provenance attestation → CycloneDX SBOM + attestation → upload artefacts → wait on the `pypi` Environment reviewer → sigstore sign → PyPI Trusted Publishing → GitHub Release - with wheel + sdist + signatures + SBOM attached. + with wheel + sdist + sigstore signatures + SBOM + the in-toto + provenance bundle (`provenance/aemo_mdff_reader.intoto.jsonl`) + attached. The provenance file lets external scanners (Scorecard, + in-toto verifiers) confirm the artefacts were built by this + workflow without a round-trip to the GitHub attestations API. 7. Approve the deployment in the `pypi` Environment when GitHub notifies you. The publish completes; verify at https://pypi.org/project/aemo-mdff-reader/ and