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