chore(deps): resolve cargo audit advisories

[alukach]

What I'm changing

cargo audit on main reported one actual vulnerability and several soundness/yank warnings:

• RUSTSEC-2026-0258 — h2 0.4.13 is vulnerable to unbounded empty DATA frames (a resource-exhaustion DoS vector). This was the one advisory failing the CI Audit job.
• RUSTSEC-2026-0190 — anyhow 1.0.102's Error::downcast_mut() is unsound (constructs an aliased mutable reference, UB under Stacked Borrows).
• RUSTSEC-2026-0097 — rand 0.8.5/0.9.2 are unsound when a custom log logger calls into rand::rng()/rand::thread_rng() during reseeding.
• chacha20 0.10.1 was yanked from crates.io; 0.10.2 is the current release.

None of these are direct dependencies — all are pulled in transitively (h2/rand/chacha20 via reqwest/object_store, anyhow via various crates), so no Cargo.toml changes were needed, only Cargo.lock updates within existing semver ranges.

How I did it

• cargo update -p h2 --precise 0.4.16 — clears RUSTSEC-2026-0258.
• cargo update -p anyhow --precise 1.0.103 — clears RUSTSEC-2026-0190.
• cargo update -p rand@0.8.5 --precise 0.8.6 and cargo update -p rand@0.9.2 --precise 0.9.3 — clears RUSTSEC-2026-0097 for both rand lines in the tree.
• cargo update -p chacha20 --precise 0.10.2 — clears the yanked-crate warning.
• Cargo.lock also picked up a handful of multistore-* workspace-member entries moving from 0.7.1 to 0.7.2, matching the version already set in Cargo.toml/workspace.package — the lockfile was stale relative to that prior release bump and got resynced as a side effect of cargo update.
• errno, quinn-udp, rustls-platform-verifier, and winapi-util moved from windows-sys 0.60.2/0.61.2 down to 0.52.0. This isn't a regression: ring hard-pins windows-sys = "^0.52", and cargo's resolver unifies onto that shared entry once the lockfile is freshly re-resolved (confirmed — asking cargo to move the shared entry back up fails with ring's pin as the blocker). windows-sys only affects Windows builds (this project targets Linux/wasm32) and 0.52.0 carries no known advisory, so this is left as-is rather than fought.

Not fixed

• spin 0.9.8 — yanked. Pulled in transitively via lazy_static (required by rsa → multistore-oidc-provider/multistore-sts), which pins spin = "^0.9.8". The only newer release (0.10.1) is semver-incompatible with that requirement, so it can't be bumped without an upstream fix in lazy_static (or dropping it from the dependency tree). This is a yank warning, not a CVE.

Test plan

• cargo audit — no vulnerabilities; only the spin yank warning remains (unfixable, see above)
• cargo check
• cargo check -p multistore-cf-workers --target wasm32-unknown-unknown
• cargo test (default workspace members)
• cargo fmt --check
• cargo clippy -- -D warnings

[claude]

Claude finished @alukach's task in 1m 27s —— View job

---

Review complete

• Gather context (diff, PR description)
• Review Cargo.lock diff for correctness/security issues
• Apply ponytail-review lens for over-engineering
• Post final review

✅ No blocking issues — safe to merge.

The diff is a pure Cargo.lock update; checksums are consistent with the stated cargo update -p <pkg> --precise <ver> invocations and each bump matches a real advisory (h2 RUSTSEC-2026-0258, anyhow RUSTSEC-2026-0190, rand RUSTSEC-2026-0097, chacha20 yank). No Cargo.toml changes, no semver-range widening.

One non-blocking observation:

• Cargo.lock:489,1850,2121,2993 — errno, quinn-udp, rustls-platform-verifier, and winapi-util all had their windows-sys dependency downgraded from 0.61.2/0.60.2 to 0.52.0. This isn't mentioned in the PR description (which only calls out the h2/anyhow/rand/chacha20/workspace-version changes) and isn't required by any of the advisories being fixed — it looks like a resolver side-effect of the targeted cargo update -p runs picking the lowest compatible windows-sys within those crates' semver ranges. Not a security issue (Windows-only, no known CVE on 0.52.0), but worth a one-line mention in the PR body or a follow-up cargo update -p windows-sys to avoid re-fragmenting the lockfile across three windows-sys versions instead of consolidating.

Simplify (ponytail)

Nothing to flag — lockfile-only diff, no code to simplify.
· chore/cargo-audit-2026-09-01

---

💰 Estimated review cost: $0.40 · 1m26s · 25 turns

[alukach]

Deploy & Test / Smoke Test failed on 2 tests: TestRangeRequests::test_head_includes_accept_ranges and TestRangeRequests::test_range_after_full_get_still_returns_206 (both after exhausting their 4 reruns). This isn't this PR's failure — the diff here is Cargo.lock only, touching no request/header/caching code — and the identical failure (same two tests, same symptoms: missing accept-ranges, chunked response with no content-length) reproduced on the last two unrelated PRs' preview deploys too (#140, #141). It looks like a Cloudflare edge-cache propagation flake on the shared RANGE_TEST_PATH fixture object, in the same family #132 and #95 already tried to mitigate — no open PR currently addresses this further, so nothing to port in. Re-running the job once to see if it clears.

---

Generated by Claude Code

[alukach]

Re-ran cargo audit against the current main (25a90e2) as part of the scheduled audit check. It reproduces the exact same advisory set already addressed by this PR:

• RUSTSEC-2026-0258 (h2 0.4.13)
• RUSTSEC-2026-0190 (anyhow 1.0.102, unsound)
• RUSTSEC-2026-0097 (rand 0.8.5/0.9.2, unsound)
• chacha20 0.10.1 (yanked)
• spin 0.9.8 (yanked, not fixed here — see "Not fixed" above)

No new advisories beyond what's already fixed here, so skipping a duplicate PR per the scheduled task's dedup check.

---

Generated by Claude Code