ci: attach .intoto.jsonl provenance bundles as release assets (Scorecard Signed-Releases) - #332
Conversation
…ard Signed-Releases) OpenSSF Scorecard's Signed-Releases check scores 0: it scans release *assets* for signature/provenance files (*.intoto.jsonl, *.sig, …) and never queries the GitHub attestation store, so our releases — genuinely attested since #329 — still read as unsigned, and the unsigned corpus/* releases drag the 5-release window regardless. Ship the existing attestations as assets too: - release.yml: give both attest steps an id and stage each step's bundle-path output — Sigstore-bundle JSON Lines carrying the DSSE-wrapped SLSA-provenance statements — into target/distrib as `ourios-server-<target>.intoto.jsonl` / `ourios-global-artifacts.intoto.jsonl`, added to the uploaded artifact set; the host job's `gh release create artifacts/*` attaches them to the release. Staging runs after attest, so the bundle cannot self-attest (the local attest glob would otherwise match it). - capture-otel-demo-corpus.yml: the publish job (gains attestations/id-token write) now attests the exact assets it releases (logs.jsonl.gz + manifest.md; gzip split into its own step so the .gz exists at attest time) and attaches `otel-demo-corpus.intoto.jsonl` on both the create and re-mint paths — corpus releases are signed in place from their next mint on. - SECURITY.md: document the bundle assets + fully-offline verification (`gh attestation verify … --bundle <file>.intoto.jsonl`). The attestation-store copy stays (online `gh attestation verify`); the asset is the offline/scanner-visible form. Validation caveat: the check can only flip on real releases — the next v0.1.x tag and the next corpus re-mint — followed by Scorecard's next scan; a branch run cannot prove it. Verified: both workflows parse; actionlint reports no new findings (baseline SC2086/SC2129 notes in dist-generated steps only, line-shifted). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 11 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR makes GitHub release provenance more scanner-visible (not just stored in GitHub’s attestation store) by attaching the existing actions/attest Sigstore bundle outputs (*.intoto.jsonl) as release assets. This aligns the project’s release signing posture with OpenSSF Scorecard’s Signed-Releases check behavior, which scans release assets rather than querying the attestation store.
Changes:
- Stage and upload
actions/attestbundle-pathoutputs as*.intoto.jsonlartifacts in the main release workflow (per-target bundles + a global-artifacts bundle). - Add attestation + bundle-asset attachment to the
corpus/*release workflow, attesting the exact assets it publishes. - Document fully-offline verification using
gh attestation verify ... --bundle <file>.intoto.jsonl.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| SECURITY.md | Documents the new *.intoto.jsonl release assets and how to verify assets offline with gh attestation verify --bundle. |
| .github/workflows/release.yml | Adds id to attest steps and copies bundle-path outputs into target/distrib/ so they’re uploaded and attached as release assets. |
| .github/workflows/capture-otel-demo-corpus.yml | Adds permissions and steps to gzip before attesting, then attaches otel-demo-corpus.intoto.jsonl alongside corpus assets on create/update. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
What
The Scorecard
Signed-Releasesfix (PR B of the signing work; follows #329).Scorecard scores Signed-Releases 0 because it scans release assets for
signature/provenance files (
*.intoto.jsonl,*.sig, …) — it never queriesthe GitHub attestation store. Our artifacts are genuinely attested (verified
via
gh attestation verify), but in a form the scanner can't see; and theunsigned
corpus/*releases drag the 5-release scoring window regardless.This ships the existing attestations as release assets too:
id; each step'sbundle-pathoutput (Sigstore-bundle JSON Lines carrying the DSSE-wrapped SLSA-provenance
statements, verification material included) is staged into
target/distribas
ourios-server-<target>.intoto.jsonl/ourios-global-artifacts.intoto.jsonland added to the uploaded set — the host job's
gh release create artifacts/*attaches them. Staging runs after attest, so the bundle can't self-attest
(the local attest glob would otherwise match its own name).
publishjob (gainsattestations/id-tokenwrite; still runs no third-party code — the attestaction is GitHub first-party) attests the exact assets it releases
(
logs.jsonl.gz+manifest.md; gzip split into its own step so the.gzexists at attest time) and attaches
otel-demo-corpus.intoto.jsonlon boththe create and re-mint/clobber paths — corpus releases signed in place
from their next mint, per the maintainer's call.
gh attestation verify <artifact> --repo … --bundle <file>.intoto.jsonl.What this does not change
The attestation-store copies (online
gh attestation verify) and the cosignimage signature are untouched — the asset is an additional, offline/scanner-
visible form of the same Sigstore material. Per the maintainer's decision,
no
cosign sign-blob(.sig) variant.Validation caveat (stated up front)
The check can only flip on real releases: the next
v0.1.xtag and thenext corpus re-mint, followed by Scorecard's next scan. A branch run cannot
prove it —
pr-run-modeisplan, so the build/attest jobs don't execute onPRs (see the #329 discussion). Also, older unsigned releases (
v0.1.0,existing
corpus/*) stay as they are until they age out of Scorecard's5-release window or the corpus tags re-mint.
Verification
actionlintreports no new findings(the SC2086/SC2129 notes are pre-existing in dist-generated steps,
line-shifted).
actions/attest'sbundle-pathoutput confirmed against the pinned SHA'saction.yml.🤖 Generated with Claude Code