mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 18:21:32 +00:00
shankar0123
b2284ef2a4
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.