fix(security): regenerate stale fuzz lockfiles — quinn-proto 0.11.14 drops out (2 high alerts) - #285
Conversation
…rops out (closes 2 high alerts) Both dependabot 'high' alerts (#15 fuzz/, #16 rust-core/fuzz/) flag quinn-proto 0.11.14 (unbounded out-of-order streams). Investigation shows neither fuzz manifest's current dependency graph pulls in quinn at all - the vulnerable crate exists only inside stale lockfiles that cargo (stable 1.98 and the repo-pinned nightly-2026-05-15 alike) refuses on any fetch, rewriting them to the true ~400-package resolution. Regenerated both lockfiles in place with the repo's own pinned toolchain (cargo update inside fuzz/ and rust-core/fuzz/). Result: - zero quinn/quinn-proto/quinn-udp entries -> both alerts auto-close - cargo fetch --locked passes for both workspaces (verified locally) - package graphs now match the manifests (784/836 -> 398/392 packages: the surplus was orphaned entries from an earlier dependency layout) No source changes; builds that consume these locks now resolve the same graph cargo itself insists on.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (2)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
2 participants
Summary
Closes the two open high dependabot alerts:
fuzz/Cargo.lockrust-core/fuzz/Cargo.lockBoth flag
quinn-proto 0.11.14(< 0.11.15, unbounded out-of-order streams).What actually happened
quinn-protois not in either fuzz manifest's current dependency graph at all — it survives only inside lockfiles that both cargo 1.98-stable and the repo-pinnednightly-2026-05-15refuse on any fetch (they rewrite them to the true ~400-package resolution). I.e. the alerts key on orphaned lock entries.Regenerated both lockfiles with the repo's own pinned toolchain:
quinn/quinn-proto/quinn-udpentries remain → both alerts auto-closecargo fetch --lockedverified green forfuzz/andrust-core/fuzz/locallyNo source changes. If a full lock refresh is judged too risky for one PR, the narrower alternative is a one-line quinn-proto 0.11.14→0.11.15 pin — but that keeps cargo-splitting locks in place, so regeneration is the honest fix.