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.

Update (2026-09-24): after merging main in (which had advanced ~3 weeks since this PR opened), Audit failed again on a new advisory published in the interim:

• RUSTSEC-2026-0285 — rustls 0.23.37 incorrectly accepts TLS 1.3 handshake messages across encryption level boundaries (medium severity, published 2026-09-14). Fixed by bumping to 0.23.45.

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 update -p rustls --precise 0.23.45 — clears RUSTSEC-2026-0285 (found after merging main). Cargo pulled aws-lc-rs/aws-lc-sys/rustls-webpki forward alongside it to satisfy rustls's updated dependency requirements.
• 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, rustls-platform-verifier, and winapi-util move from windows-sys 0.61.2 to 0.60.2 (the version socket2 already uses) as a resolver side effect of the lockfile refresh — not related to any advisory. windows-sys only affects Windows builds (this project targets Linux/wasm32) and 0.60.2 carries no known advisory, so this is left as-is. (Correction: an earlier revision of this description attributed this to ring's windows-sys = "^0.52" pin forcing a downgrade to 0.52.0 — that was accurate against the original Sept 1 diff, but main independently normalized things in the interim, ring still sits alone on its own 0.52.0 entry, and the current diff is a smaller 0.61.2→0.60.2 move unrelated to ring.)

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 28s —— View job

---

Todo

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

---

✅ No blocking issues — safe to merge.

This diff is Cargo.lock only — no application code, so the surface for correctness bugs is limited to "does the lockfile correctly encode the intended dependency bumps," which it does:

• anyhow 1.0.102→1.0.103, h2 0.4.13→0.4.16, rand 0.8.5→0.8.6 and 0.9.2→0.9.3, chacha20 0.10.1→0.10.2, rustls 0.23.37→0.23.45 all match the advisories cited in the PR description, and each entry's checksum/dependency block is internally consistent.
• windows-sys moving from 0.61.2→0.60.2 for errno, rustls-platform-verifier, and winapi-util is a resolver side effect, not a manual edit — verified windows-sys 0.52.0/0.60.2/0.61.2 all still coexist in the lockfile, consistent with the PR's explanation. This only affects Windows builds; the project targets Linux/wasm32, so no functional risk.
• multistore-* workspace members bumping 0.7.1→0.7.2 in the lockfile matches the version already set in the root Cargo.toml (version = "0.7.2", confirmed by reading it directly) — the lockfile was simply stale, not a scope-creep version bump.
• spin 0.9.8 (yanked, unfixed) is confirmed still pinned transitively via lazy_static alongside a separate spin 0.10.1 entry already in the tree — matches the "Not fixed" explanation, nothing overlooked there.

No security concerns beyond what the advisories themselves already describe (which this PR resolves), and nothing here reflects a best-practice violation — it's a clean cargo update --precise set of bumps within existing semver ranges.

Simplify (ponytail)

No findings — a lockfile-only diff has no code, abstractions, or dependencies to simplify.

---

💰 Estimated review cost: $0.37 · 1m28s · 19 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

[alukach]

Re-ran cargo audit against current main (25a90e2) as part of the scheduled audit check. It reproduces the same advisory set this PR already fixes (h2, anyhow, rand, chacha20/spin yanks), plus one new one published since this PR opened:

• RUSTSEC-2026-0285 — rustls 0.23.37, TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries (published 2026-09-14).

Since this PR's diff doesn't cover it, I opened #145 with just the rustls bump rather than duplicating the fixes already here. Once either PR merges, the other will need a quick rebase/dedup pass on Cargo.lock.

---

Generated by Claude Code

[alukach]

Today's scheduled cargo audit run (2026-09-19) against main reproduced the same advisories this PR already addresses: RUSTSEC-2026-0258 (h2), RUSTSEC-2026-0190 (anyhow), RUSTSEC-2026-0097 (rand), and the yanked chacha20 crate. Combined with #145 (RUSTSEC-2026-0285/rustls), these two PRs cover every fixable advisory from today's scan. spin 0.9.8 (yanked) remains unfixed for the reason already noted above — no change there. Not opening a duplicate PR.

Flagging for whoever merges this: Deploy & Test / Smoke Test is currently failing on this PR's head — worth checking whether that's pre-existing/flaky or related to the dependency bumps before merging.

---

Generated by Claude Code

[alukach]

Today's scheduled cargo audit run (2026-09-21) against main (25a90e2) reproduced the same advisory set this PR already fixes: RUSTSEC-2026-0258 (h2), RUSTSEC-2026-0190 (anyhow, unsound), RUSTSEC-2026-0097 (rand, unsound), and the yanked chacha20. Combined with #145 (RUSTSEC-2026-0285/rustls), these two PRs still cover every fixable advisory from today's scan. spin 0.9.8 (yanked) remains unfixed for the reason already noted above. Not opening a duplicate PR.

This PR has now been open 20 days without merging, and Audit stays red on main in the meantime. Flagging again for a human to merge (or say why not) rather than leaving this to keep recurring on future scheduled runs.

---

Generated by Claude Code

[alukach]

Ran the scheduled cargo audit check against main today (2026-09-23) and it still reports RUSTSEC-2026-0258 (h2 0.4.13, unbounded empty DATA frames) among the failures this PR addresses. No duplicate PR was opened since this one already covers it.

Flagging that this PR has been open since 2026-09-01 and CI is currently red (Smoke Test job failing). Worth a rebase/refresh and a look at the smoke test failure before merging.

---

Generated by Claude Code

[alukach]

Superseded by #145