fix(deps): clear the quick-xml DoS advisories and close the relay/ supply-chain blind spot

[runyourempire]

The premise, verified first

An audit lane claimed the quick-xml suppression in deny.toml:96-112 / .cargo/audit.toml:15-29 had gone stale. It rested on this justification:

"NO consumer in our tree has a released version against >=0.41 yet"

Confirmed false. Read straight out of the registry index (rust_version and deps per published version):

consumer	we had	latest	quick-xml req	zip req
calamine	0.25.0	0.36.1	^0.31 → ^0.41	^1.0 → ^8.6
docx-rs	0.4.20	0.4.22	^0.36 → ^0.41 (since 0.4.21)	^0.6.3 → ^8.6
plist	1.9.0	1.10.0	^0.39.2 → ^0.41	—

All three shipped support. The ignores were suppressing a live, fixable advisory pair on a parser that reads user-supplied .xlsx / .docx.

What changed

quick-xml (RUSTSEC-2026-0194 / -0195) — resolved, not re-justified. Bumping the three consumers collapses quick-xml 0.31.0 + 0.36.2 + 0.39.4 → a single 0.41.0. Both advisories stop firing on their own, so both ignores are deleted from deny.toml and .cargo/audit.toml (they had diverged; both were checked). RUSTSEC-2023-0071 (rsa) left alone as instructed.

office.rs needed no edit — and that is a verified claim, not an absence of errors:

• sheet_names() and worksheet_range() have byte-identical signatures in 0.25 and 0.36.
• Data still has exactly the same nine variants with the same payloads. cell_to_string matches it exhaustively with no wildcard arm, so an added variant could not have compiled.
• ExcelDateTime's Display impl is byte-identical (write!(f, "{}", self.value)), so DateTime cells format the same.
• Same for docx-rs: TableChild / TableRowChild are destructured irrefutably, so a new variant there could not have compiled either.

The documented decompression-bomb weakness (the 100 MB cap is on the compressed size) is untouched — separate work, not regressed.

zip — partial. zip 1.1.4 retired as hoped. zip 0.6.6 did not — it is our own direct zip = "0.6", so retiring it is an 8-major API migration across osv/cache.rs, extractors/archive.rs and embeddings_providers/fastembed.rs. No advisory attaches to it, so it is staleness, not exposure. Left as follow-up rather than smuggled into a security PR. Tree is now zip 0.6.6 (ours) + 4.6.1 (tauri-plugin-updater) + 8.6.0 (calamine/docx-rs).

relay/ — 5 vulnerabilities → 0. A TLS-terminating server with no Dependabot entry, no cargo-audit, no CI.

crate	change	advisory
rustls-webpki	0.103.9 → 0.103.14	RUSTSEC-2026-0049 / -0098 / -0099 / -0104 (cert validation)
spin	0.9.8 → 0.9.9	0.9.8 was yanked
anyhow	1.0.102 → 1.0.104	RUSTSEC-2026-0190
event-listener	5.4.1 → 5.4.2	RUSTSEC-2026-0221
rand	0.8.5 → 0.8.7	RUSTSEC-2026-0097

rsa 0.9.10 remains with no fix available, and is recorded in a new relay/.cargo/audit.toml with evidence that it is not in the build graph: it reaches Cargo.lock only via sqlx's optional mysql backend, which relay never enables — cargo tree -i rsa and cargo tree -i sqlx-mysql both report nothing to print.

Coverage, so it stops recurring. dependabot.yml gains a cargo entry for /relay (not a src-tauri workspace member, so the existing entry never saw it), and nightly-audit.yml's cargo-audit step now loops every Cargo.lock in the repo. Workflow footprint is deliberately limited to those two files — validate.yml is being reshaped by peer PRs and is untouched here.

relay/Dockerfile. cargo build --release --locked 2>/dev/null || cargo build --release silently dropped lockfile enforcement and swallowed the reason. Fallback removed. Its base image also had to move 1.82 → 1.95: the lockfile already required 1.88 via time 0.3.47 (jsonwebtoken → simple_asn1), so that image could not have built this crate at all — the fallback was hiding a hard failure, not surviving a soft one.

Two things found on the way

1. main was un-committable — independently confirmed, now fixed by #430. scripts/check-file-sizes.cjs exits 1 on src-tauri/src/analysis_rerank.rs (1032 lines against a 1000 hard limit, arrived with #423). The gate scans the whole repo rather than staged paths, so .husky/pre-commit failed for every terminal on every commit — including this one. I hit it, diagnosed it, and fixed it the same way a peer did in #430 (lift the test module into a sibling analysis_rerank_tests.rs via #[path], 1032 → 866). #430 landed first, so that commit has been dropped from this branch by rebase — this PR now contains only the dependency work. Recording it here as an independent second confirmation of both the diagnosis and the chosen fix.

2. cargo clippy --all-targets -- -D warnings does not pass on main (255 pre-existing errors at my branch point, ~all unwrap_used/expect_used in test code). This is not the gate — CI runs cargo clippy ${{ matrix.cargo-features }} -- -D warnings without --all-targets, so the numbers below are from the CI-equivalent invocation. Reported as an observation, not touched.

Verification

check	result
src-tauri cargo audit	exit 0 — zero vulnerabilities, zero warnings
src-tauri cargo deny check	exit 0 — advisories ok, bans ok, licenses ok, sources ok
relay cargo audit	exit 0 (was 5 vulns + 4 warnings + 1 yanked)
relay cargo check --locked --all-targets	clean
cargo clippy -- -D warnings (CI-equivalent, default)	exit 0
cargo clippy --features experimental -- -D warnings	exit 0
cargo fmt --check	exit 0
cargo test --lib	4300 passed, 0 failed, 10 ignored

All re-run after rebasing onto c1fd348c (#425, #426, #427, #429, #430, #431 all landed mid-flight).

--features team-sync and --features enterprise fail to compile — pre-existing rot on main (chacha20poly1305::aead::OsRng unresolved, then cascading __cmd__* macro failures), which is what #424 exists to repair. My lockfile diff touches no crypto crate. #424 is still open as of this push, and the CI clippy matrix on main still carries only the default and experimental legs — so the two legs verified above are exactly the gate.

The extractor tests were #[ignore]d and had never run

There are no .xlsx/.docx fixtures anywhere in the repo, so test_real_docx_extraction / test_real_xlsx_extraction were no-ops that returned early. To gain real confidence in an 11-minor-version parser bump I generated real OOXML documents — shared strings, an inline string, numeric and boolean cells, paragraphs and a table — confirmed both #[ignore]d tests pass against them, and separately asserted the extracted text matches the pre-bump formatting contract exactly:

=== Sheet: Budget ===        Hello from 4DA
Item | Cost                  Second paragraph
Widget | 42                  A1 | B1
Gadget | 3.50 | TRUE

That exercises every arm of cell_to_string that a document can reach (shared/inline string, integral float → 42, fractional float → 3.50, bool → TRUE) plus the docx paragraph and table paths. The scratch harness was deleted; no test-file changes ship in this PR.

Deliberately left

• zip 0.6.6 — direct dep, 8-major API migration, no advisory. Follow-up.
• office.rs decompression bomb — the 100 MB cap is on the compressed size. Out of scope, not regressed.
• --all-targets clippy backlog — pre-existing, not the CI gate.
• validate.yml — peer-owned right now, untouched on purpose.
• --features team-sync / enterprise — pre-existing rot, fix(build): repair team-sync + enterprise feature rot and gate them in CI #424's job.