Skip to content

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

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

Description

@qnbs
qnbs
opened on Sep 29, 2026

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).

Activity

  1. qnbs
    added a commit that references this issue on Sep 29, 2026

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

    9d35d10
  2. qnbs
    added
    P1
    on Sep 29, 2026

  3. qnbs commented on Sep 29, 2026

    @qnbs
    qnbs
    on Sep 29, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  4. qnbs
    added a commit that references this issue on Sep 29, 2026

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

    612e659

  5. qnbs commented on Sep 30, 2026

    @qnbs
    qnbs
    on Sep 30, 2026
    OwnerAuthor

    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.

  6. qnbs commented on Sep 30, 2026

    @qnbs
    qnbs
    on Sep 30, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  7. qnbs
    added 2 commits that reference this issue on Oct 10, 2026

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

    e583691

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

    5be1b4e

  8. qnbs commented on Oct 11, 2026

    @qnbs
    qnbs
    on Oct 11, 2026
    OwnerAuthor

    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.

  9. qnbs commented on Oct 13, 2026

    @qnbs
    qnbs
    on Oct 13, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  10. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  11. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  12. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  13. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  14. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    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.

  15. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    2026-10-17 — separate status check for Dependabot alert #88 (sprintf-js)

    This remains separate from the ZIP advisories. Live Dependabot alert #88 is still open; GHSA-hp3w-g68c-fv3c still reports affected sprintf-js <=1.1.3 and no patched version. npm latest is still 1.1.3. NVD now reports CVE-2026-97058 as Rejected (last modified 2026-10-16), and the upstream alexei/sprintf.js disclosure thread says the maintainers disputed the CNA finding; this does not automatically close the still-open GitHub GHSA/alert.

    Source review confirms the two lockfile paths already described in src-tauri/osv-scanner.toml: mammoth -> argparse@1.0.10 -> sprintf-js@1.0.3, and optional @huggingface/transformers -> onnxruntime-node -> global-agent -> roarr -> sprintf-js@1.1.3. Mammoth is used for DOCX import, but its package main is lib/index.js; only its CLI entrypoint loads argparse. The repository has no first-party sprintf-js import/call. The optional ONNX Node backend remains install-script denied and the app's Vite alias selects the browser Transformers distribution. These facts reduce known reachability but do not prove the advisory false positive or the alert fixed.

    Disposition: keep the existing time-limited IgnoredVulns entry unchanged through its current 2026-11-30 review horizon; no newer package is available, and no separate remediation was identified. Do not transfer this exception to ZIP or mark alert #88 closed. No dependency, scanner-policy, or source change was made.

  16. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    2026-10-17 — current OSV result and ZIP race-prototype update

    Exact-head Security Audit run 39061065120 on #1078 head 19dfd0223ecae4da8b35c8932e1ee92ad33bd614 is red; OSV exited 1 across all three lockfiles. The scan reports 8 affected package instances / 12 advisory matches: six ZIP matches (RUSTSEC-2026-0367/0368/0369 on zip@4.6.1 and 8.6.0, fixed version listed as 9.0.0) and six instances of new unmaintained notices (RUSTSEC-2026-0370 zvariant, 0371 zbus_names, 0372 zvariant_derive). The latter have no CVSS, fixed version, or affected functions in OSV; they are not exploit reports, but the current required scanner still fails. No ignore or scanner-policy edit was made.

    The private Linux candidate now holds the extraction-root handle and applies deferred stream permissions through handle-relative openat(..., NOFOLLOW) plus fchmod. The combined stable harness passes 3/3, including both deterministic parent-replacement tests; each now refuses with NotADirectory and leaves the outside sentinel at mode 0600. ZIP4 source also checks with Rust 1.77.2 only under the experiment-only --ignore-rust-version flag after a size_of import; the package manifest itself declares 1.82. ZIP8/Candle remains blocked at the Edition-2024 resolver graph and is not qualified. No product source, lockfile, or PR was changed.

    Disposition remains PROTOTYPE_ONLY / OSV_FAIL / NO_MERGE; the candidate does not yet cover all path-based archive writes or Windows/macOS/updater/Candle behavior, and its package identity is still the OSV-flagged registry version. Exact local patch SHA-256: f5a401fe823becce73442ce4e87d44eb5380f9387a3a34f0f8deb4aaab02c92a.

  17. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    ZIP4 private prototype follow-up — 2026-10-17T19:38Z

    A new isolated test of the handle-relative stream-permission prototype now passes under Rust/Cargo 1.77.2: during central-directory processing the test replaces an extracted parent directory with a symlink to a harmless sibling; extraction refuses with NotADirectory and the sibling sentinel remains mode 0600 (1 test passed). A source check of the same ZIP4 candidate also passed under 1.77.2 with --ignore-rust-version.

    This remains prototype-only evidence. The disposable harness ignores ZIP 4.6.1's declared Rust 1.82 metadata and uses a private v3 lockfile; it does not qualify the published package, updater integration, Windows/macOS behavior, or full archive writes. ZIP8 remains unqualified at the declared floor: Cargo 1.77.2 rejects the source's Edition 2024 metadata, and the tested adapted resolver selects hashbrown 0.17.1, which also requires Edition 2024. No repository source/lockfile changed and no PR was pushed.

    The required Security Audit remains failed on exact PR #1078 head 19dfd0223ecae4da8b35c8932e1ee92ad33bd614 (run 39061065120): OSV still identifies the original ZIP package versions and reports unmaintained zvariant/zbus_names advisories. This prototype is not an OSV-recognized fix; BLOCKED_BY_GLOBAL_OSV remains.

  18. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    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.

  19. qnbs commented on Oct 17, 2026

    @qnbs
    qnbs
    on Oct 17, 2026
    OwnerAuthor

    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.

  20. qnbs commented on Oct 18, 2026

    @qnbs
    qnbs
    on Oct 18, 2026
    OwnerAuthor

    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.

  21. qnbs commented on Oct 18, 2026

    @qnbs
    qnbs
    on Oct 18, 2026
    OwnerAuthor

    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.

  22. qnbs commented on Oct 18, 2026

    @qnbs
    qnbs
    on Oct 18, 2026
    OwnerAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions