Should release artifacts have an independent signing or attestation identity?

[PierrunoYT]

Problem to decide

Zero's release pipeline produces per-asset SHA-256 files and the updater verifies the expected filename and digest before extraction. These are strong corruption and mismatch controls. Because the archive and its .sha256 sibling are published through the same GitHub release authority, replacement of both by an actor controlling that release channel still yields a self-consistent pair.

This is not a claim that current checksum verification is broken or that a release has been compromised. It is a request to decide whether Zero's threat model should include an independent artifact-authenticity identity.

Audit context: finding SEC-06 at main revision 1b5db1765672820caac1684b168c9898b5ba3593.

Relevant boundaries:

• internal/update/apply.go downloads archive and checksum and verifies before extraction.
• internal/release/release.go creates and verifies the digest files.
• .github/workflows/release-artifacts.yml publishes GitHub assets and uses npm OIDC/provenance behind a reviewed environment.

Proposed invariant

Keep SHA-256 sibling assets for corruption detection, and—if maintainers want stronger release-channel compromise resistance—verify an independently identifiable signature or attestation before extraction/install.

The verifier should pin an expected repository/workflow or signing identity rather than accepting any signature bundled beside the archive.

Design questions

1. Is GitHub release authority plus current checksum verification the intended trust model, or should direct installers/updater verify an independent identity?
2. If stronger verification is wanted, should the project prefer Sigstore/GitHub artifact attestations, a long-lived signing key, or another mechanism?
3. How should key/identity rotation, offline use, older releases, mirrors, and recovery from verifier outages work?
4. Should verification initially be advisory before becoming fail-closed?
5. How can install.sh, install.ps1, the Go updater, and npm packaging share one release identity without introducing an unsafe bootstrap dependency?

Acceptance criteria for any eventual implementation

• valid releases continue to install on Linux, macOS, and Windows;
• archive, checksum, signature, or provenance substitution fails before extraction;
• expected identity and workflow are explicit and tested;
• rotation and recovery are documented;
• current checksum filename/digest protections remain; and
• npm OIDC/provenance and manual environment approval are preserved.

Full audit proposal: https://github.com/PierrunoYT/zero/blob/audit/codebase-audit-2026-09-08/docs/audit/SECURITY_AUDIT.md#sec-06--sibling-checksums-do-not-independently-authenticate-releases

[FabioLeitao]

Thanks for writing this up. We went through the same decision in another project, so here is what we chose and why, in case it is useful. It is one data point, not a recommendation to copy.

What we did. In Data Boar we kept per-asset digests and added native GitHub build provenance on tagged releases: actions/attest-build-provenance (SHA-pinned, id-token: write + attestations: write only on that job). The job fails if no bundle is produced and verifies the bundle before attaching it. The decision record is ADR 0092. One lesson from it: we only claim what a consumer can actually verify, so no badges for provenance that a registry does not expose yet.

The principle behind it is the one this discussion names: a verifier must not draw its trust from the artifact it verifies. We wrote that down as ADR 0088. The sibling .sha256 is a good corruption check, but it shares an authority with the archive, so it cannot also be the authenticity check.

On your questions, from that experience:

1. Trust model. One concrete detail: release-artifacts.yml uploads with gh release upload ... --clobber, so a published asset can be replaced in place. Whatever the decision, it may be worth deciding whether replacement after publish should be possible at all. GitHub's immutable releases could address that part, but they need assets attached before publishing, which interacts with the release-please flow.
2. Mechanism. GitHub artifact attestations (Sigstore-backed, keyless) fit well because the npm path already uses OIDC provenance: no long-lived key to store or rotate, and the identity is the repository plus workflow path plus tag ref, which the verifier can pin exactly as you propose.
3. Rotation, offline, old releases. Keyless removes key rotation, but the verifier still needs Sigstore's trust root. Shipping the bundle as a release asset allows offline verification against an embedded root, with a documented way to refresh it. Releases from before the cutover have no attestation, so the verifier needs an explicit "no attestation, checksum only" path for them rather than treating absence as failure.
4. Advisory first. That is what we would suggest too: report the result loudly but do not block, then fail closed once a few releases have verified cleanly on all three platforms. A failed verification should never look like success.
5. One identity for all installers. The Go updater can verify in-process; install.sh/install.ps1 could verify when gh is available (gh attestation verify --repo ... --signer-workflow ...) and say clearly when they could not. Verifying in Go would likely mean a new dependency (sigstore-go), which I understand needs maintainer agreement first.

For context on how we work: that project runs CodeQL, Semgrep, gitleaks, zizmor and OpenSSF Scorecard in CI with SHA-pinned actions (ADR 0005), and the same checks run locally before anything is pushed. Happy to help prototype the advisory step if the team decides to go this way.