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

CURRENT RELEASE-SAFETY DECISION — 2026-10-09 — HARD BLOCK BEFORE THE NEXT TAG

ISSUE = #911 / OPEN / IMPLEMENTATION NOT PROVEN
RELEASE_TAG_ALLOWED = NO (for the next v* release, including v1.30.0, until #911 terminal)
TAURI_RELEASE_PUBLISH_ALLOWED_WITHOUT_TAG_TIME_SECURITY_SUCCESS = NO
GHCR_PUBLISH_OR_ALIAS_MOVE_ALLOWED_WITHOUT_TAG_TIME_SECURITY_SUCCESS = NO
PROCEDURAL_WATCH_OR_MANUAL_CANCEL_IS_NOT_A SUBSTITUTE = YES
GATE_4D_PREEMPTION = NO; IMPLEMENT AFTER GATE 6 / BEFORE ANY NEXT RELEASE CANDIDATE TAG
OWNER = Claude Code CLI (sole source/workflow/PR/merge/retention writer)

Decision and scope: Make the publication actions fail closed on a fresh, trusted Security Audit of the exact tag/ref SHA, and complete this implementation before creating the next release tag, not after it. The fact that GitHub Actions cannot automatically stop a tag from being created is distinct from the publish gate: the operator must withhold tag creation until the code and both negative/positive workflow proofs have already merged and passed on the candidate main. Tag creation, Tauri/GitHub Release+updater output, and GHCR version/minor/latest publication are not permitted while this issue remains open. No automatic or tacit fallback to the v1.29.1 watched-cancellation procedure. An explicit maintainer decision would be needed to change this control-plane policy, never an agent self-authorization.

Live verified gap on main=4428fdd81c9e656be37861895a6cb001ef129dbc: .github/workflows/tauri-build.yml still uses release.needs: [bundle]; .github/workflows/docker.yml publishes through a build-push job with push: true and no security dependency; .github/workflows/ci.yml runs the separate OSV 🔒 Security Audit job. The independently passing tag CI is not a publication barrier. v1.29.0 Docker publication evidence includes :1.29.0, :1.29, :latest (the stable-SemVer latest=auto behavior of docker/metadata-action is material). Pre-tag rerun side-effects forbid CI job reruns with dependent deploy jobs.

Required engineering acceptance — all conditions, not a checklist-only gate

Exact-ref security gate: tag-triggered Tauri and GHCR publish DAGs each require a fresh successful, SHA-pinned OSV audit using the existing pinned scanner and src-tauri/osv-scanner.toml over all three lockfiles pnpm-lock.yaml, src-tauri/Cargo.lock, crates/Cargo.lock. No stale or unrelated main/PR result as substitute; verify config, scanner exit code, checkout/ref/lockfile provenance. Share a trusted reusable implementation only if it preserves independent per-workflow publish gating and immutable action policy.
Tauri: release creation, asset upload, updater latest.json publication and any release-visible side effects are unreachable unless the security job concludes success for the identical tag SHA, alongside existing bundle, tag signature, parity and asset gates.
GHCR: build-push (including version, major.minor, latest and any future moving aliases) cannot push or move tags unless the exact-ref security gate succeeds. Evaluate effective docker/metadata-action stable-SemVer latest=auto semantics, not solely an explicit raw latest rule.
Fail-closed on failures and skips: vulnerability finding, scanner error/unavailable database, no result, skipped job, cancellation, timeout, wrong/missing ref, invalid input or branch/tag confusion never publish. Both push: tags and workflow_dispatch paths must be tested for no security bypass; test the actual permission/condition graph, not only a green audit in a separate workflow.
Security and policy: immutable action pins; least-privilege token permissions (no publish-token use before admission), protected trusted workflow definitions, no pull_request_target, no admin/ruleset bypass, no untrusted PR-controlled authorization and no artificial passing status. Preserve signing/notarization/update-provenance contracts.
Positive/negative tests: isolated non-publishing workflow_dispatch/policy validation, positive OSV success and representative fail/skip/timeout/cancellation/wrong-SHA fixtures must prove each publish consumer remains blocked. Do not create a real GHCR tag or release in tests. Link exact-head CI/CodeQL, workflow-policy assertions, reviewer thread disposition and observed job-dependency proofs on the implementation PR.
Release integration: implement via a bounded signed PR under the exclusive Claude Code CLI writer; merge only after exact-head gates and reviewer disposition, then resulting-main CI/CD+CodeQL, Production exact SHA, canonical health and safe retention. Update release protocol/evidence and GitHub #926 / Linear QNB-162 / QNB-172. Maintain hard RELEASE_TAG_ALLOWED=NO until all tests and audit gates are terminal and independently read back.

Historical clarification: earlier #911/#926 language saying preferred or allowing a watched-cancellation exception described the previous temporary mitigation. It is superseded for the next release tag by this hard pre-tag decision. No Gate-4/5/6 preemption; the sequence stays Gate 4D/4E → Gate 5 → Gate 6 → #911 mechanical implementation/proof → authorized Gate 7 and/or other prerequisite sequencing as applicable → release-candidate freeze and tag. This issue is not done until the code is actually enforcing the contract.

CURRENT ROLE — 2026-10-06 — v1.30 PRE-TAG SECURITY PREREQUISITE

CURRENT_MAIN = bf745090f7e980e167b1bbf01c7f6dea51fb451f
STATUS = OPEN / NON-PREEMPTIVE
PRIMARY_ACTIVE_LANE = Gate 4D / #359 / QNB-11 — fresh read-only R4 admission
PREFERRED_EXECUTION_WINDOW = after Gate 6 / before tag boundary
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO

The tag-time publication hardening remains queued for the pre-tag window. It does not preempt the current R-15 semantic gates.

HISTORICAL / SUPERSEDED AUTHORITATIVE STATE — v1.30 pre-tag publication-security prerequisite — 2026-10-01

TARGET_RELEASE = v1.30.0
V1_29_1 = VERIFIED
CURRENT_CRITICAL_PATH = R-15 Gate 3C → Gate 4 → Gate 5 → Gate 6
THIS_ISSUE = release-pipeline security hardening
GATE_3_6_BLOCKER = NO
V1_30_TAG_PREREQUISITE = SHOULD RESOLVE BEFORE TAG unless an explicit maintainer decision accepts the procedural fallback
PREFERRED_EXECUTION_WINDOW = after Gate 6 / before v1.30 candidate tag-publication boundary

The old v1.29.1 release hold is gone. Preserve this as the mechanical owner for making Tauri/GHCR publication depend on fresh security success. It should not preempt the active R-15 engineering gates, but #926 now treats it as a preferred prerequisite before the v1.30.0 tag. Revalidate the workflow graph on then-current main before changing publication workflows; preserve immutable pinning and the no-admin/no-bypass trust model.

HISTORICAL / SUPERSEDED — post-v1.29.1 hardening checkpoint — 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).

docs(release): state the tag-time audit guard as procedural and keep …

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.

docs(release): require a newly executed Security Audit before the v1.…

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.

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.

docs(release): state the tag-time audit guard as procedural and keep …

docs(release): require a newly executed Security Audit before the v1.…

Security observation — 2026-10-11

A fresh authenticated GitHub read reports open Dependabot alert #88 for GHSA-hp3w-g68c-fv3c (sprintf-js; medium; unbounded-precision denial of service; no first patched version reported). The current lockfile/installed graph contains two paths:

WorldScript runtime dependency mammoth@1.12.3 → argparse@1.0.10 → sprintf-js@1.0.3.
Optional @domain/ai-core dependency @huggingface/transformers@4.2.0 → onnxruntime-node@1.24.3 → global-agent@3.0.0 → roarr@2.15.4 → sprintf-js@1.1.3.

GitHub labels the alert dependency scope runtime; these graph observations do not establish which shipped surface accepts attacker-controlled formatting or actual exploit reachability. Current main already contains a maintainer-evaluated, time-bounded OSV exception for this exact advisory in src-tauri/osv-scanner.toml (lines 102–113), valid until 2026-11-30T00:00:00Z. It records the absence of a patched release, the attacker-controlled-format precondition and both transitive paths; argparse's own help/error templates are the documented format strings. This is existing governing state, not a newly granted waiver. No new ignore, dependency train or dismissal was introduced. Follow-up is to refresh reachability/upstream availability before expiry and remove the exception once remediation is available.

PR #1026 changes only coordination test evidence and CHANGELOG and does not remediate this alert. The CI OSV scan explicitly uses src-tauri/osv-scanner.toml against pnpm-lock.yaml and both Cargo lockfiles; green Security Audit therefore includes that existing exception and does not mean the open alert has disappeared. #911 remains open; no tag, release, publication-gate implementation or Gate-7 admission is claimed. Latest release remains v1.29.1.

2026-10-13 — Rust cloud-analysis inventory / pretag scope disposition

Maintainer requests cloud-first Rust/CI tooling without workstation overload or additional governance/tooling PRs. Single release-path inventory + timing matrix is now curated in Linear. Existing mandatory release blocker stays exactly this issue: prove that Tauri/GHCR tag-time publication cannot proceed unless the matching Security Audit/OSV gate passes on the exact tag SHA; never infer that routine PR OSV green guarantees tag-time publishing.

Identified security-coverage gap, not a new release gate: current .github/workflows/codeql.yml scans only javascript-typescript; GitHub officially supports Rust CodeQL (including build-mode: none). Read-only evaluate a safe separate Rust-language configuration alongside the existing advanced JS/TS configuration; DO NOT switch on default setup blindly (it can supersede advanced setup), or make the Rust scanner an unrelated pretag blocker/PR. Implement only within an already genuinely necessary approved security source wave if scope, time and independent CI remain safe; otherwise stage after v1.30. No mandatory review reruns, local Rust build, extra new issue/PR or weakening any release gate authorized by this comment.

Current main snapshot 35a7866529779d8a4e8a67a48fbc6a85b02ca386; current active R-15 PR #1027. Re-fetch before action. RELEASE_ALLOWED=NO until existing prerequisites, including this issue, are proven.

2026-10-17 — newly materialized ZIP archive-extraction security blocker (pretag and PR CI)

Upstream RustSec advisories RUSTSEC-2026-0367, 0368, 0369 now list zip fixed in >=9.0.0. GH #927 OSV evidence identifies six hosted Security Audit hits on current lockfiles zip@4.6.1 and zip@8.6.0 (including critical findings). The affected transitive paths are worldscript-studio -> tauri-plugin-updater@2.12.0 -> zip@4.6.1 and worldscript-studio -> candle-core@0.11.0 -> zip@8.6.0, also via candle-nn@0.11.0. This caused current-head PR #1077 CI Security Audit failure though its own diff is a GitHub workflow action pin, not the vulnerable dependency change. Current upstream zip docs declare MSRV Rust 1.88, conflicting with WorldScript's declared 1.77.2 (GH #572/QNB-55). Root cause/actual archive-extraction reachability has not been verified; do not claim exploitability or safety without callsite/platform evidence.

Urgent security triage before PR/release admission: map each advisory to both lockfiles, concrete extraction APIs and local/untrusted-input privileges on Linux/macOS/Windows; find fully compatible fixed upstream graph, source-scoped safer fix, or an explicitly reviewed security/MSRV policy decision (do not silently raise MSRV); validate OSV, Rust/Tauri updater parity, native packaging/build. Do not add an advisory ignore, turn off OSV, set continue-on-error, treat skipped checks as pass, or merge #1077 under a weaker policy. Maintain #911's distinct exact-tag-SHA Security Audit publication gate; v1.30=NO_GO and no tag/publication.

Execution sequencing and ownership in QNB-173 conditional successor plan, also recorded at QNB-162/QNB-55. This is an observed blocker, not a fix or source-work authorization.

Read-only reachability and current-main OSV follow-up — 2026-10-17T15:39:13Z

On the exact current main a710b39, the scheduled Security Audit/OSV run 38998852956 is FAILURE; see workflow run. PR #1077's run 39024385683 also has Security Audit and CI Success FAILURE while CodeQL succeeds; its lockfiles match main and its workflow-only diff did not introduce the vulnerable versions.

Read-only source/upstream inspection narrows exposure but does not prove the app safe: no first-party Rust ZipArchive::extract or ZipStreamReader::extract callsite was found. tauri-plugin-updater 2.12.0 enables ZIP support and its Windows updater path calls ZipArchive::extract into a temporary directory; the first-party UI reaches signed downloadAndInstall, and the current Windows feed points at a signed setup executable. The updater's signature check is an input boundary, not proof against a compromised signing/release path. zip 4.6.1 resolves only for the Windows target here. The optional rust-compute feature is disabled by default; when enabled, Candle's zip 8.6.0 upstream readers use entry reads, not extract, and no first-party Candle caller was found. Unix advisories principally map to that optional path; RustSec's Linux/macOS reproduction for 0368 does not establish the Windows outcome.

The repository has no demonstrated arbitrary user ZIP extraction path, but downstream rust-compute use and signed updater supply-chain compromise remain unqualified. Do not claim exploitability or non-exploitability. No source change/admission, advisory ignore, or gate weakening occurred. The OSV failure still blocks merges and v1.30 publication.

Maintainer security path selection — 2026-10-17 — Codex maintenance-only remediation, MSRV unchanged

The owner explicitly instructs that Claude remain paused and Codex perform maintenance only. For current zip@4.6.1/8.6.0 RUSTSEC-2026-0367/0368/0369 blockers, retain Rust 1.77.2 as the declared MSRV and admit only focused dependency/security remediation work (not ordinary R-15 product/secure-store feature work). Research compatible upstream version graph/backport and affected ZIP archive-extraction API callsites first; optional Candle and signed Windows updater path require separate surface tests. Four target graphs declaring dependencies up to Rust 1.89.0 expose an unresolved declared-MSRV contract; does not prove compiler failures. Fully test an isolated signed minimal PR against OSV/Cargo both lockfiles, 1.77.2/installed toolchain, Windows/macOS/Linux, Tauri native-JS updater parity, CodeQL, and current substantive reviewers. No global MSRV uplift, no blanket suppressions, gate bypass, or release until owner approval and full proof. If no compatible secure remediation exists, stop SECURITY MERGE admission with explicit evidence and minimal required owner decision; other independent read-only maintenance may continue.

Separate operator transfer for SAFE-only Vercel Preview retention is recorded at #627; it is no authorization for publishing or releasing. Dependencies for new train remain gated on honest OSV clean and terminal retention. v1.30=NO_GO.

Live registry check — no Rust-1.77.2-compatible ZIP remediation identified — 2026-10-17T16:14:19Z

Fresh crates.io API reads show zip 9.0.4 is the newest stable release and declares Rust 1.88; no 4.6.2 or 8.6.1 release is listed. The patched zip 9.x line therefore fits neither current dependency requirement: tauri-plugin-updater 2.12.0 has Windows zip ^4, while candle-core 0.11.0 requires zip ^8.6.0. The updater's 2.12.0 default feature set includes zip; its zip feature also enables tar/flate2 used by archive update paths, so removing it blindly would change supported Linux/Windows updater formats.

Latest stable tauri-plugin-updater is 2.14.0 (Rust 1.90), outside the repository's ~2.12.0 pin and still with a target-Windows zip ^4 dependency; 2.13.x is likewise Rust 1.90 and zip ^4. candle-core 0.11.0 remains the only 0.11 release and brings zip 8.6.0 through the optional rust-compute feature.

Main's scheduled OSV scan 38998852956 remains FAILURE and #1077's Security Audit remains blocked. No safe complete upstream bump was proven under the declared 1.77.2 floor. Disposition: NO_COMPATIBLE_FIX_PROVEN; no partial Candle removal, fork/backport, lockfile edit, or scanner exception was made. A reviewed maintained backport/fork design would need its own full dependency-source, API/ABI, license, dual-version, MSRV, and cross-platform test proof before admission.

Codex next-step refinement — 2026-10-17: engineering prototype BEFORE repeating NO_COMPATIBLE_FIX_PROVEN

Owner directs local Codex to continue maintenance-only without stopping at version inventories. Declared Rust MSRV 1.77.2, tauri updater zip^4, optional Candle zip^8.6, RUSTSEC-2026-0367/0368/0369 and red OSV remain binding facts. Neither an OSV waiver nor higher MSRV is authorized.

Concrete next action: in a private isolated test workspace trace verified upstream fixes and prototype an independently reviewable minimal backport for both ZIP lines or a suitable maintained extractor alternative. Add harmless temporary-directory regression tests for privileged Unix bits, symlink target containment, chmod through symlinks, stream/archive API parity, TOCTOU and Windows/macOS/Linux compatibility. Qualify rustc 1.77.2 and both Cargo locks; do not claim source-level mitigation automatically clears scanner advisories. No fork publishing, renamed package to hide scanning, new ignore, check downgrade, or production integration without authentic OSV-clean provenance and normal merge gates. If no admissible fix emerges, produce exact tested patch/diff, observed failure matrix and the one concrete external approval needed, and keep advancing independent maintenance. This comment is a work-method directive, not confirmation of any successful patch.

2026-10-17 — source-level ZIP security prototype and Rust 1.77.2 probes

Current main was rechecked through GitHub REST and git ls-remote: a710b39bb2aeecee9a1e580cc367c930c45b58c1.

A private, isolated differential prototype was built from official crates.io archives for zip 4.6.1 and 8.6.0, with source/VCS provenance checked. The local Linux temporary-directory harness passed for both: SUID/SGID masking, sibling traversal rejection, pre-existing parent-symlink escape rejection, normal in-root relative symlink behavior, central-only metadata confinement, and ordinary stream-mode handling. A separate 8.6.0 activation probe confirmed that restoring the stream central-directory signature parser without the confinement change lets a malicious central-only entry chmod a harmless outside sentinel through a pre-existing symlink; those changes must remain coupled.

The updater's Windows target graph resolves tauri-plugin-updater 2.12.0 -> zip 4.6.1 with no additional zip features. Under cargo +1.77.2, the private zip4 source initially failed on three unqualified size_of::<u32>() calls; adding std::mem::size_of and lowering only the disposable copy's manifest floor to 1.77.2 made that source check pass. For zip8, the current locked rust-compute graph contains zip 8.6.0 -> candle-core 0.11.0 -> indexmap 2.14.0 -> hashbrown 0.17.1; Cargo 1.77.2 rejects the latter's Edition-2024 manifest. No repository lockfile was modified.

Private artifact digests: prototype report SHA-256 4ee5e537681360cf666c959167d19cb9e62f2bd2beb446cb0e9d63f03ddefa0f; differential patch SHA-256 78db65e381b657aa1d72f8c0dfb535337f2d973ff989e73ef1158c0650a56d85.

Disposition remains PROTOTYPE_ONLY / OSV_FAIL / NO_MERGE: the patch retains original package identities and the active OSV result is not cleared; zip8 is not qualified at Rust 1.77.2. The local tests do not prove race resistance, Windows/macOS behavior, updater packaging, Candle runtime, or full hosted CI. No PR, push, package publish, scanner exception, MSRV change, or source merge occurred. The exact remaining shipping gate is a traceable patched dependency identity accepted by the existing scanner and a complete 1.77.2/platform/security review; the prototype is not ready to ship.

ZIP8 source backport probe — 2026-10-17T19:43Z

A private ZIP 8.6.0 candidate was tested under Cargo/rustc 1.77.2 with an experimental exact indexmap 2.11.0 pin, resolving hashbrown 0.15.5. The private copy first required Edition 2021/Rust 1.77.2 metadata and source compatibility edits (the official 8.6.0 manifest remains Edition 2024/Rust 1.88); after those edits, the handle-relative parent-replacement fixture passed 1/1, rejecting the raced symlink with NotADirectory while the harmless sibling remained mode 0600. The exact private candidate diff SHA-256 is 6d0d694494c347f9b5fd7439bce299770d27ceaaf0244d8c9da8df4b2a0b37e0.

This does not qualify the released ZIP package or its full API and feature graph: the package identity/version remains OSV-flagged; full ZIP security tests, Windows/macOS, Candle, updater packaging and maintenance review are not complete. No source/lockfile/PR changes were made. Security Audit run 39061065120 remains failed, and #1078 remains BLOCKED_BY_GLOBAL_OSV without another correction push.

ZIP8 private regression suite under Rust 1.77.2 — 2026-10-17T19:44Z

The adapted private ZIP 8.6.0 backport candidate passed the Unix regression fixture target under Cargo/rustc 1.77.2 (1 test target). Assertions covered SUID/SGID masking, archive symlink escape rejection, pre-existing parent-symlink escape rejection, central-only name/mode mismatch preserving an outside sentinel at 0600, ordinary stream mode 0777, and valid in-root relative symlinks; the dedicated parent-replacement race test separately passed 1/1. The fixture source is private and the complete candidate diff SHA-256 is 6d0d694494c347f9b5fd7439bce299770d27ceaaf0244d8c9da8df4b2a0b37e0.

The experiment changes only a private ZIP copy's Edition/Rust metadata to 2021/1.77.2 and backports source syntax/API compatibility; it pins indexmap 2.11.0 / hashbrown 0.15.5. Two prior version aliases in the harness were directed to this same ZIP8 copy, so repeated assertions are not independent package-version evidence. Official ZIP 8.6.0 remains Edition 2024 / Rust 1.88. The released package identity is still OSV-flagged; full feature graph, Windows/macOS, Candle/updater, archive-write races and independent review are not qualified. No repository source/lockfile, PR branch, or OSV configuration changed. #1078 remains blocked by required OSV failure.

2026-10-18 UTC security follow-up (private experiment evidence; no production dependency or lockfile change):

ZIP 4.6.1: an isolated candidate now has a reproducible diff (SHA-256 1dbd85704b7b7e930a1abd18442e4f417d13b3d46901012ee66541edfd6af485) and differential temporary-fixture regressions for RUSTSEC-2026-0367/-0368/-0369 pass. ZIP-only stable checks also pass for Windows MSVC and macOS ARM64 targets. This remains PROTOTYPE_ONLY: official ZIP4 declares Rust 1.82, and Tauri updater API/signature/package/hosted matrix proof is not complete.
ZIP 8.6.0: the current private coupled parser/stream/symlink-permission patch is SHA-256 abee9da44c2380c9684e94644bbe2691ab23769b28daafd471f5d9d43085897c. Prior isolated crate tests pass; the full Candle graph remains unqualified under Rust 1.77.2 at gemm 0.19 -> pulp 0.22.3. No production lockfiles changed.
Separate RustSec RUSTSEC-2026-0370/-0371/-0372 are informational unmaintained notices with no CVSS or fixed-version list, not ZIP fixes. Current OSV run 39061065120 / job 117479093033 is still red and reports 12 findings across 8 package identities, including ZIP4 and ZIP8.

No OSV ignore, fork identity, source merge, or security pass is claimed. The exact source/test caveats and next experiment are in the current private operator ledger; ZIP and zbus findings remain open.

2026-10-18 UTC ZIP4 updater integration delta (isolated private probe; no repository source/lockfile change):

The final ZIP4 candidate is selected by the actual tauri-plugin-updater 2.12.0 Windows target's default zip feature. The target-specific cargo tree --target x86_64-pc-windows-msvc -e features -i zip resolves zip 4.6.1 to the private candidate (tree SHA-256 4f5ff9c75cd6f8bd8b7920c9fe174b6f9c2719db8ff2d2bf3af88d3d09cdcbef).
A Stable Windows-target cargo check could not complete because ring 0.17.14 could not find lib.exe; the Linux host has no Windows MSVC archive tool. This is a cross-toolchain limitation, not a source compile pass/failure for the updater. No Windows hosted/package proof or MSRV qualification is claimed.
ZIP4 remains a private prototype: the differential security fixtures and ZIP-only target checks pass, but official ZIP4 declares Rust 1.82 and the updater integration/signature/package gates remain open. Current OSV still fails on the original ZIP4 package identity.

Detailed sanitized receipt remains local; no toolchain installation, dependency identity change, or merge was attempted.

Fresh security-audit and target-graph evidence — 2026-10-18

The exact-head Security Audit for PR #1078 remains red (run 39061065120, job 117479093033). Its OSV scan reports 8 package identities / 12 findings: ZIP 4.6.1 and 8.6.0 each hit RUSTSEC-2026-0367/-0368/-0369 (fixed version reported as 9.0.0); zbus_names 3.0.0 and 4.3.2 hit -0371; zvariant 4.2.0 and 5.12.0 hit -0370; zvariant_derive 4.2.0 and 5.12.0 hit -0372. The three zvariant-family entries are unmaintained notices without CVSS/fixed-version metadata; no exploitability conclusion is made here.

A fresh all-features target cargo tree narrowed the active graph: Tauri zvariant 5.12.0 is active for Linux through notify-rust 4.18.0 -> tauri-plugin-notification 2.4.0 and tauri-plugin-single-instance 2.4.4; the queried Windows MSVC, macOS x86_64 and macOS ARM64 target trees have no active zvariant 5.12.0 path. In the Core lock, zvariant 4.2.0 is present through optional secret-service 4.0.0 -> zbus 4.4.0 -> keyring 3.6.3, but the all-feature target tree selects Linux sync-secret-service/dbus-secret-service, Windows windows-native, and macOS apple-native; it shows no active zvariant 4.2.0 path. These target findings narrow observed paths but do not clear the scanner: OSV scans and fails on the locked package entries.

ZIP4/ZIP8 source patches remain private prototypes; no production dependency identity, lockfile, or scanner behavior changed. No OSV exception was added. #1078 remains BLOCKED_BY_GLOBAL_OSV; the unrelated Node-22 guard is not merged while this required audit is red.

2026-10-19 crates.io / OSV provenance delta

Read-only live metadata checks:

zip 9.0.5 is the latest non-yanked stable zip release (published 2026-10-17), declares Rust 1.88, and has crates.io checksum 6e04976da629d3b04204ba8105b396a193af8ad2583b2c79bfb3ab8af580a11e.
Stable tauri-plugin-updater 2.12.0, 2.13.0, and 2.14.0 all retain the Windows-target optional dependency zip ^4. Current stable 2.x is 2.14.0 and declares Rust 1.90. A parent-only updater bump therefore cannot select the OSV fixed ZIP 9 line, and the newer updater line also exceeds this repository's declared Rust 1.77.2 floor.
The exact a710b39... src-tauri/Cargo.lock still records updater 2.12.0, zip 4.6.1, and optional zip 8.6.0.
Live OSV records for RUSTSEC-2026-0367/-0368/-0369 still mark zip affected until fixed at 9.0.0.

This rules out “upgrade the Tauri updater only” as an OSV-clean or Rust-1.77.2-compatible fix. It does not qualify the private ZIP4 patch, change package identity, or clear the required security gate. No repository lock/source change or exception was made.

ZIP4 platform and updater-boundary follow-up — 2026-10-19

I revalidated the private Run05 ZIP4 patch digest (1dbd85704b7b7e930a1abd18442e4f417d13b3d46901012ee66541edfd6af485) and reviewed the verified updater 2.12.0 source archive against its Cargo.lock checksum.

The patch's descriptor-relative openat/symlinkat protections and new race fixtures are Unix-only. The non-Unix/Windows extraction path still uses path-based directory/file/symlink operations; there is no Windows reparse-point/race fixture. This is a qualification gap for the active Windows updater target, not a demonstrated Windows exploit.
In the exact updater source, download() verifies the Minisign signature before returning bytes; download_and_install() uses that path before install/extract. Public install(bytes) itself does not verify a signature and reaches Windows ZipArchive::extract directly, so an integration test must establish the verified-buffer path rather than infer it from install().
The prior Linux-to-Windows target check stopped at ring because lib.exe was unavailable. That remains a host toolchain stop, not an updater compile result. Required Rust CI is also blocked upstream by Security Audit, so no hosted full-gate proof or merge is available.
Official zip 9.0.5 is checksum-verified and contains the upstream mode-bit masking / symlink-permission handling, but requires Rust 1.88; current updater 2.x still requires zip ^4 and Rust 1.90 at its latest stable release.

No product code, lock identity, CI workflow, exception, PR, release, or deployment was changed. ZIP4 remains a private Unix-tested prototype, not an OSV-clean or Windows-qualified fix.

Private local diagnostics — 2026-10-19 (prototype evidence only)

Installed/verified local Rustup stable 1.99.1 alongside 1.77.2; no project MSRV, manifest, lockfile, CI, or policy was changed.
On the isolated Candle 0.11.0 rust-compute graph, cargo +stable check --locked completed successfully with safetensors 0.8.0, ZIP8 and Pulp private path candidates (one ZIP dead-code warning). The feature graph confirms Candle Core and Candle NN require safetensors ^0.8.0; pinning 0.7.0 is not semver-compatible.
On the isolated ZIP4 4.6.1 Run05 candidate, a no-default-features library check and five Unix regression fixtures passed on Rust 1.77.2 with --ignore-rust-version: RUSTSEC-2026-0367 mode masking, -0368 symlink escape, and three -0369 chmod/parent-swap cases. The candidate patch SHA-256 is 1dbd85704b7b7e930a1abd18442e4f417d13b3d46901012ee66541edfd6af485.

These are private source/fixture diagnostics, not product integration or declared-MSRV qualification: upstream ZIP4 4.6.1 declares Rust 1.82.0, and the command explicitly ignored that declaration. The tests are Unix-only and do not establish Windows/non-Unix updater behavior, signed update-flow integration, full platform coverage, race-freedom beyond the deterministic fixtures, or an OSV-clean package identity. The mandatory OSV gate and the product merge status are unchanged; no product source/lock/CI files were modified.

2026-10-19 Candle runtime and upstream compatibility update

A new isolated smoke test completed under Stable 1.99.1: synthetic Safetensors bytes loaded through Candle Core 0.11.0 VarBuilder into a Candle NN Linear layer and produced the expected CPU result (1/1 passed). This does not establish real product model use, Rust 1.77.2 compatibility, platform integration, or an OSV pass.

Fresh crates.io metadata confirms the integration constraints:

zip 9.0.5 is published and falls within RustSec 0367/0368/0369's fixed range, but requires Rust 1.88.
Stable tauri-plugin-updater 2.14.0 requires Rust 1.90 and still depends on Windows-target zip ^4.
Candle Core 0.11.0 still requires zip ^8.6.0 and safetensors ^0.8.0; Safetensors 0.8.0 requires Rust 1.80.
zbus 6.0.0 is available at Rust 1.89, but the latest stable Tauri notification and single-instance plugins still require Rust 1.90 and depend on zbus 5. The zvariant-family findings remain informational unmaintained notices without a fixed version event.

The exact PR heads remain unchanged. Runs 39061065120 (#1078) and 39024385683 (#1077) still report Security Audit and CI Success failed, with Verified Signatures and Node Quality jobs skipped. No product manifests, lockfiles, MSRV, CI, or security policy were changed; no PR or deployment mutation occurred.

Dependabot graph disposition — 2026-10-19

A targeted read-only review of two open candidates confirms neither removes the reported zvariant family from the product lockfiles:

PR #1047 changes dbus-secret-service 4.0.3 → 4.1.0. The official crates.io manifest raises its declared Rust floor from 1.70 to 1.78, above the unchanged project MSRV 1.77.2. The current crates/Cargo.lock separately retains secret-service 4.0.0 → zbus 4.4.0 → zbus_names 3.0.0 / zvariant 4.2.0; the candidate's diff does not remove that edge. It is not an OSV disposition for the zvariant findings and is not MSRV-admissible as written.
PR #1053 changes only the npm @tauri-apps/plugin-notification package and pnpm-lock.yaml; it does not update the Rust tauri-plugin-notification package or the Linux Cargo graph containing zvariant 5.12.0. It is unrelated to clearing RUSTSEC-2026-0370/0372.

Both candidates are on older bases and remain subject to the unchanged required Security Audit. No PR, lockfile, or MSRV changes were made.

Tauri candidate and zbus-compatible line check — 2026-10-19

PR #1043 updates the updater to 2.13.2. Its official crate manifest declares Rust 1.90 and still uses Windows-target zip ^4; it exceeds the unchanged Rust 1.77.2 floor and does not reach the OSV-fixed ZIP identity.
PR #1047 raises dbus-secret-service to Rust 1.78 while the separate secret-service 4.0.0 -> zbus 4.4.0 -> zvariant 4.2.0 lock edge remains.
PR #1053 is an npm-only plugin bump. It does not update Rust tauri-plugin-notification; the Rust crate 2.5.1 itself requires Rust 1.90.
A private stable feature-graph probe tested notify-rust 4.11.0, which is within the notification crate's ^4.11 range and defaults to zbus ^4. It resolves to zbus 4.4 / zvariant 4.2 / zbus_names 3.0, so the advisory family remains. The independent Tauri single-instance path still selects zbus 5.16 / zvariant 5.12. This is graph evidence only, not Rust 1.77.2 qualification; the unpinned 1.77 resolver hit Edition 2024 transitive manifests before graph completion.

No dependency or lock changes were made. Full private evidence and resolver-log digests are retained in the local operator report DEPENDABOT_DBUS_GRAPH_DISPOSITION_2026-10-19T2031Z.md.

OSV delta — 2026-10-20: 12 → 9 findings through one real removal

#1079 (108466e5) builds tauri-plugin-updater without its zip feature. With createUpdaterArtifacts: true, the release ships the raw -setup.exe / .msi / .AppImage. The zip feature is only needed for v1 .zip / .tar.gz bundles, and the macOS .app.tar.gz path does not depend on it. On that head, the unchanged required scanner (run 39337407480, job 118350489746) reports 9 findings in 7 packages. All three zip 4.6.1 findings are gone (RUSTSEC-2026-0367/-0368/-0369, including the 9.1 and 7.3 instances). There is no version change, no ignore entry, and Rust 1.77.2 is unchanged. All review channels report no findings. A hosted compile proof is running as a tauri-build.yml dispatch test build (run 39338327043), because the Rust gate in ci.yml stays skipped while Security fails.

Frontier for the remaining 9 (crates.io, 2026-10-20)

Remaining	Path	Why no dependency fix exists today
`zip 8.6.0` ×3	optional, default-off `rust-compute` (Candle 0.11, `zip ^8.6` non-optional); no product caller	No Candle release admits zip ≥ 9
`zvariant` / `zbus_names` / `zvariant_derive` 5.x ×3	Linux notification + single-instance plugins	notification 2.7.0, single-instance 2.5.4 and the 3.0.0-alpha.3 line (Rust 1.95) still require `zbus ^5`; only zbus 6 (Rust 1.89) drops the advisories. No MSRV raise alone reaches a clean graph.
same 4.x family ×3 (`crates/Cargo.lock`)	lockfile-only: keyring 3.6.3's `crypto-rust` feature names `secret-service?/crypto-rust`, a weak edge that keeps `secret-service 4 → zbus 4` in the lock; it is never compiled	Removing keyring's `crypto-rust` is not acceptable: keyring then opens the Secret Service session as `EncryptionType::Plain` instead of `Dh`. keyring 4.2.0 has no zbus edge but needs Rust 1.88.

Decisions this leaves for the maintainer (no action taken)

D1: remove the unused rust-compute feature (Candle). That honestly removes zip 8.6.0 ×3. Otherwise HOLD.
D2: a time-boxed osv-scanner.toml ignore for RUSTSEC-2026-0370/-0371/-0372 (unmaintained, no CVSS, no fix event). That is the same class as the accepted paste / unic / proc-macro-error entries. Otherwise HOLD until Tauri's Linux plugins move to zbus 6.
All existing osv-scanner.toml ignores expire on 2026-11-30. Their renewal review is due before then.

#1078, #1077 and #1079 stay unmerged while the required Security Audit is red.

fix(tauri): remove the unused rust-compute feature (#911)

fix(security): accept the unmaintained zbus sub-crate notices (#911)

fix(security): clear the required OSV gate (#1079)

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

Description

CURRENT RELEASE-SAFETY DECISION — 2026-10-09 — HARD BLOCK BEFORE THE NEXT TAG

Required engineering acceptance — all conditions, not a checklist-only gate

CURRENT ROLE — 2026-10-06 — v1.30 PRE-TAG SECURITY PREREQUISITE

HISTORICAL / SUPERSEDED AUTHORITATIVE STATE — v1.30 pre-tag publication-security prerequisite — 2026-10-01

HISTORICAL / SUPERSEDED — post-v1.29.1 hardening checkpoint — 2026-09-29

Problem (observed on v1.29.0, #872)

Current mitigation (procedural, not mechanical)

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

Activity

qnbs commented on Sep 29, 2026

Scope / evidence refinement — 2026-09-29

Exact GHCR evidence from v1.29.0

Post-release acceptance

qnbs commented on Sep 30, 2026

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

qnbs commented on Sep 30, 2026

v1.30.0 release relationship — 2026-10-01

qnbs commented on Oct 11, 2026

Security observation — 2026-10-11

qnbs commented on Oct 13, 2026

2026-10-13 — Rust cloud-analysis inventory / pretag scope disposition

qnbs commented on Oct 17, 2026

2026-10-17 — newly materialized ZIP archive-extraction security blocker (pretag and PR CI)

Read-only reachability and current-main OSV follow-up — 2026-10-17T15:39:13Z

qnbs commented on Oct 17, 2026

Maintainer security path selection — 2026-10-17 — Codex maintenance-only remediation, MSRV unchanged

qnbs commented on Oct 17, 2026

Live registry check — no Rust-1.77.2-compatible ZIP remediation identified — 2026-10-17T16:14:19Z

qnbs commented on Oct 17, 2026

Codex next-step refinement — 2026-10-17: engineering prototype BEFORE repeating NO_COMPATIBLE_FIX_PROVEN

qnbs commented on Oct 17, 2026

2026-10-17 — source-level ZIP security prototype and Rust 1.77.2 probes

3 remaining items

qnbs commented on Oct 17, 2026

ZIP8 source backport probe — 2026-10-17T19:43Z

qnbs commented on Oct 17, 2026

ZIP8 private regression suite under Rust 1.77.2 — 2026-10-17T19:44Z

qnbs commented on Oct 18, 2026

qnbs commented on Oct 18, 2026

qnbs commented on Oct 18, 2026

Fresh security-audit and target-graph evidence — 2026-10-18

qnbs commented on Oct 19, 2026

2026-10-19 crates.io / OSV provenance delta

qnbs commented on Oct 19, 2026

ZIP4 platform and updater-boundary follow-up — 2026-10-19

qnbs commented on Oct 19, 2026

Private local diagnostics — 2026-10-19 (prototype evidence only)

qnbs commented on Oct 19, 2026

2026-10-19 Candle runtime and upstream compatibility update

qnbs commented on Oct 19, 2026

Dependabot graph disposition — 2026-10-19

qnbs commented on Oct 19, 2026

Tauri candidate and zbus-compatible line check — 2026-10-19

qnbs commented on Oct 19, 2026

OSV delta — 2026-10-20: 12 → 9 findings through one real removal

Frontier for the remaining 9 (crates.io, 2026-10-20)

Decisions this leaves for the maintainer (no action taken)

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

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