From b2284ef2a461f088060808f59d81eb4c54da2c52 Mon Sep 17 00:00:00 2001 From: shankar0123 Date: Thu, 14 May 2026 00:38:48 +0000 Subject: [PATCH] fix(ci): enable compile-generator in SLSA L3 binary provenance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The SLSA reusable workflow generator_generic_slsa3.yml@v2.1.0 has two paths for fetching its generator binary: 1. (Default) download a pre-built binary from a GitHub release of slsa-framework/slsa-github-generator. Releases are identified by TAG NAME (vX.Y.Z), not commit SHA. 2. (compile-generator: true) build the generator from source inside the workflow run, using whatever ref the workflow was pinned to. Phase 1 RED-2 (commit eda3b48, 2026-05-13) SHA-pinned every GitHub Actions `uses:` line including the SLSA reusable workflow: uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@f7dd8c54... # v2.1.0 The SHA pin is correct for supply-chain integrity (no surprise updates via tag moves) but incompatible with the default release-download path, which the workflow proves by hard-erroring at: Fetching the builder with ref: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a Invalid ref: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a. Expected ref of the form refs/tags/vX.Y.Z The fix is the SLSA project's documented escape hatch for SHA-pinned consumers: set `compile-generator: true` in the workflow inputs. This: - Preserves the Phase 1 RED-2 SHA pin (no policy regression) - Builds the generator from the pinned-SHA source (actually MORE secure than downloading a release binary — no separate trust boundary on the release artifact's signing) - Adds ~1 minute to the workflow runtime (acceptable for a release workflow that already takes ~5 min for the SBOM + cosign work) - Documented inline so future contributors don't strip the line thinking it's a stale workaround Visible in the failed Release v2.1.1 workflow run 25834286907 (the `SLSA provenance (binaries) / generator` job, 17s duration, exited on the invalid-ref check before any sigstore network operation). Re-cutting v2.1.1 (or tagging v2.1.2) against this commit should produce a green release pipeline. --- .github/workflows/release.yml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 338ed1e..663a363 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -217,6 +217,19 @@ jobs: base64-subjects: "${{ needs.aggregate-checksums.outputs.hashes }}" upload-assets: true provenance-name: multiple.intoto.jsonl + # Phase 1 RED-2 compat (2026-05-14): the SLSA reusable workflow's + # default path downloads a pre-built generator binary from a + # GitHub *release* of slsa-framework/slsa-github-generator — + # releases are keyed by tag name (vX.Y.Z), and the workflow + # rejects SHA-form refs with "Expected ref of the form + # refs/tags/vX.Y.Z". Phase 1 RED-2 SHA-pinned every Actions + # uses: line, so the default path errors out. Setting + # compile-generator: true instead builds the generator from the + # pinned-SHA source inside the workflow run — preserves + # supply-chain integrity (SHA pin retained), adds ~1 min build + # time. This is the SLSA project's documented escape hatch for + # SHA-pinned reusable-workflow consumers. + compile-generator: true # ---------------------------------------------------------------------- # build-and-push-docker: push container images to GHCR with native