3 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
le king fu
|
c5efc38e96 |
fix(deps): build the updater without its zip feature
All checks were successful
PR Check — Rust / rust (pull_request) Successful in 4m14s
Clears RUSTSEC-2026-0367, RUSTSEC-2026-0368 and RUSTSEC-2026-0369 on zip 4.6.1, which turned the daily audit.yml red at run 558 (2026-10-17) without any lockfile change. zip was compiled only for Windows, through the default `zip` feature of tauri-plugin-updater 2.10.0. It is fixed only in zip >= 9.0.0, and tauri-plugin-updater 2.14.0 still requires zip ^4, so no cargo update can reach a fix. That feature only unpacks archived update packages (.nsis.zip, .msi.zip, .AppImage.tar.gz, produced by createUpdaterArtifacts "v1Compatible"); this app ships createUpdaterArtifacts: true, whose packages are never archives. The updater is now declared without its default features, keeping rustls-tls. The lockfile loses zip, arbitrary and derive_arbitrary (666 -> 663 packages, nothing added), and tar leaves the Linux graph. tar was the canary of the suppression guard in check-rust.yml. It is replaced by webkit2gtk, Tauri's Linux webview, which keeps the property that made tar useful: a dependency present on x86_64-unknown-linux-gnu only, so finding it also proves that --target resolves conditional edges. ADR 0018, architecture.md, qa-update-cycle.md and the release skill are updated to match. Verified locally: cargo-audit 0.22.2 exits 1 on the old lock with the three IDs and 0 on the new one (663 crates, the same 12 allowed warnings); the suppression guard is green, and red with the canary swapped for tar or zip; windows-sys guard 9/9; cargo check and cargo test (267 passed) on Linux; cargo xwin check for x86_64-pc-windows-msvc is green on main (zip compiled) and on this branch (zip gone). Refs #455 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
le king fu
|
2d4caecae8 |
fix(deps): resolve the quick-xml advisories, unyank deep-link and spin
All checks were successful
PR Check — Rust / rust (pull_request) Successful in 9m23s
The removal trigger #312 was written for had already fired — I filed the issue without checking whether a newer plist existed. plist 1.10.0 ships quick-xml 0.41.0, which carries the fix, within tauri's existing bound: cargo update -p plist -> plist 1.8.0 -> 1.10.0 quick-xml 0.38.4 -> 0.41.0 So RUSTSEC-2026-0194 and -0195 are resolved rather than accepted, and leave .cargo/audit.toml the day they entered it. rsa is now the only entry, and the guard loops on that crate alone; its rationale comment is re-pointed accordingly, since it was written entirely around quick-xml/plist. Also bumps the two yanked crates (#313). tauri-plugin-deep-link 2.4.8 -> 2.4.9: upstream's 2.4.9 is a single commit, "Fix broken iOS custom URL schemes", so the defect behind the yank is iOS-only and never reached this desktop app — v0.14.0 shipping 2.4.8 was not a user-facing problem, which is why neither Security nor Fixed applies to it in the changelog. spin 0.9.8 -> 0.9.9; every 0.9.x up to 0.9.8 is yanked, which reads as a bulk yank rather than a defect. The #310 changelog bullet is amended rather than contradicted: it sits in the same unreleased section and would otherwise ship two opposing claims in the same release notes. Two of its statements were wrong. It said three advisories remained (now one), and it said tar sits on "real code paths in the shipped app" — tar is compiled, but its vulnerable extraction path is only reached by the AppImage and macOS installers this project does not bundle. The rustls-webpki half stands: TLS runs on every update check. ADR 0018's decision is untouched; an amendment header marks the passages that are now historical, including the "override is impossible" alternative, which plist 1.10.0 made false the same day. cargo audit from the repo root: 0 vulnerabilities, warnings 23 -> 21 (the two yanked ones). From src-tauri/ it reports 1 — that is the cwd sensitivity of .cargo/audit.toml, not a regression. Guard: 2 checks + canary, exit 0. cargo check + cargo test green (106 tests). Lock diff: 4 packages, 666 before and after. Resolves #312 Resolves #313 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
le king fu
|
f4b09b028e |
fix(deps): clear 6 reachable RustSec advisories, accept 3 unreachable ones
cargo update -p rustls-webpki -p tar moves rustls-webpki 0.103.9 -> 0.103.13 and tar 0.4.44 -> 0.4.46, both within the existing Cargo.toml bounds. They sit under tauri-plugin-updater, which downloads and unpacks application updates, so all six of their advisories were reachable in the shipped binary. The remaining three can neither be fixed nor reached. quick-xml (2x 7.5 high) is pulled by plist, which tauri only needs for Apple bundling: its per-target trees are empty for both shipped targets and it appears solely under x86_64-apple-darwin. Its fix is >= 0.41.0 while plist requires ^0.38, a semver-incompatible boundary [patch.crates-io] cannot cross. rsa has no published fix at all and is never compiled — its only parent is sqlx-mysql, an artifact of sqlx's multi-backend graph on a SQLite project. Leaving those three to red the daily gate forever would reproduce the signal loss that #232 removed the `|| true` to fix, so they move into a versioned .cargo/audit.toml. Entries are keyed by advisory ID, never by crate, so a new advisory against the same crate still reds the gate; each carries its reachability proof and its removal condition. A blocking step in check-rust.yml re-proves that justification on every PR touching src-tauri/ or .cargo/, and fails if a suppressed crate enters a shipped target's graph — the scenario that would rot the list is itself a src-tauri change. It separates cargo tree's exit status from its output (an absent crate and a failed invocation both print nothing) and asserts a canary crate is still found, so its silence proves something. cargo audit: 9 vulnerabilities -> 0, warnings unchanged at 23 (cargo-audit 0.22.2, advisory-db 0bfde9d6 of 2026-07-27). cargo check + cargo test green (106 tests); npm build + 871 vitest green. Resolves #310 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |