release: v0.3.0-beta.4 - #171
Conversation
GSTACK-Checkpoint: 2026-07-14/e9-hub-oci-publication#1 Signed-off-by: Gnani Rahul <gnani.nutakki@gmail.com>
…i-publication feat(e9): publish signed hub OCI image
📝 WalkthroughWalkthroughThe release workflow now publishes a signed, immutable amd64/arm64 hub image with provenance and SPDX SBOM attestations. Release checks verify OCI platforms, policy tests validate workflow and documentation contracts, and release guides require digest-based image verification. ChangesHub image release
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseTag
participant GitHubActions
participant GHCR
participant Cosign
participant GitHubAttestations
participant GitHubRelease
ReleaseTag->>GitHubActions: start release workflow
GitHubActions->>GHCR: push amd64/arm64 hub manifest
GitHubActions->>Cosign: sign and verify manifest digest
GitHubActions->>GitHubAttestations: publish provenance and SBOM attestations
GitHubActions->>GitHubRelease: upload digest and attestation bundles
Possibly related issues
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
127-154: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low valueGuard-then-push has a residual TOCTOU window, and GHCR offers no native immutable-tag backstop.
docker manifest inspectand the subsequent push are two separate network calls; nothing prevents a concurrent/duplicate run for the same tag from racing between them. Since GHCR does not support registry-level immutable tags (unlike Docker Hub/Quay/Harbor), this shell-level guard is the sole enforcement mechanism. Additionally, if the workflow fails after the image is pushed but before signing/attestation completes (e.g., a transientcosign/syftfailure), re-running the same tag will trip this guard ("hub image tag already exists") and block a legitimate recovery — the operator would need to manually delete the GHCR package version or cut a new tag.This is likely an accepted trade-off for immutability, but worth calling out explicitly as an operational risk (recovery path after partial failure) rather than a functional bug.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 127 - 154, Document the accepted operational risk in the release workflow around “Guard hub image tag against overwrite”: the separate manifest check and push can race, and a post-push signing or attestation failure will block reruns because the existing tag is treated as immutable. Add concise guidance describing the required recovery path, such as manually deleting the GHCR package version or publishing a new tag, without changing the guard or publish behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/RELEASE.md`:
- Around line 50-66: Add --source-ref "refs/tags/$tag" to both gh attestation
verify commands in the release verification instructions, preserving their
existing repository, signer-workflow, and SPDX predicate options so attestations
are bound to the exact release tag.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 127-154: Document the accepted operational risk in the release
workflow around “Guard hub image tag against overwrite”: the separate manifest
check and push can race, and a post-push signing or attestation failure will
block reruns because the existing tag is treated as immutable. Add concise
guidance describing the required recovery path, such as manually deleting the
GHCR package version or publishing a new tag, without changing the guard or
publish behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ad0d1f37-410e-40c9-89e6-99626e83a95e
📒 Files selected for processing (8)
.github/workflows/release.ymlMakefileREADME.mddocs/RELEASE.mdhack/verify-release-hub-image.shsessions/2026-07-14-e9-hub-oci-publication.mdtests/scripts/release_hub_image_policy_test.shtools/internal/releasepack/policy_test.go
| Verify the keyless image signature against the exact tag workflow identity, then verify GitHub | ||
| provenance and the SPDX SBOM attestation. These commands require registry access; the later air-gap | ||
| workflow consumes mirrored, pre-verified material rather than weakening this verification boundary. | ||
|
|
||
| ```bash | ||
| identity="https://github.com/ArdurAI/sith/.github/workflows/release.yml@refs/tags/${tag}" | ||
| cosign verify \ | ||
| --certificate-identity "$identity" \ | ||
| --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \ | ||
| "$image" | ||
| gh attestation verify "oci://$image" \ | ||
| --repo ArdurAI/sith \ | ||
| --signer-workflow ArdurAI/sith/.github/workflows/release.yml | ||
| gh attestation verify "oci://$image" \ | ||
| --repo ArdurAI/sith \ | ||
| --signer-workflow ArdurAI/sith/.github/workflows/release.yml \ | ||
| --predicate-type https://spdx.dev/Document/v2.3 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
GitHub CLI gh attestation verify --source-ref exact syntax refs/tags tag release workflow identity
💡 Result:
The gh attestation verify command in the GitHub CLI allows you to enforce that an artifact's provenance matches a specific Git reference (such as a tag) using the --source-ref flag [1][2]. When verifying an artifact against a release tag and a specific workflow identity, the syntax is as follows: gh attestation verify \ --repo / \ --source-ref refs/tags/ \ --signer-workflow //@refs/tags/ Explanation of flags: --repo /: Specifies the repository associated with the artifact [3][2]. This is required for fetching the attestation [4]. --source-ref refs/tags/: Enforces that the Git reference associated with the source repository matches the provided tag exactly [5][2]. --signer-workflow @refs/tags/: Enforces that the workflow that signed the attestation matches the specified workflow file, optionally scoped to a specific tag or commit [4][2][6]. Example: To verify an artifact against a release version (e.g., v1.0.0) and a specific release workflow: gh attestation verify my-artifact.zip \ --repo my-org/my-repo \ --source-ref refs/tags/v1.0.0 \ --signer-workflow my-org/my-repo/.github/workflows/release.yaml@refs/tags/v1.0.0 This ensures the artifact was produced by the specified workflow running on the exact tag provided [4][6].
Citations:
- 1: Add signer-digest, source-ref, and source-digest options for
gh attestation verifycli/cli#10308 - 2: https://man.archlinux.org/man/extra/github-cli/gh-attestation-verify.1.en
- 3: https://man.archlinux.org/man/gh-attestation-verify.1.en
- 4: https://github.com/github/docs/blob/main/content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md
- 5: https://man.freebsd.org/cgi/man.cgi?manpath=freebsd-ports&query=gh-attestation-verify&sektion=1
- 6: https://github.com/integrations/terraform-provider-github/blob/main/VERIFY_ATTESTATIONS.md
Bind attestation verification to the exact release tag.
Add --source-ref "refs/tags/$tag" to both gh attestation verify commands so the attestation must come from the release tag, not just the workflow file.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/RELEASE.md` around lines 50 - 66, Add --source-ref "refs/tags/$tag" to
both gh attestation verify commands in the release verification instructions,
preserving their existing repository, signer-workflow, and SPDX predicate
options so attestations are bound to the exact release tag.
1 participant
Release candidate
Promotes green dev integration commit 6fe30e0 to main for the v0.3.0-beta.4 beta release.
Included
Evidence
After this PR is green and merged, the signed annotated tag v0.3.0-beta.4 will trigger the release workflow. The published GHCR manifest, signature, attestation, SBOM, release assets, and exact main CI will be verified before marking the promotion complete.
Summary by CodeRabbit
New Features
Documentation
repository@sha256:...image reference and rejects mutable tags such aslatest.