chore(deps): resolve cargo audit advisories

[alukach]

What I'm changing

cargo audit on main (25a90e2) reported two actual vulnerabilities:

• RUSTSEC-2026-0285 — rustls 0.23.37 incorrectly accepts TLS 1.3 handshake messages across encryption level boundaries (medium, CVSS 5.3). Published 2026-09-14, after chore(deps): resolve cargo audit advisories #142 was opened. This is what originally failed the CI Audit job on this branch.
• RUSTSEC-2026-0258 — h2 0.4.13's unbounded empty DATA frames (resource-exhaustion DoS). Originally tracked by chore(deps): resolve cargo audit advisories #142; folded into this branch too so this PR's own Audit check is green independently.

Both are transitive dependencies (rustls via reqwest/hyper-rustls/rustls-platform-verifier; h2 via reqwest/object_store), so no Cargo.toml changes were needed — just Cargo.lock updates within existing semver ranges.

cargo audit also reports non-blocking warnings (unsound/yanked, not CVEs) for anyhow, rand, and spin. anyhow and chacha20 (yanked) are bumped below; rand and spin are not — see "Not fixed."

#142 closed: that PR tracked the same h2/anyhow/rand/chacha20 advisories; its fixes (minus rand) are folded into this branch, so #142 was closed in favor of this PR rather than merging both.

How I did it

• cargo update -p rustls --precise 0.23.45 — clears RUSTSEC-2026-0285. Pulled rustls-webpki 0.103.13 → 0.103.15 and aws-lc-rs/aws-lc-sys (rustls's crypto provider) 1.17.1 → 1.18.1 / 0.42.0 → 0.45.0 along with it.
• cargo update -p h2 --precise 0.4.19 — clears RUSTSEC-2026-0258.
• cargo update -p anyhow --precise 1.0.104 — clears the RUSTSEC-2026-0190 unsound warning.
• cargo update -p chacha20 --precise 0.10.2 — clears the yanked-crate warning.
• Cargo.lock also resynced the multistore-* workspace-member entries from 0.7.1 to 0.7.2, matching the version already set in Cargo.toml — stale-lockfile side effect, not introduced by this PR.
• errno, quinn-udp, rustls-platform-verifier, and winapi-util moved from windows-sys 0.60.2/0.61.2 to 0.52.0 as a resolver side effect (ring hard-pins windows-sys = "^0.52"). All three windows-sys versions still coexist in the lockfile — nothing dropped. Windows-only, no known advisory on 0.52.0.
• Merged main in (2026-09-25) to pick up ci: replace MinIO with RustFS as the local/CI S3 backend #148 (MinIO → RustFS in CI, since Docker Hub stopped allowing anonymous pulls of minio/minio) — this cleared the Integration Tests failures that blocked this branch for over a week.

Not fixed

• RUSTSEC-2026-0097 (rand 0.8.5/0.9.2, unsound) — a warning, not a blocking vulnerability (doesn't fail cargo audit's exit code in this repo's config). Not bumped here.
• 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. Not a CVE, just a yank warning.

Test plan

• cargo audit — RUSTSEC-2026-0285 and RUSTSEC-2026-0258 both cleared; only the rand/spin warnings remain (non-blocking, see above)
• cargo check
• cargo check -p multistore-cf-workers --target wasm32-unknown-unknown
• cargo test
• cargo fmt --check
• cargo clippy -- -D warnings
• CI on this branch: Format, Cargo Check, Cargo Check (WASM), Clippy, Unit Tests, Audit, Integration Tests all green. Deploy & Test / Smoke Test is red for a pre-existing/unrelated reason (Cloudflare edge-cache flake on the shared range-test fixture, tracked across multiple prior PRs) — documented in PR comments.

🤖 Generated with Claude Code

https://claude.ai/code/session_019j5JA1n6MdcHEUbRVnABXE

---

Generated by Claude Code

[claude]

Claude finished @alukach's task in 48s —— View job

---

Review complete

• Gather context (PR body, comments, custom instructions)
• Fetch diff against origin/main
• 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 Cargo.lock only, exactly as described: targeted --precise bumps for rustls (0.23.37 → 0.23.45, RUSTSEC-2026-0285), h2 (0.4.13 → 0.4.19, RUSTSEC-2026-0258), anyhow (1.0.102 → 1.0.104), and chacha20 (0.10.1 → 0.10.2), plus their transitive fallout (aws-lc-rs/aws-lc-sys, rustls-webpki). No Cargo.toml changes, so no semver-range surprises.

Verified the one thing worth double-checking in a lockfile-only PR — the windows-sys downgrade (errno, quinn-udp, rustls-platform-verifier, winapi-util moved from 0.60.2/0.61.2 to 0.52.0): Cargo.lock still carries all three windows-sys versions (0.52.0, 0.60.2, 0.61.2) side by side, so this is just re-pointing a few deps at an entry that already exists in the graph (via ring's ^0.52 pin), not dropping the newer versions from the lockfile. Windows-only, no advisory on 0.52.0 — non-issue.

No correctness or security concerns in the diff itself. The multistore-* workspace-member version bumps (0.7.1 → 0.7.2) are just the lockfile catching up to Cargo.toml, as already called out in the PR description, and the overlap with #142 is a merge-sequencing question, not a code issue in this diff.

Simplify (ponytail)

Nothing to flag — this is a mechanical cargo update --precise diff with no source changes, so there's no logic, abstraction, or dependency surface to simplify.

---

💰 Estimated review cost: $0.22 · 0m47s · 10 turns

[alukach]

Integration Tests failed on this PR's CI run, but it's not this PR's failure — the diff here is Cargo.lock only (rustls + transitive deps), touching no Docker/MinIO/integration-test code. The job died at the Start MinIO step, before any test ran:

Unable to find image 'minio/minio:latest' locally
docker: Error response from daemon: pull access denied for minio/minio, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

That's a Docker Hub pull failure for a base image the workflow always uses — the same job passed cleanly on main at this exact commit's parent (see run 32452418254, 2026-08-21), so this looks like a transient Docker Hub outage/rate-limit rather than a real regression. Re-running the job once to confirm.

---

Generated by Claude Code

[alukach]

The Audit check on this PR is also red, but expected — this is exactly the situation described in the PR body: cargo audit still reports the h2/anyhow/rand/chacha20 advisories that open PR #142 fixes (this PR deliberately doesn't duplicate that Cargo.lock diff) plus the pre-existing spin yank warning. Audit is red on main today for the same reason (it's the job this whole cargo-audit routine exists to clear). Nothing to fix here — it'll go green once #142 merges and this branch is rebased, or if this PR is retargeted to include #142's fixes. Not re-running it; it's a deterministic real finding, not a flake.

Re-running Integration Tests now to check the Docker Hub pull flake noted above.

---

Generated by Claude Code

[alukach]

Integration Tests failed identically on the re-run — same error, same step:

Unable to find image 'minio/minio:latest' locally
docker: Error response from daemon: pull access denied for minio/minio, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

That rules out a one-off blip. It's not this PR's failure (diff is Cargo.lock only, no CI/Docker config touched) and it's not a code regression — it's a Docker Hub anonymous-pull denial for minio/minio:latest, which the Start MinIO step in .github/workflows/ci.yml (or .github/workflows/*integration*) pulls unauthenticated. Docker Hub has been tightening anonymous-pull rate limits/gating, so this is consistent with that pulling this exact image without docker login now being refused.

No existing PR fixes this. I'm not pushing a fix here since it'd widen this PR beyond the Cargo.lock security bump — the fix belongs in the CI workflow, not this diff. Proposed patch for whoever picks it up: authenticate the docker run/docker pull step with a Docker Hub service account (docker login using a repo secret before Start MinIO), or pin/mirror the image (e.g. quay.io/minio/minio or GHCR) to avoid Docker Hub's anonymous-pull limits entirely.

I've used my one re-run per the CI-failure policy; standing down on Integration Tests and Audit (see prior comment) as not-this-PR's-to-fix. The rustls fix itself is verified locally (cargo audit, cargo check incl. wasm target, cargo test, cargo fmt --check, cargo clippy -- -D warnings all pass) and Claude's automated review already approved the diff.

---

Generated by Claude Code

[alukach]

Deploy & Test / Smoke Test failed on the same 2 tests as #142's preview deploy: TestRangeRequests::test_head_includes_accept_ranges and TestRangeRequests::test_range_after_full_get_still_returns_206 (missing accept-ranges, chunked response with no content-length). Not this PR's failure — the diff here is Cargo.lock only, no request/header/caching code touched — and it's the same Cloudflare edge-cache propagation flake on the shared RANGE_TEST_PATH fixture object already tracked on #142 (which also reproduced it, in the same family as #132/#95). No open PR fixes it further. Re-running once.

---

Generated by Claude Code

[alukach]

Deploy & Test / Smoke Test re-run failed identically (same 2 tests, same symptoms) — confirms this is the persistent pre-existing Cloudflare edge-cache flake tracked via #142, not something introduced by this Cargo.lock-only diff. I've used my one re-run for this check per policy; standing down here.

Summary of this PR's CI state: Format, Cargo Check, Cargo Check (WASM), Clippy, Unit Tests, and PR Conventional Commit Validation are all green, and Claude's automated review approved the diff. The three red checks (Integration Tests — Docker Hub pull denial, Audit — advisories already fixed by #142, Deploy & Test / Smoke Test — known CF cache flake) are all pre-existing/infra issues unrelated to this change, each documented above. Nothing further to do on this PR from my side; it's ready for human review/merge whenever convenient.

---

Generated by Claude Code

[alukach]

Today's scheduled cargo audit run (2026-09-19) against main found the same advisories already covered between this PR and #142 — nothing new, so I'm not opening a duplicate PR.

Two things worth a look before merging: this PR's own Audit check is currently failing, which looks expected — its branch was cut from main before #142 merged, so it doesn't yet include #142's h2/anyhow/rand/chacha20 fixes; it should clear once this is rebased on top of (or merged after) #142. Integration Tests and Deploy & Test / Smoke Test are also currently failing on this head — worth checking whether that's related to the rustls/aws-lc-rs bump or pre-existing.

---

Generated by Claude Code

[alukach]

Today's scheduled cargo audit run (2026-09-21) against main (25a90e2) found the same advisories already covered between this PR and #142 — nothing new. Not opening a duplicate PR.

This PR's own Audit check is still red because its branch predates #142's merge — should clear once rebased on/merged after #142. It's been open 6 days; flagging for a human to merge (or rebase) rather than letting this recur 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-0285 (rustls 0.23.37, TLS 1.3 handshake message boundary issue) 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-15 and CI is currently red (Audit + Integration Tests failing). Per the PR description, that's expected until #142 merges first — its own Audit job can't go green while main still carries the h2/anyhow/rand advisories that #142 fixes. Worth sequencing #142 first, then rebasing this one.

---

Generated by Claude Code

[alukach]

Good catches — updated the PR description to match the current diff: h2/anyhow/chacha20 are now fixed here too (folded in from #142), only rand (warning, non-blocking) and spin (yank, no fix available) remain open. Also called out the windows-sys downgrade explicitly and flagged the overlap with #142 for a human to decide how to sequence.

Audit is now green on this branch (both real vulnerabilities — h2 and rustls — are fixed). Remaining red checks (Integration Tests, Deploy & Test / Smoke Test) are the pre-existing infra issues documented earlier in this thread, unrelated to this diff.

---

Generated by Claude Code

[alukach]

Scheduled cargo audit run (2026-09-25) against main (1b63f73) found the same two advisories this PR and #142 already cover — no new advisories, so no duplicate PR opened:

• RUSTSEC-2026-0258 (h2 0.4.13 → fix ≥0.4.16)
• RUSTSEC-2026-0285 (rustls 0.23.37 → fix ≥0.23.45)

Status update worth a human look: as of the last push to each branch, #142 is now the greener of the two — its Audit, Integration Tests, Cargo Check, Cargo Check (WASM), Clippy, Unit Tests, and Format are all passing, with only Deploy & Test / Smoke Test red (the known Cloudflare edge-cache flake tracked on both PRs). This PR (#145) still has Integration Tests red (Docker Hub pull denial) in addition to that same smoke-test flake.

Both PRs fix the same advisories and now overlap in their Cargo.lock diffs (per your note above). It's been open 10 days (#142 since 2026-09-01, 24 days) — recommend merging whichever is preferred and closing the other to stop the daily re-flagging.

🤖 Generated with Claude Code

https://claude.ai/code/session_0164BBFUoSJjnJRteXFtna8c

---

Generated by Claude Code