build(deps): Bump quinn-proto from 0.11.14 to 0.11.16 - #180

Review — bump quinn-proto 0.11.14 → 0.11.16

Routine patch bump, safe to merge:

• Only Cargo.lock changes; quinn = "0.11" in Cargo.toml already covers this range, so no manifest churn.
• We pull quinn-proto in transitively via quinn for the asf-2.0 QUIC output — it's on the ingest path, not the decode path, so blast radius is limited.
• The 0.11.14→0.11.16 range is dependency upgrades (anyhow, rand 0.10, rustls-platform-verifier 0.7, fastbloom 0.17) plus one nice upstream robustness fix — proto: yield error on too many gaps in assembler — which hardens the QUIC reassembler against malformed/adversarial streams. Good to take.
• CI (build + decode-counts) is green.

No concerns. 👍

Review: don't merge as-is, but don't close it either — this is a security fix

Verified locally against current master (6a768a2). Summary: the bump is correct and security-relevant, but the branch is stale and merging it lands a broken Cargo.lock. Regenerate on current master instead.

1. This closes a live High-severity advisory

quinn-proto 0.11.15 patches RUSTSEC-2026-0185 / CVE-2026-25800 / GHSA-4w2j-m93h-cj5j (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): remote memory exhaustion from unbounded out-of-order stream reassembly in Assembler.

The advisory specifically calls out consumers that read from a RecvStream in order — a peer sends later fragments while withholding early ones, and the receiver buffers them unboundedly. That is exactly the shape of src/commands/ingest.rs, which runs a quinn::Endpoint::server(...) with with_no_client_auth(), accepts arbitrary inbound connections, and reads with recv.read_exact(...) in a loop. src/outputs/asf2_quic.rs is the client side.

master is still on the vulnerable 0.11.14:

name = "quinn-proto"
version = "0.11.14"
checksum = "434b42fec591c96ef50e21e886936e66d3cc3f737104fdb9b737c40ffb94c098"

So this PR is not obsolete, and it has been sitting open since 2026年07月27日 with an unauthenticated QUIC listener on the vulnerable version.

(RUSTSEC-2026-0037 and RUSTSEC-2024-0373 are already satisfied at 0.11.14.)

2. The scary-looking lockfile churn is fine — it's staleness plus a legitimate cascade

For anyone who looked at the diff and got nervous (I did): the extra churn is not dependabot regenerating lossily.

The branch's merge-base is 7a8ac7e; master has since gained the ZeroMQ output, which pulled in ~14 crates (zeromq, async-io, futures, polling, scc, ...). The branch predates that, which accounts for most of the deletions. Two-dot master..branch shows 90 insertions / 319 deletions; the three-dot diff shows 90 / 122.

The branch's own change is a coherent transitive cascade:

quinn-proto 0.11.14 → 0.11.16
rustls-platform-verifier 0.6.2 → 0.7.0
jni 0.21.1 / jni-sys → jni 0.22.4 / jni-macros
cesu8 1.1.0 → simd_cesu8 1.2.0 + simdutf8
fastbloom 0.14.1 → 0.17.0 ; rand 0.9.4 → 0.10.2
windows-sys 0.45.0 + 8 windows_* 0.42.2 dropped (obsolete jni chain)

Running cargo update -p quinn-proto --precise 0.11.16 on a clean checkout of current master reproduces exactly this add/remove/update set.

The windows-sys 0.61.2 → 0.60.2 "downgrade" is an edge re-pointing, not a removal — all refs contain both versions. rustls-platform-verifier 0.7.0 requires windows-sys ^0.60, so cargo unified the range-flexible consumers (rustix, errno, tempfile, ... which declare >=0.52, <=0.61) onto 0.60.2. Net effect is deduplication: 4 copies of windows-sys → 3, total crates 469 → 446.

3. Why it still shouldn't be merged: the lockfile merges clean and is wrong

Merging this branch into current master produces no conflict in Cargo.lock — and an invalid lockfile:

$ cargo metadata --locked
error: cannot update the lock file ... because --locked was passed to prevent this

The textual merge silently drops rand 0.9.5, rand_chacha 0.9.0, rand_core 0.9.5, which master's zeromq 0.6.0 still requires. Classic false-clean Cargo.lock merge.

This wouldn't show up as a red build, which is the worrying part: no CI job passes --locked (rust.yml, release.yml, bench.yml, and the Dockerfile all omit it), so CI would silently regenerate and go green while the committed lockfile stayed incoherent.

The branch in isolation is fine — cargo metadata --locked exit 0, cargo check --locked --no-default-features exit 0.

Recommendation

Rebase or regenerate on current master rather than merging this branch:

cargo update -p quinn-proto --precise 0.11.17

0.11.17 shipped 2026年08月17日, so 0.11.16 is already a patch behind — though 0.11.16 alone does clear the advisory. I ran the 0.11.16 form on a clean master checkout and confirmed cargo metadata --locked and cargo check --locked --no-default-features both exit 0 with rand 0.9.4 <-- zeromq 0.6.0 correctly retained. Either let dependabot rebase, or apply directly and close this PR.

Two suggestions beyond this PR

1. Add --locked to CI. It is what turns a silently-incoherent lockfile into a failing build, and it is the reason this class of problem is invisible today.
2. Add cargo audit or cargo-deny. A High-severity advisory against an internet-facing listener sat on master for ~2 months; a scheduled audit job surfaces that on day one instead of via a dependabot PR nobody triaged.

_{Scope note: the quinn upstream changelogs for 0.11.15–0.11.17 could not be fetched from this environment (GitHub API and rustsec.org are blocked by the egress proxy), so the security claim rests on the advisory-db entry and non-security changes in those releases are unreviewed.}

Generated by Claude Code