Skip to content

fix(fuzz): refresh the fuzz lockfile to clear stale RUSTSEC advisories - #475

Merged
Destynova2 merged 1 commit into
mainfrom
fix/fuzz-quinn-proto-advisory
Jul 26, 2026
Merged

fix(fuzz): refresh the fuzz lockfile to clear stale RUSTSEC advisories#475
Destynova2 merged 1 commit into
mainfrom
fix/fuzz-quinn-proto-advisory

Conversation

@Destynova2

Copy link
Copy Markdown
Contributor

What

Dependabot alert #34: quinn-proto 0.11.14 (GHSA-4w2j-m93h-cj5j, high
remote memory exhaustion via unbounded out-of-order stream reassembly), in
fuzz/Cargo.lock.

The fuzz crate is a separate cargo workspace with its own lockfile
(deliberately, to not interfere with the main workspace). So none of this
session's main-lock security bumps reached it — it had drifted several
advisories behind:

crate fuzz lock (before) after
quinn-proto 0.11.14 (GHSA-4w2j-m93h-cj5j) 0.11.16
crossbeam-epoch 0.9.18 (RUSTSEC-2026-0204) 0.9.20
rsa, spin (yanked) present gone (mirrors the jsonwebtoken aws_lc_rs swap)

Fix

Regenerated the fuzz lock against grob's current Cargo.toml:

cargo update --manifest-path fuzz/Cargo.toml

It now mirrors the main resolution. Large diff because the lock was stale, not
because of broad version jumps.

Verification

  • cargo audit -f fuzz/Cargo.lockexits clean (was 1 vulnerability found + warnings)
  • cargo metadata --manifest-path fuzz/Cargo.toml --locked — resolves
  • main Cargo.lock untouched; main cargo audit still clean

Fuzz binaries are never shipped, but a stale mirror lockfile is exactly what
keeps re-triggering these alerts, so keeping it current is the actual fix rather
than dismissing the alert.

Note

fuzz/Cargo.lock isn't covered by release-plz or the main cargo update, so it
will drift again. A dedicated Dependabot ecosystem entry for /fuzz (or folding
it into the existing cargo config) would keep it current automatically — flagging
as a follow-up rather than doing it here.

🤖 Generated with Claude Code

Dependabot flagged quinn-proto 0.11.14 (GHSA-4w2j-m93h-cj5j, high — remote
memory exhaustion via unbounded out-of-order stream reassembly) in
`fuzz/Cargo.lock`. The fuzz crate is a SEPARATE cargo workspace with its own
lockfile, so none of this session's main-lock bumps reached it — it had drifted
several advisories behind (quinn-proto, crossbeam-epoch RUSTSEC-2026-0204, and
the now-removed rsa/spin from the jsonwebtoken aws_lc_rs swap).

Regenerated the fuzz lock against grob's current Cargo.toml with
`cargo update --manifest-path fuzz/Cargo.toml`. quinn-proto -> 0.11.16,
crossbeam-epoch -> 0.9.20, and the tree now mirrors the main resolution.

`cargo audit -f fuzz/Cargo.lock` exits clean (was 1 vulnerability + warnings).
Fuzz binaries are never shipped, but a stale mirror lock is exactly what keeps
re-triggering these alerts, so keeping it current is the fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@Destynova2
Destynova2 enabled auto-merge July 26, 2026 07:03
@Destynova2
Destynova2 merged commit 01ea33a into main Jul 26, 2026
25 checks passed
@Destynova2
Destynova2 deleted the fix/fuzz-quinn-proto-advisory branch July 26, 2026 07:05
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.

1 participant