[Release] Ship signed, notarized, auto-updatable desktop builds with rollback evidence

[seonghobae]

Parent: #958

Buyer-visible gap

The current manual release workflow validates repository state and packaging prerequisites, but it does not constitute a complete commercial release channel. Buyers still lack evidence that the Windows/macOS artifacts they install are signed by the expected publisher, that macOS artifacts are notarized, that updates are signature-verified, and that a failed update can be recovered without losing a project.

A downloadable but unsigned or non-notarized artifact is a developer build, not the BandScope 1.0 distribution contract.

Product outcome

Create one release pipeline that produces trusted Windows and macOS artifacts from an exact protected commit, publishes checksums/SBOM/provenance, signs every platform artifact, notarizes macOS, and serves a signature-verified Tauri updater manifest with staged rollout and recovery evidence.

Required scope

Release identity and metadata

• Make the root package, Tauri config, application footer/about surface, Figma identity, release tag and generated updater manifest derive from one authoritative version source.
• Reject a release when any version or product identifier drifts.
• Preserve the current local-first product boundary; ordinary startup and update checks must not upload project or audio metadata.

Windows

• Produce the supported Windows installer/bundle formats from the protected release commit.
• Authenticode-sign the executable and installer with the approved publisher identity and timestamp service.
• Verify the signature and publisher in CI from a clean machine/image.
• Record architecture, OS compatibility, digest, signing certificate identity and timestamp in the release manifest.
• Coordinate with [Level 1] Windows/macOS arm64 + amd64 교차 아키텍처 빌드 지원 #38 for architecture coverage rather than duplicating its build matrix.

macOS

• Code-sign the app and installer artifacts with hardened runtime settings appropriate to the actual entitlement set.
• Submit the exact distributable to Apple notarization, staple the ticket where supported, and validate it with Gatekeeper tooling.
• Verify both Apple Silicon and Intel/universal outputs according to the supported matrix.
• Keep signing/notarization credentials outside repository artifacts and logs.

Updater and rollback

• Adopt the Tauri updater plugin/configuration with a pinned public verification key and signed update artifacts.
• Host an immutable update manifest that identifies version, platform, architecture, signature, digest, minimum supported version and release notes.
• Support staged rollout, explicit user deferral, bounded retry, offline startup and a recovery path when installation or first launch fails.
• Never auto-downgrade across a project-schema incompatibility; coordinate with the project-format issue under [Product Readiness] Complete BandScope 1.0 with measurable rehearsal outcomes #958.
• Retain the previous known-good installer and document rollback/repair steps.

Supply-chain evidence

• Generate and attach SHA-256 checksums, SPDX SBOM, build provenance/attestation and a machine-readable release manifest.
• Pin all release actions by full commit SHA and all toolchains/dependencies by repository policy.
• Prove the published artifacts are byte-identical to the verified release job outputs or explain the platform-signing transformation in provenance.

Acceptance criteria

• A single documented command or protected workflow creates the complete release candidate from a clean checkout.
• Windows installer and executable signature verification succeeds on a clean Windows environment.
• macOS code-signing, notarization and Gatekeeper verification succeed on clean supported macOS environments.
• The updater rejects a wrong key, wrong signature, wrong digest, truncated manifest, unsupported platform/architecture and replayed/stale update metadata.
• Offline startup remains functional when the update service is unavailable.
• A failed/cancelled update leaves the last known-good build and all project data usable.
• Version metadata is identical across package, runtime, about UI, release tag, updater manifest and Figma/brand handoff.
• Every artifact has checksum, SBOM, provenance and exact source commit evidence.
• Production statement/branch coverage and public API documentation remain 100% for repository-owned release/updater logic.
• Current-head CI, security, supply-chain, independent approval and zero unresolved review threads pass.

Test cases

• expired or rotated signing certificate;
• tampered installer after signing;
• notarization service timeout and retry;
• updater manifest rollback/replay;
• partial download and disk-full failure;
• app restart during update;
• update available while offline or behind a captive portal;
• project created on the new version and rollback attempted;
• version drift between package.json, tauri.conf.json, UI and tag;
• update channel switch between stable and pre-release.

Standards and authoritative guidance

• Tauri application signing and updater documentation: https://v2.tauri.app/distribute/sign/
• Tauri updater plugin: https://v2.tauri.app/plugin/updater/
• Apple notarization workflow: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
• Microsoft code-signing guidance: https://learn.microsoft.com/windows/msix/package/sign-app-package-using-signtool

Non-goals

• Do not store signing keys in GitHub artifacts or repository files.
• Do not call a manually zipped development build a production release.
• Do not make the updater a prerequisite for offline use.
• Do not bypass fix(security): establish canonical npm, PDF.js, Nanoid, and Undici baseline #783 or current branch protection to manufacture a release.