Skip to content

chore(deps): move quinn-proto to 0.11.19 for three RustSec advisories - #251

Open
grumbach wants to merge 1 commit into
WithAutonomi:mainfrom
grumbach:chore/quinn-proto-rustsec
Open

grumbach wants to merge 1 commit into
WithAutonomi:mainfrom
grumbach:chore/quinn-proto-rustsec

Conversation

@grumbach

Copy link
Copy Markdown
Member

Linear issue

Closes V2-1518

Risk tier

  • T0 — docs / tooling / CI / pure UX-output. Repo CI only.
  • T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
  • T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
  • T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Proposed rather than asserted, as on #209. No build compiles the crate this changes, so no binary, behaviour, wire format or stored format moves. T0 would fit as well; T1 matches the precedent.

Compatibility

  • Wire: none.
  • Storage: none.
  • API: none. No manifest and no source file is touched; this is the lockfile only.

Semver impact

  • breaking
  • feature
  • fix

Test evidence

Run on this branch, one commit on top of main at f8008ef4.

  • cargo audit: exit 0, leaving only the seven warnings already allowed on main. On main's own Cargo.lock it fails with RUSTSEC-2026-0338, RUSTSEC-2026-0340 and RUSTSEC-2026-0343.
  • cargo tree --locked --all-features --target all -e normal,build,dev --prefix none --no-dedupe | sort -u: the same 606 unique package lines on main and on this branch, byte for byte, and quinn-proto is not one of them. Nothing that is compiled changes.
  • cargo metadata --locked accepts the lockfile on cargo 1.95 (MSRV), 1.98 and 1.99, and cargo update -p quinn-proto --precise 0.11.19 --dry-run finds nothing to change on any of them.
  • The checksum is the real one: hashing the cached quinn-proto-0.11.19.crate and the crates.io sparse index both give 0e750cca…, not yanked.
  • The published 0.11.17 and 0.11.19 manifests have identical dependency sections, edition and rust-version (1.85), so the entry's dependency list is still correct.
  • cargo clippy --all-targets --all-features -- -D warnings (the CI form), cargo clippy -- -D warnings, cargo fmt --all -- --check, and cargo doc --no-deps with -D warnings, with and without --all-features: clean.

The test suites were not rerun: with the compiled dependency graph unchanged, they would build and run exactly what they build and run on main.

New dependency

None. An existing lockfile entry, quinn-proto, moves from 0.11.17 to 0.11.19. No entry is added or removed.

ADR

n/a, Tier 1.

Mitigation / rollback

Revert the commit. It touches only Cargo.lock and no compiled crate, so there is nothing to migrate either way.


What this is

The Security Audit job fails on three advisories against quinn-proto 0.11.17, all fixed in 0.11.18. This takes 0.11.19, the latest 0.11 release.

  • RUSTSEC-2026-0338: a remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads.
  • RUSTSEC-2026-0340: a peer's minimum ACK delay can panic quinn-proto when ACK_FREQUENCY sending is enabled.
  • RUSTSEC-2026-0343: outgoing datagram buffer accounting can panic the sender.

They reached the RustSec database on 2026-10-12, after the last Security Audit runs on #249 and #250 passed. Since then main's lockfile fails cargo audit, and the Security Audit job fails whenever CI runs on a PR that still locks quinn-proto 0.11.17.

Why quinn-proto is in the lockfile at all

reqwest is built with json and rustls. Its rustls feature includes __rustls-aws-lc-rs, which carries the weak feature quinn?/rustls-aws-lc-rs. Cargo records the optional quinn (and so quinn-proto) in Cargo.lock for that weak feature, but only reqwest's http3 feature enables quinn, and it is off. That is why cargo audit, which reads the lockfile, reports the crate while cargo tree cannot find it.

Why the diff is two lines

cargo update -p quinn-proto also moves tempfile from getrandom 0.4.3 to 0.3.4. tempfile is compiled, and an advisory fix has no reason to change it, so that line is left as main has it. The checks above show cargo accepts the result as it stands.

`cargo audit` fails on RUSTSEC-2026-0338, RUSTSEC-2026-0340 and
RUSTSEC-2026-0343 against `quinn-proto` 0.11.17. All three are fixed in
0.11.18; this takes 0.11.19, the latest 0.11 release. They reached the
RustSec database on 2026-10-12. Since then `main`'s lockfile fails
`cargo audit`, and the Security Audit job fails whenever CI runs on a PR
that still locks `quinn-proto` 0.11.17.

`quinn-proto` is in `Cargo.lock` only. `reqwest`'s `rustls` feature carries
the weak feature `quinn?/rustls-aws-lc-rs`, and Cargo records that optional
dependency in the lockfile although `http3`, the only `reqwest` feature that
enables `quinn`, is off. The unique package lines of
`cargo tree --locked --all-features --target all -e normal,build,dev
--prefix none --no-dedupe` are the same 606 before and after this change,
none of them `quinn-proto`, so no compiled crate changes.

Only the `quinn-proto` entry changes. `cargo update -p quinn-proto` also
moves `tempfile` from `getrandom` 0.4.3 to 0.3.4, a compiled crate this fix
has no reason to touch, so that line is kept as it was. 0.11.17 and 0.11.19
declare the same dependencies, and cargo 1.95, 1.98 and 1.99 accept the
lockfile under `--locked` and find nothing to change with
`--precise 0.11.19`.

@dirvine dirvine left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed at head 989bc16. Verdict: APPROVE.

Two-line Cargo.lock change: quinn-proto 0.11.17 -> 0.11.19 (version + checksum only). Verified:

  • New checksum 0e750cca... matches crates.io for quinn-proto 0.11.19; not yanked.
  • Dependency list byte-identical to the 0.11.17 entry; hand-edit internally consistent.
  • RUSTSEC-2026-0338 / 0340 / 0343 all patched in >= 0.11.18; 0.11.19 clears them.
  • cargo metadata --locked accepts the lockfile locally.
  • CI: Security Audit, Clippy, Format, Docs, Rust 1.95 MSRV, Test (no logging) all pass. Build/Test/Storage jobs were still running at time of review — no failures observed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants