[pablodeymo]

🗒️ Description / Motivation

cargo audit against main reports 23 advisories. One of them can be triggered remotely by any peer: quinn-proto 0.11.14, the QUIC implementation behind libp2p-quic, our primary transport, is open to remote memory exhaustion from unbounded out-of-order stream reassembly (RUSTSEC-2026-0185, CVSS 7.5) and to unbounded growth of pending connection-ID retirements (RUSTSEC-2026-0339). Both need no authentication.

This PR takes every fix that already clears the 14-day publish-age cooldown and needs nothing but a lockfile change.

What Changed

Cargo.lock only, via make update UPDATE_ARGS="-p quinn-proto -p h2 -p rkyv -p crossbeam-epoch" (so the cooldown is applied):

Crate	From → to	Advisories fixed	Reachable here?
quinn-proto	0.11.14 → 0.11.19	0185, 0339 (and 0338, 0340, 0342)	Yes: 0185 and 0339 from any QUIC peer. 0342 is not (libp2p-quic disables datagrams), nor are 0340/0338 (ACK_FREQUENCY not enabled, no unordered reads)
h2	0.4.14 → 0.4.20	0258 (unbounded empty DATA frames)	Client side only (reqwest); our axum servers are HTTP/1 only
rkyv / rkyv_derive	0.8.16 → 0.8.18	0233, 0234, 0235	No: pulled in by ethrex-common, which we never feed peer-supplied archives
crossbeam-epoch	0.9.18 → 0.9.21	0204 (fmt::Pointer on an invalid pointer)	No

quinn-proto 0.11.19 adds one new transitive dependency, rand_pcg 0.10.2.

Correctness / Behavior Guarantees

• No source changes, and no change to any direct dependency's requirement in a Cargo.toml.
• Every new version is semver-compatible with the one it replaces and older than the cooldown; make cooldown-check passes.

Deliberately left out

Crate	Why not here
rustls (0285, 0346, 0348, 0349), rustls-webpki (0382), webpki-roots (0381)	The fixed rustls (≥ 0.23.45) needs rustls-webpki 0.103.16, published 2026-10-20, which is still inside the cooldown: the resolver stops at rustls 0.23.43, which fixes none of them. A follow-up after 2026-11-03 picks all three up together.
crypto-bigint 0.5.5 (0387)	Fixed only in 0.7, which needs an upstream elliptic-curve/k256 major bump.
ruint 1.18.0 (0220)	Reached through leanVM's xmss → ethereum_ssz; the fix pulls in ark-ff 0.6, so it belongs with a leanVM bump.
hickory-proto (0118, 0119), quick-xml (0194, 0195), zstd-sys (0410)	Not reachable: libp2p's DNS/mDNS transports are compiled (full) but unused, quick-xml only serves inferno's SVG output under jemalloc_pprof, and the zstd-sys issue is wasm-only.

After this PR cargo audit reports 13 advisories, none of them in quinn-proto, h2, rkyv or crossbeam-epoch.

Tests Added / Run

None added: no source touched.

• make cooldown-check: passes
• make lint: clean
• make test: 2859 passed, 0 failed
• cargo audit: 23 → 13 advisories

Related Issues / PRs

• Follow-up: rustls / rustls-webpki / webpki-roots once rustls-webpki 0.103.16 clears the cooldown (2026-11-03).

✅ Verification Checklist

• Ran make fmt — clean
• Ran make lint (clippy with -D warnings) — clean
• Ran make test (test-consensus plus test-node, at release-fast) — all passing

[github-actions]

🤖 Kimi Code Review

I'll review this PR diff focusing on the relevant changes. This appears to be primarily a dependency update in Cargo.lock with some notable downgrades and version changes that warrant attention.

Critical Issues

1. syn crate downgrade from 2.0.117 to 1.0.109 (Line 1487)

- "syn 2.0.117",
+ "syn 1.0.109",

This is a major version downgrade in the dependency tree. The syn crate is fundamental for proc macros throughout the Rust ecosystem. Downgrading from 2.x to 1.x:

• Introduces potential API incompatibilities with other crates expecting syn 2.x
• May cause duplicate syn versions in the dependency tree (both 1.x and 2.x), increasing compile times and binary size
• Could break proc macros that rely on syn 2.x features

However, I also notice syn 3.0.4 appearing at line 6253 for rkyv_derive. Having three major versions of syn (1.x, 2.x, 3.x) in the same project is a red flag for dependency bloat and potential compilation issues.

2. getrandom version split (Lines 2870-2889)

The diff shows getrandom 0.3.4 being replaced by 0.4.2 in quinn-proto, while keeping 0.3.4 elsewhere. More critically:

- "getrandom 0.3.4",
+ "getrandom 0.4.2",

getrandom is critical for cryptographic randomness in blockchain applications. Version 0.4.x has significant changes from 0.3.x. Ensure:

• The getrandom 0.4.2 properly supports all target platforms (especially wasm32-unknown-unknown if this client has browser/light-client targets)
• Check if js-sys and wasm-bindgen features are correctly gated (they moved from getrandom 0.3.4 to 0.4.2 in this diff — lines 2870-2889)

The feature migration looks correct, but verify getrandom 0.4.x's breaking changes don't affect XMSS key generation or other cryptographic operations.

3. rand upgrade from 0.9.4 to 0.10.1 (Line 5815)

- "rand 0.9.4",
+ "rand 0.10.1",

This is a major version bump with potential API changes. For a blockchain client, this affects:

• Test determinism (if any tests use rand directly)
• Any consensus-critical randomness (though getrandom is typically used for that)
• The new rand_pcg dependency (line 5996) suggests rand 0.10 uses PCG as its default algorithm

Verify: No consensus code depends on specific rand behavior, and all tests still pass deterministically.

Security Concerns

4. h2 upgrade 0.4.14 → 0.4.20 (Line 2951)

This HTTP/2 library update likely contains security fixes. The jump from .14 to .20 suggests multiple patch releases. Verify this includes any relevant security advisories for HTTP/2 implementations (Rapid Reset, CONTINUATION flood, etc.).

5. crossbeam-epoch 0.9.18 → 0.9.21 (Line 1263)

Minor version bump in concurrent memory management. Usually safe, but in blockchain code with high concurrency for attestation processing, ensure no regressions in memory ordering guarantees.

Performance & Maintenance Issues

6. socket2 downgrade 0.6.3 → 0.5.10 (Lines 3267, 5839)

- "socket2 0.6.3",
+ "socket2 0.5.10",

Downgrade in networking stack. socket2 0.6 had API improvements for async networking. Reverting to 0.5 may:

• Lose performance optimizations for QUIC/libp2p networking
• Reintroduce bugs fixed in 0.6.x

This appears forced by quinn-proto's requirements, but monitor for networking performance regressions.

7. rkyv 0.8.16 → 0.8.18 with syn 3.0.4 (Lines 6234-6253)

The rkyv serialization library (used for SSZ-like zero-copy serialization) updates with a breaking proc-macro change (syn 2.x → 3.x).

Critical for SSZ correctness: If rkyv is used in any consensus-critical serialization paths, this requires extensive testing. syn 3.x is very new and may have parsing differences that affect derived serialization implementations.

Recommendations

1. Blocker: Investigate why syn 1.0.109 appears. If this is from a stale dependency, consider updating that dependency or using cargo update -p <crate> more precisely.

2. High Priority: Run full consensus test suite, especially:

   • SSZ round-trip tests
   • XMSS signature verification tests
   • State transition tests with process_slots/process_block

3. Medium Priority: Audit getrandom 0.4.2 changelog for platform support changes affecting your deployment targets.

4. Suggestion: Pin syn to avoid triple-version bloat. Consider:

   # In Cargo.toml workspace
   [patch.crates-io]
   # Force unified syn version if possible, or accept cargo resolver's choice

5. Verify: cargo tree -d to check for duplicate versions and assess if the dependency tree is intentionally resolved or indicates version conflicts.

Summary

Severity	Issue	Location
🔴 High	syn downgrade 2→1 and introduction of 3.x	Lines 1487, 6253
🔴 High	rand 0.9→0.10 major bump	Line 5815
🟡 Medium	getrandom version split 0.3/0.4	Lines 2870-2889
🟡 Medium	rkyv with syn 3.x for derived serialization	Lines 6234-6253
🟢 Low	socket2 downgrade	Lines 3267, 5839

The Cargo.lock changes suggest this was a broad cargo update rather than targeted updates. For consensus-critical code, prefer targeted updates with explicit changelog review.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

[github-actions]

🤖 Claude Code Review

Review of PR 718: lockfile-only security bump

The change looks good. It takes the right fixes and keeps to the stated scope. I only read the diff and did not build or run cargo audit.

What I checked

• quinn-proto 0.11.14 → 0.11.19 is the important one. It closes RUSTSEC-2026-0185 and RUSTSEC-2026-0339, both remotely triggerable by any QUIC peer through libp2p-quic. This is the right fix to ship quickly.
• h2, rkyv/rkyv_derive and crossbeam-epoch are patch bumps, and the diff touches only Cargo.lock. The PR's reachability analysis (client-side h2 only, no peer-fed rkyv archives) matches what I know of the dependency graph.
• quinn-proto now uses rand 0.10 and getrandom 0.4.2, and pulls in rand_pcg 0.10.2. Both versions were already in the lockfile, and rand_pcg is the only new package. It depends only on rand_core 0.10.1, which is already present. That is acceptable.

Notes (non-blocking)

1. The resolver also moved some unrelated entries between versions that were already in the lockfile:

   • windows-sys 0.61.2 → 0.60.2 in several crates
   • socket2 0.6.3 → 0.5.10 in hyper-util, quinn and quinn-udp
   • syn 2 → 1 for data-encoding-macro
   • getrandom 0.3.4 → 0.4.2 for quinn-proto

   Most of these look like fallout from the 14-day cooldown resolver and not a real downgrade. Please confirm cargo tree -d shows no new duplicate versions beyond rand_pcg. Also confirm make cooldown-check still passes after the final lockfile. The PR description says it does.

2. rkyv_derive now pulls syn 3.0.4, a new major version in the build graph. It is a proc-macro, so it only affects build time and not the runtime attack surface. Check that it is older than the cooldown, since it is a new package version in the lockfile.

3. Because quinn-proto changed its internal RNG and getrandom major, run a quick QUIC smoke test, such as a devnet with a peer connecting over QUIC. CI unit tests may not cover the transport.

The PR documents what it leaves out and why: rustls, rustls-webpki, crypto-bigint, ruint and the unreachable crates. I agree with deferring them.

Verdict: approve, subject to the QUIC smoke test and the cooldown check from the notes.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

I only see a Cargo.lock diff in /tmp/pr_diff.txt, with no source changes. Given that scope, I don’t see consensus-logic regressions directly in fork choice, attestation validation, state transition, XMSS, or SSZ code paths. The review is mainly about dependency-lock churn and supply-chain/runtime risk.

• Looks broadly fine as a lockfile refresh, but I’d ask for one follow-up before merge: confirm this was produced by an intentional cargo update/resolver change and not accidental platform-specific churn.
• Cargo.lock:1487 downgrades syn from 2.0.117 to 1.0.109 for ethnum-intrinsics. That may be harmless if required by that crate, but downgrading proc-macro tooling in a lockfile-only PR is unusual and worth explaining in the PR description.
• Cargo.lock:2950 updates h2 from 0.4.14 to 0.4.20. Since this is network-facing code, I’d consider this a positive from a security/correctness perspective unless there was a known compatibility reason to stay pinned.
• Cargo.lock:5809 updates quinn-proto from 0.11.14 to 0.11.19, and related entries switch some socket2 edges from 0.6.3 to 0.5.10 (Cargo.lock:3267, Cargo.lock:5801, Cargo.lock:5839). For a p2p client, this deserves one validation pass because QUIC behavior changes can affect peer connectivity, path MTU handling, or retry behavior even without code changes.
• Cargo.lock:6233 and Cargo.lock:6252 bump rkyv / rkyv_derive. If any persisted on-disk or over-the-wire archived formats rely on rkyv, this should be checked carefully for backward-compatibility assumptions. I can’t confirm usage from the diff alone, but serialization crates are high-sensitivity in blockchain clients.
• Cargo.lock:1262 updates crossbeam-epoch; that is typically low risk and likely a maintenance improvement.
• Mixed windows-sys versions remain in the lockfile after this PR (0.60.2 and 0.61.2 both still appear). That’s not a correctness bug by itself, but it suggests this is not a clean normalization pass; if the intent was “refresh all transitive deps,” the result is partial and a bit noisy.

No blocking correctness bug is evident from the diff alone, but I would leave one concise review note:

• Please document what command/environment generated this lockfile update and whether quinn/reqwest smoke tests were run, since the PR changes transitive networking and serialization dependencies without corresponding source changes.

If you want, I can also do a second pass by tracing where quinn-proto and rkyv are actually used in this repo and assess whether these specific version bumps are operationally risky.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt