release: make tag-time publishing depend on the security audit (Tauri release + GHCR)

[qnbs]

CURRENT AUTHORITATIVE STATE — post-v1.29.1 hardening — 2026-09-29

V1_29_1_BLOCKER = NO
CURRENT_MITIGATION = procedural / actively watched
MECHANICAL_ENFORCEMENT_OWNER = #911
START_AFTER = #872 v1.29.1 VERIFIED

v1.29.1 keeps the already-qualified release pipeline unchanged: refresh the exact-candidate Security Audit immediately before tag, watch the tag-triggered audit, cancel Tauri publication if red, and verify GitHub/Desktop and GHCR states independently.

The durable target here is machine enforcement after the recovery release: gate Tauri GitHub Release and GHCR publication/moving aliases on required security success, with positive + negative-path proof and workflow-policy revalidation.

Exact v1.29.0 Docker evidence confirms the current tag workflow emitted/pushed 1.29.0, 1.29, and latest. The :latest output is also produced by docker/metadata-action's stable-SemVer latest=auto behavior; future tests must preserve actual output semantics rather than reason only from the explicit raw is_default_branch rule.

---

Problem (observed on v1.29.0, #872)

Tag-triggered publishing does not depend on the tag's security audit:

• tauri-build.yml release has needs: [bundle] only. The enforced OSV scan runs in ci.yml (🔒 Security Audit) as an independent workflow.
• docker.yml pushes :X.Y.Z, :X.Y and :latest without depending on it either.

On v1.29.0, a new advisory (GHSA-6h2x-m376-mqjq, dev-only joi) appeared between the candidate's resulting-main run and the tag.

• The tag CI/CD failed.
• The desktop release was stopped only because it was cancelled by hand before its GitHub Release job.
• GHCR had already published 1.29.0, 1.29 and latest.

Current mitigation (procedural, not mechanical)

The v1.29.1 evidence record (#910) sets a procedure: re-check the Security Audit on the exact candidate right before tagging, then watch the tag's Security Audit (about 1–2 min) and cancel the Tauri release run if it is red. The bundle jobs take at least 12 min before release can start.

This is fail-closed only while someone is watching. It is not enforced by the pipeline.

Proposal (maintainer decision: release-pipeline and governance surface)

• Add a pinned OSV scan job (same osv-scanner.toml and lockfiles as ci.yml) to tauri-build.yml and make release depend on it: needs: [bundle, security-audit].
• Gate the docker.yml push on the same check. This also closes the gap where :latest moves before the audit.
• Exercise it with a workflow_dispatch run and a negative fixture, and update the workflow-policy tests.

Not part of the v1.29.1 cut, so the qualified release pipeline stays unchanged under the candidate. Found by review on #910 (Codex P1, CodeRabbit).

[qnbs]

Scope / evidence refinement — 2026-09-29

This issue is the durable post-v1.29.1 mechanical hardening owner.

V1_29_1_BLOCKER = NO
CURRENT_MITIGATION = PROCEDURAL / ACTIVELY WATCHED
POST_RELEASE_MECHANICAL_HARDENING = YES

The current v1.29.1 recovery intentionally keeps the already-qualified release pipeline unchanged and records the real control truthfully: refresh the exact-candidate Security Audit before tag, watch the tag-time Security Audit, and cancel Tauri publication if red.

Exact GHCR evidence from v1.29.0

Docker run 36618279810, job 109576816645, proves the tag workflow emitted and pushed:

• ghcr.io/qnbs/worldscript-studio:1.29.0
• ghcr.io/qnbs/worldscript-studio:1.29
• ghcr.io/qnbs/worldscript-studio:latest

all at digest:

sha256:1f463bc6ba1e2544b9d8c2191814c3eff50c9add81cd81d3d3927be736b3fe2d.

Important implementation nuance: the explicit raw rule
type=raw,value=latest,enable={{is_default_branch}}
is not what makes :latest appear for the tag. The pinned docker/metadata-action also has latest=auto behavior for stable SemVer tags, and the real run confirms the resulting tag set. Future changes/tests must preserve this actual behavior rather than reasoning only from the raw rule.

Post-release acceptance

After v1.29.1 VERIFIED, re-read current main and implement the smallest trusted design that:

• makes Tauri GitHub Release publication depend on successful security state;
• equivalently prevents GHCR publication/moving aliases before required security success;
• uses the same pinned/configured OSV contract;
• includes a negative/failure-path proof;
• updates workflow-policy/governance tests;
• preserves immutable action pinning and trusted execution boundaries.

Do not close this issue merely because the procedural v1.29.1 release succeeds.

[qnbs]

Finding from the v1.29.1 freshness executions: gh run rerun --job has deploy side effects

The v1.29.1 pre-tag freshness gate re-ran the 🔒 Security Audit job of the candidate's resulting-main CI/CD run (gh run rerun <run> --job <databaseId>). GitHub also re-runs the jobs that depend on it. That includes 🚀 Deploy to GitHub Pages:

• run 36654478104, attempt 2, job 109711590286 on f255d767 failed with Multiple artifacts named "github-pages" were unexpectedly found for this workflow run. Artifact count is 2;
• no user impact: Pages was already deployed from the same SHA, and main 4f971e0e redeployed at 03:54Z (HTTP 200);
• hazard: if main had already moved on, such a rerun could re-deploy Pages from an older SHA, or at least leave a red run on main history.

Procedure until this issue is implemented:

• run the freshness scan side-effect free via gh workflow run security-scheduled.yml --ref main, only while origin/main = the frozen candidate, and record the run ID and headSha;
• the workflow uses the same osv-scanner.toml and lockfiles and has no deploy jobs;
• do not use gh run rerun --job on a CI/CD run that has deploy dependents.

For the mechanical design here: the pre-publish audit dependency should run its own OSV job inside tauri-build.yml and docker.yml (fresh DB at tag time). That makes both a separate freshness rerun and the watched cancellation unnecessary.

[qnbs]

v1.30.0 release relationship — 2026-10-01

Release milestone #926 now targets the complete desktop at-rest encryption cutover.

This issue is the preferred mechanical release-pipeline predecessor for that cut: Tauri GitHub Release and GHCR publication/moving aliases should depend on a fresh tag-time Security Audit rather than the v1.29.1 procedural watch.

Treat #911 as P1 release hardening to converge before the v1.30.0 tag if safely possible. If it remains unresolved at candidate freeze, #926 requires an explicit maintainer disposition; do not silently fall back to assuming the procedural mitigation is equivalent to machine enforcement.