Skip to content

fix(deps): bump tokio to 1.53.3 for RUSTSEC-2026-0386 - #260

Merged
grumbach merged 1 commit into
mainfrom
nic/v2-1736-tokio-rustsec-2026-0386
Oct 27, 2026
Merged

grumbach merged 1 commit into
mainfrom
nic/v2-1736-tokio-rustsec-2026-0386

Conversation

@Nic-dorman

Copy link
Copy Markdown
Member

Linear issue

Closes V2-1736

Part of V2-1733, which tracks the same move across every affected WithAutonomi lockfile.

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.

This tier is proposed rather than asserted, and matches the earlier lockfile advisory moves (V2-1659). The change is lockfile only: tokio moves from 1.53.1 to 1.53.3, and only its version and checksum change. RUSTSEC-2026-0386 is informational ("unsound"). The safe AsyncFd constructors violate I/O safety, so closing a duplicated fd can lead to a use-after-free. It is Unix-only. The patched versions are 1.51.6 and 1.53.3 or later. No Autonomi protocol message changes.

Compatibility

  • Wire: none.
  • Storage: none.
  • API: none. No manifest or source file is touched.

Semver impact

  • breaking
  • feature
  • fix

Test evidence

cargo update --precise on cargo 1.97 also rewrote unrelated windows-sys edges, so the tokio version and checksum were edited by hand. The checksum is the one cargo itself resolved.

  • cargo metadata --locked: pass
  • cargo check --locked --all-targets: pass
  • cargo audit: RUSTSEC-2026-0386 is present before the change and gone after. No new advisories.

New dependency

none

ADR

n/a

Mitigation / rollback

Revert the single Cargo.lock commit. tokio goes back to 1.53.1.

🤖 Generated with Claude Code

tokio 1.53.1 -> 1.53.3 resolves RUSTSEC-2026-0386 (unsound
tokio::io::unix::AsyncFd; patched in >=1.51.6,<1.52.0 and >=1.53.3).

Lockfile-only: Cargo.toml keeps `tokio = "1.35"`, which already admits
1.53.3. `cargo update -p tokio --precise 1.53.3` with cargo 1.97 also
rewrote unrelated windows-sys 0.61 -> 0.52 and socket2 0.6 -> 0.5 edges,
so the tokio version and checksum were edited by hand and the diff is
limited to those two lines. No dependency edges changed.

Closes V2-1736

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@grumbach grumbach 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.

Checked at 5d10725.

  • The diff only changes tokio's version and checksum in Cargo.lock. Every other file is the same as main (a5bccf0).
  • The new checksum is the crates.io one for tokio 1.53.3. 1.53.1 is affected by RUSTSEC-2026-0386, and 1.53.3 is in the patched range (>= 1.53.3).
  • tokio 1.53.3 declares the same dependencies as 1.53.1, so the unchanged dependency list is right. cargo metadata --locked passes, and cargo tree -i tokio shows a single tokio, 1.53.3.
  • cargo update -p tokio --precise 1.53.3 on main writes the same tokio entry, but it also rewrites 10 unrelated dependency lines (6 windows-sys, 4 socket2). The hand edit avoids that drift.
  • cargo audit no longer reports RUSTSEC-2026-0386 and reports nothing new. RUSTSEC-2026-0387 (crypto-bigint 0.5.5) is also on main, so it does not come from this PR.
  • Nothing in this repo or its dependency graph calls the AsyncFd constructors that 1.53.3 deprecates.
  • Between 1.53.1 and 1.53.3, tokio ships upstream bug fixes (sync, timers, runtime shutdown, Windows child processes, DuplexStream) plus the new AsyncFd::register API. I am fine with T1 for this lockfile-only advisory fix.
  • CI on this head: 20/20 passing.

@grumbach
grumbach merged commit 02c8682 into main Oct 27, 2026
21 checks passed
@grumbach
grumbach deleted the nic/v2-1736-tokio-rustsec-2026-0386 branch October 27, 2026 08:04
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