gsadmin/certctl
1
0
Fork 0
mirror of https://github.com/shankar0123/certctl.git synced 2026-06-07 13:51:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(ci): enable compile-generator in SLSA L3 binary provenance

Browse Source 
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.
This commit is contained in:
shankar0123
2026-05-14 00:38:48 +00:00
parent 09c29b9f40
commit b2284ef2a4
1 changed files with 13 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/release.yml
+13
View File
@@ -217,6 +217,19 @@ jobs:
base64-subjects: "${{ needs.aggregate-checksums.outputs.hashes }}" base64-subjects: "${{ needs.aggregate-checksums.outputs.hashes }}"
upload-assets: true upload-assets: true
provenance-name: multiple.intoto.jsonl 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 # build-and-push-docker: push container images to GHCR with native