release(native): establish platform code signing, notarization, artifact identity & rollback trust #574

v1.29 release-truth disposition — 2026-09-29

The only current v1.29 blocker discovered under this owner was a truth bug, not missing signing implementation: Help claimed macOS/Windows installers were code-signed even though the release pipeline currently provides Tauri updater signatures, not Apple Developer ID/notarization or Windows Authenticode.

#904 removed that overclaim across the affected locales and also corrected the desktop data/log path shown for manual backups. Resulting main a67354841c54a73a6ddb8785bac2273762499aa2 has green CI/CD + CodeQL and exact-SHA READY Production.

Therefore:

• v1.29 does not claim OS-native installer signing/notarization;
• this issue remains open and post-release;
• release evidence must preserve the distinction:

source/tag identity
!= Tauri updater Minisign signature
!= macOS Developer ID + notarization
!= Windows Authenticode

Do not pull Developer ID/notarization/Authenticode implementation into v1.29 unless a new independently evidenced release blocker appears.

#906 owns future packaged functional qualification; it does not replace this artifact-trust/signing owner.

Context

WorldScript Studio's desktop release pipeline already has meaningful integrity controls, but it currently stops short of OS-native trust for downloaded installers.

Current release evidence and documentation distinguish these layers correctly:

Git commit/tag signature
        ≠
GitHub build provenance / attestation
        ≠
Tauri updater Minisign signature
        ≠
macOS Developer ID + notarization
        ≠
Windows Authenticode signature

The updater path already verifies per-platform Tauri updater artifacts with the configured Minisign public key. Current v1.28.x release evidence nevertheless states explicitly that platform code-signing and notarization remain separate claims. docs/TAURI-CI.md documents macOS APPLE_* requirements and says Windows Authenticode still requires a CA-issued certificate. docs/TAURI-UPDATER.md likewise documents the intended macOS/Windows signing inputs but the normal release pipeline does not yet make these guarantees authoritative.

The binding native roadmap also requires packaged identity, signing/update trust, rollback and installer evidence before native stable admission.

No current open issue owns this cross-platform release-trust remainder end to end.

Related but distinct:

• supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529 — provenance/SBOM/supply-chain gaps; does not establish OS-native package trust;
• toolchain(tauri): align JS/CLI/Rust Tauri 2.x versions and establish a bounded transitional update policy #573 — bounded Tauri 2.x dependency/version maintenance;
• native: promote macos-15-intel qualification lane into the release matrix #507 — Intel macOS qualification;
• [Bug]: Sluggishness? (.deb) #332 — packaged desktop lifecycle/performance evidence;
• future Qt packaging must inherit the same trust contract rather than create an unrelated second policy.

Goal

Establish one explicit, testable native-release trust contract for supported desktop platforms:

SOURCE / TAG IDENTITY
        ↓
TRUSTED CI BUILD
        ↓
ARTIFACT IDENTITY + PROVENANCE
        ↓
OS-NATIVE SIGNATURE / NOTARIZATION WHERE APPLICABLE
        ↓
UPDATER SIGNATURE + MANIFEST CONSISTENCY
        ↓
INSTALL / UPDATE / ROLLBACK VERIFICATION

The objective is not simply to make Gatekeeper/SmartScreen warnings disappear. It is to make every release artifact's identity, signing authority, update relationship, revocation/rotation behavior and recovery path explicit.

1. Current release-trust inventory

Before changing CI, inventory every produced desktop artifact and its existing trust layer.

At minimum record for each current platform/artifact:

Linux:
  .deb
  .rpm
  .AppImage

Windows:
  .msi
  .exe / NSIS bundle where produced

macOS:
  .dmg
  .app.tar.gz updater payload

Cross-platform:
  latest.json
  updater .sig files
  GitHub provenance/attestations if/when present
  release checksums/digests if present

For every artifact capture:

Do not call an installer "signed" solely because a different updater archive has a Minisign .sig file.

2. macOS Developer ID signing + notarization

Define and implement the production macOS release path using the current Apple-supported model.

Required properties:

• Developer ID signing identity is explicit;
• credentials exist only in the release job that needs them;
• hardened-runtime/entitlement requirements are reviewed rather than copied blindly;
• all executable code in the distributed app bundle is signed consistently;
• notarization is submitted and reaches an accepted terminal result before publication is called successful;
• notarization ticket is stapled where applicable;
• the published .dmg and updater bundle are independently verified after packaging;
• CI records non-sensitive verification evidence (codesign, spctl, notarization/stapling status) without dumping certificate/private material;
• failure to sign/notarize a release that claims these guarantees is fail-closed.

A locally usable unsigned developer build may remain possible, but it must be visibly distinct from a production release artifact.

Credential policy

Inventory and minimize the currently documented APPLE_* secret surface.

Prefer modern short-lived/notarization credentials where upstream tooling supports them; if long-lived credentials remain necessary, document:

owner
scope
rotation procedure
revocation procedure
recovery procedure

Never expose Apple credentials to pull-request-controlled code.

3. Windows Authenticode signing

Define and implement an evidence-backed Windows signing path.

Required decisions/evidence:

• certificate source/type appropriate to the project and distribution model;
• secure CI access mechanism for the private signing key or signing service;
• SHA-256 signing;
• trusted timestamping so signatures remain valid after certificate expiry where the platform contract permits;
• .msi and .exe/NSIS artifacts covered as applicable;
• post-build signtool verify or equivalent verification against the published bytes;
• subject/publisher identity documented truthfully;
• renewal/rotation/revocation procedure;
• no certificate/private-key material exposed to normal PR jobs.

SmartScreen reputation is not itself a cryptographic acceptance criterion. Document it as a distribution UX consideration rather than pretending code signing guarantees immediate reputation.

4. Linux artifact trust policy

Linux desktop distribution has no single universal Authenticode/Gatekeeper equivalent.

Define an explicit policy for the formats WorldScript publishes rather than making a vague "all installers signed" claim.

Evaluate, as applicable:

• GitHub/Sigstore provenance from supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529;
• release checksums/digest manifest;
• optional detached signatures for standalone artifacts if they add real user-verifiable value;
• .deb/.rpm repository/package-signing semantics only if WorldScript actually operates a repository requiring them;
• AppImage signature mechanisms only if supported and maintainable.

Do not introduce redundant signature layers with no documented verifier/user path.

5. Updater trust remains a separate layer

Preserve the current Tauri updater signature model as an independent control.

Explicitly prove:

latest.json identifies the intended release
        ↓
URL selects the intended artifact
        ↓
artifact bytes match the signature
        ↓
configured public key rejects modified/foreign payloads
        ↓
installation/relaunch occurs only after verification

Test both positive and negative cases.

Required negative cases include:

• modified updater payload;
• wrong signature;
• wrong manifest signature/entry where applicable;
• release manifest pointing at the wrong platform/architecture;
• stale/older release offered unexpectedly;
• missing asset;
• interrupted download;
• key mismatch after a planned rotation.

Do not conflate updater Minisign with macOS/Windows platform signatures in UI or docs.

6. Signing-key lifecycle and emergency response

Every signing authority must have a documented lifecycle.

For each key/certificate define:

PURPOSE
OWNER
STORAGE / CI ACCESS MODEL
ROTATION TRIGGER
EXPIRY
REVOCATION PROCEDURE
COMPROMISE RESPONSE
PUBLIC-KEY / CERTIFICATE UPDATE PROCEDURE
OLD-RELEASE VERIFICATION CONSEQUENCES

At minimum cover:

• Tauri updater Minisign key;
• Apple Developer ID/notarization credentials;
• Windows Authenticode credential;
• Sigstore/OIDC identities where supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529 introduces them.

Updater-key rotation

A rotation must not strand already-installed clients.

Design the transition explicitly before replacing the embedded updater public key. If the updater architecture only trusts one key at a time, define the necessary bridge-release sequence and recovery behavior.

A compromised updater key is a security event, not an ordinary dependency bump.

7. Release artifact identity and manifest coherence

Create one release evidence manifest or equivalent machine-verifiable record tying together:

release tag
source commit SHA
workflow/run identity
application version
platform + architecture
artifact filename
artifact SHA-256
OS signing identity/status where applicable
updater signature presence/status
provenance/attestation reference

The exact serialization format is implementation-defined, but duplicate sources of truth should be avoided.

latest.json, GitHub Release assets and the actual uploaded bytes must be checked for exact agreement.

Do not generate hashes before a later signing/notarization step mutates the artifact.

8. Reproducibility and rebuild evidence

This issue does not require immediate bit-for-bit reproducible desktop binaries on every OS, but it must make the level of reproducibility explicit.

Inventory nondeterministic inputs:

• Node/pnpm versions (toolchain(node): promote Node 24 LTS baseline and qualify Node 26 before supported-lane adoption #569/toolchain(pnpm): add non-frozen fresh-resolution canary for registry, override and lockfile integrity #570);
• Rust compiler/toolchain (toolchain(rust): define deterministic build toolchain, explicit MSRV policy and Core/Tauri compatibility lanes #572);
• Tauri/CLI/runtime graph (toolchain(tauri): align JS/CLI/Rust Tauri 2.x versions and establish a bounded transitional update policy #573);
• OS image/SDK versions;
• package locks;
• timestamps/signatures/notarization metadata;
• generated assets/version metadata.

Classify release reproducibility as one of:

SOURCE_REPRODUCIBLE
DEPENDENCY_GRAPH_REPRODUCIBLE
BUILD_ENVIRONMENT_PINNED
FUNCTIONALLY_REBUILDABLE
BIT_FOR_BIT_REPRODUCIBLE
NOT_YET_PROVEN

Do not claim deterministic/reproducible binaries without evidence.

Where bit-for-bit comparison is impossible due to signatures/timestamps, compare stable pre-signing payloads or normalized components only if this produces meaningful assurance.

#529 remains the provenance/SBOM owner; #570/#572/#573 own the underlying toolchain determinism.

9. Rollback / bad-release response

Define a safe response to a signed but defective release.

At minimum answer:

• can latest.json be rolled back safely?;
• does the updater permit downgrade, and should it?;
• how are incompatible persisted-data/schema migrations handled?;
• how is a bad artifact withdrawn without breaking already-installed clients?;
• when is a replacement patch release required instead of manifest rollback?;
• how do platform signatures/notarization behave for withdrawn releases?;
• how are release notes/status pages/docs corrected?;

Data compatibility outranks release convenience. Never downgrade automatically across a persisted-data format boundary that the older version cannot safely read.

Coordinate project/schema compatibility with #553 and protected-data migration with #445.

10. CI trust boundary / least privilege

Release-signing jobs are privileged code-execution environments.

Required properties:

• secrets are unavailable to ordinary pull-request jobs;
• release workflow inputs are validated;
• release only builds from admitted tags/refs according to policy;
• actions remain SHA-pinned;
• signing occurs only after required source/CI gates;
• artifacts passed into a privileged signer have a trusted provenance/identity path;
• no PR-controlled artifact can be substituted into the signing step;
• environments/approvals are used where appropriate;
• logs/artifacts cannot leak signing material.

Coordinate generalized GitHub Actions trusted-execution concerns with #506/#510 rather than inventing a separate workflow-policy engine here.

11. Qt migration relationship

This contract must survive the Tauri→Qt transition.

Separate:

PRODUCT RELEASE TRUST CONTRACT
        = durable

TAURI PACKAGING IMPLEMENTATION
        = transitional

QT PACKAGING IMPLEMENTATION
        = future adapter to the same contract

Do not defer OS signing/notarization merely because Tauri is transitional: current users download current installers today.

Conversely, do not build a Tauri-specific signing abstraction that Qt cannot replace cleanly.

Before Qt Stable, the Qt packaging lane must prove equivalent or stronger:

• artifact identity;
• native code signing/notarization;
• updater/update trust if Qt uses an updater;
• rollback/revocation;
• least-privilege CI;
• packaged verification.

12. Documentation truth

After implementation, reconcile:

• README install/download language;
• docs/TAURI-CI.md;
• docs/TAURI-UPDATER.md;
• AUDIT.md release evidence;
• release checklist/evidence docs;
• future Qt packaging docs;
• security(truth): consolidate user-visible security/privacy claims across storage, providers, PWA, collaboration & supply chain #549 security-truth matrix where claims are user-facing.

Use precise vocabulary:

SIGNED UPDATER PAYLOAD
AUTHENTICODE-SIGNED INSTALLER
APPLE-DEVELOPER-ID-SIGNED APP
NOTARIZED / STAPLED
PROVENANCE-ATTESTED BUILD

Never collapse them into generic "signed".

Acceptance criteria

• Current desktop artifact/signature/provenance matrix is documented.
• macOS production artifacts have a deliberate Developer ID signing and notarization policy, with CI verification where enabled.
• Windows production installers have a deliberate Authenticode + timestamp/verification policy where enabled.
• Linux artifact trust is explicitly defined without false cross-platform equivalence claims.
• Updater Minisign remains independently verified, including negative tamper/wrong-key cases.
• latest.json/release-assets/artifact identities are cross-checked deterministically.
• Signing/notarization secrets are isolated from untrusted PR execution.
• Signing key/certificate rotation, expiry, revocation and compromise response are documented.
• Updater-key rotation has a non-stranding transition plan.
• A machine-readable release evidence record ties tag/SHA/version/platform/artifact digest/trust state together.
• Build reproducibility maturity is explicitly classified and toolchain inputs are linked to toolchain(node): promote Node 24 LTS baseline and qualify Node 26 before supported-lane adoption #569/toolchain(pnpm): add non-frozen fresh-resolution canary for registry, override and lockfile integrity #570/toolchain(rust): define deterministic build toolchain, explicit MSRV policy and Core/Tauri compatibility lanes #572/toolchain(tauri): align JS/CLI/Rust Tauri 2.x versions and establish a bounded transitional update policy #573.
• Bad-release rollback/withdrawal behavior is defined without risking persisted user data.
• README/release docs distinguish updater signatures, OS-native signatures and provenance accurately.
• Future Qt packaging consumes the same product-level release-trust contract.

Non-goals

• claiming platform signatures exist before real credentials/evidence exist;
• storing private signing keys in the repository;
• exposing signing secrets to PRs;
• treating SmartScreen reputation as cryptographic proof;
• forcing one identical signing mechanism onto Linux/macOS/Windows;
• implementing supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529's provenance/SBOM work here;
• changing R-15/project storage formats;
• making Tauri permanent merely because current signing work targets its packages.