fix(release): sign and attest GitHub release assets directly#201
Conversation
OpenSSF Scorecard's Signed-Releases check only inspects GitHub release assets (matching *.sigstore.json / *.intoto.jsonl suffixes), not OCI registry signatures. The image and chart were already cosign-signed and SLSA-attested in ghcr.io, but Scorecard still flagged every release as unsigned/no-provenance because install.yaml and sbom.spdx.json carried neither. Sign each asset with cosign sign-blob and attest SLSA build provenance directly, uploading both alongside the original asset. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 16 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 (4)
✨ 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 |
publish-helm already runs inside the ci-image container and was installing cosign at runtime via sigstore/cosign-installer just to sign the chart and (per the prior commit) install.yaml. Bake cosign into the ci stage of .devcontainer/Dockerfile instead — same checksum-verified pattern as the other CLI tools there — so that job drops its installer step, and cosign verify/verify-blob become available locally without a separate install. publish-manifest keeps its own cosign-installer: it runs on a bare ubuntu-latest runner, not the ci-image. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sigstore/cosign-installer defaults to cosign v3.0.6 when cosign-release isn't set, which silently diverged from the v3.1.1 baked into the ci-image that publish-helm signs with. Pin it explicitly so both signing jobs in the same release run the same cosign binary. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
1 participant
Summary
Signed-Releasescheck only inspects GitHub release assets (looking for*.sigstore.json/*.intoto.jsonlsiblings), never OCI registry signatures — so it flagged every release as unsigned even though the image and Helm chart are already cosign-signed and SLSA-attested inghcr.io.sbom.spdx.jsonandinstall.yamldirectly withcosign sign-blob --bundle, and attest SLSA build provenance for each viaactions/attest-build-provenance, uploading the resulting<asset>.sigstore.jsonand<asset>.intoto.jsonlfiles as additional release assets.docs/ci-overview.md's release-artifacts table and adds acosign verify-blobexample for verifying a release asset.Test plan
task lint-actions(actionlint) passes on the modifiedrelease.ymlcosign sign-blob --bundle/cosign verify-blob --bundleflag syntax against the pinned cosign versionmainpush / release for the new steps to run successfully inpublish-manifestandpublish-helmSigned-Releasesno longer warns🤖 Generated with Claude Code