Skip to content

chore(deps): move rustls to 0.23.46 for four RustSec advisories - #255

Open
grumbach wants to merge 1 commit into
WithAutonomi:mainfrom
grumbach:chore/rustls-0.23.46
Open

grumbach wants to merge 1 commit into
WithAutonomi:mainfrom
grumbach:chore/rustls-0.23.46

Conversation

@grumbach

Copy link
Copy Markdown
Member

Linear issue

Closes V2-1595

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, following how dependency patch bumps here have been tiered: #209 (h2, compiled into the node) and WithAutonomi/saorsa-transport#190 (this same rustls move, in the transport itself) were both T1. Against the template's boundary question it is a borderline call. rustls is compiled into the node, and besides the four advisory fixes 0.23.46 tightens TLS handling (stricter handshake checks, key-update and I/O fixes). It changes no Autonomi protocol message, stored data, payment logic or upgrade mechanism. It does change TLS handling in the node transport and in the reqwest client the auto-upgrader uses; the code builds unchanged on it, the local e2e suite below passes over real node-transport connections, and the upgrader's release check works over HTTPS (below). If review wants T2, it needs a dev-testnet run and a linked ADR first.

Compatibility

  • Wire: none for the Autonomi protocol and its message formats. TLS handling gets stricter: 0.23.46 rejects more malformed or nonconforming handshake and record input, and fixes key updates and I/O.
  • 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 a6e3388e, with the RustSec database at its current head (edb58f59).

  • cargo audit: no vulnerabilities, leaving only the six warnings main already has. On main's own Cargo.lock it fails with exactly RUSTSEC-2026-0346, RUSTSEC-2026-0347, RUSTSEC-2026-0348 and RUSTSEC-2026-0349.
  • cargo tree --locked --workspace --all-features --target all -e normal,build,dev --prefix none | sort -u: 818 unique lines on main and on this branch, identical except rustls v0.23.45 becoming rustls v0.23.46.
  • cargo metadata --locked accepts the lockfile on cargo 1.95 (MSRV), 1.98 and 1.99, and cargo update -p rustls --precise 0.23.46 --dry-run finds nothing to change.
  • The checksum is the real one: the cached rustls-0.23.46.crate hashes to 48e13bd8…, the same as the crates.io sparse index, and the release is not yanked.
  • The published 0.23.45 and 0.23.46 have the same dependency requirements and rust-version (1.71), so the entry's dependency list is still correct.
  • On Rust 1.99: cargo fmt --all -- --check, cargo check --all-targets --all-features --locked, cargo clippy --locked --all-targets --all-features -- -D warnings (CI's flags, plus --locked), cargo clippy --locked -- -D warnings, cargo check --lib --no-default-features --locked and cargo doc --locked --no-deps with RUSTDOCFLAGS=--deny=warnings: all clean.
  • Tests on Rust 1.99: cargo test --locked --lib --features test-utils 1188 passed; cargo test --locked --test e2e --features test-utils -- --test-threads=1 119 passed, with the suite's 3 #[ignore]d live-testnet tests skipped; cargo test --locked --test webrtc_direct_devnet 3 passed. The e2e suite runs real QUIC connections between local nodes, so it exercises the new rustls on the node's own transport.
  • Upgrade HTTPS smoke: a throwaway local example (not in this PR) calling the node's own UpgradeMonitor::check_for_updates() on this branch's lockfile, i.e. reqwest over rustls 0.23.46 to api.github.com, fetched and parsed the release list and correctly found no stable release newer than 0.23.0. The binary and signature downloads in src/upgrade/apply.rs were not run.
  • Production compatibility smoke: the ant binary from the matching ant-client branch at 33b78931 (grumbach/ant-client, chore/rustls-0.23.46, linking rustls 0.23.46) connected to the production network (six peers) and downloaded a 54,903,201-byte public file in 78.4 s. Separately, ant-node v0.21.0, v0.22.0, v0.23.0-rc.1 and v0.23.0 all lock rustls 0.23.45; the smoke log does not record which versions the peers it fetched from run. A node built from this branch has not been run against production.

New dependency

None. An existing lockfile entry, rustls, moves from 0.23.45 to 0.23.46. No entry is added or removed.

ADR

n/a, Tier 1.

Mitigation / rollback

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


What this is

The Security Audit job fails on four advisories against rustls 0.23.45, all fixed in 0.23.46. They reached the RustSec database on 2026-10-14.

  • RUSTSEC-2026-0346: the Debug impls of client session values print the TLS 1.2 master secret or TLS 1.3 resumption PSK.
  • RUSTSEC-2026-0347: after an Encrypted Client Hello rejection, buffered application data goes to the outer server.
  • RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authentication.
  • RUSTSEC-2026-0349: an unauthenticated ServerHello can make later connections to that server name use classical key exchange only.

Exposure depends on configuration. The brotli feature is off, so 0348 cannot trigger, and nothing in this repo or in the compiled crates that use rustls here (saorsa-transport, reqwest, hyper-rustls, tokio-rustls, dtls, rustls-platform-verifier, rustls-post-quantum; quinn and quinn-proto also depend on it but are lockfile-only and never compiled) enables ECH or implements a custom ClientSessionStore, so 0346 and 0347 do not apply. 0349 is the one that can apply: client session resumption is on by default, so an on-path attacker could make later connections to a server name use classical-only key exchange, as long as the genuine server accepts that share.

Why the diff is two lines

cargo update -p rustls also moves tempfile from getrandom 0.4.3 to 0.3.4. An advisory fix has no reason to change it, so that line is left as main has it, as on #251. The checks above show cargo accepts the result as it stands.

`cargo audit` fails on RUSTSEC-2026-0346, RUSTSEC-2026-0347,
RUSTSEC-2026-0348 and RUSTSEC-2026-0349 against `rustls` 0.23.45. All
four are fixed in 0.23.46. They reached the RustSec database on
2026-10-14. Since then `main`'s lockfile fails `cargo audit`, and the
Security Audit job fails whenever CI runs on a PR that still locks
`rustls` 0.23.45.

Only the `rustls` entry in `Cargo.lock` changes (version and checksum).
0.23.45 and 0.23.46 declare the same dependencies and `rust-version`,
every existing requirement on `rustls` already allows the new patch, and
the unique package lines of `cargo tree --locked --workspace
--all-features --target all -e normal,build,dev --prefix none` differ
only in the `rustls` version.

`cargo update -p rustls` also moves `tempfile` from `getrandom` 0.4.3 to
0.3.4, a crate this fix has no reason to touch, so that line is kept as
it was. Cargo 1.95, 1.98 and 1.99 accept the lockfile under `--locked`
and find nothing to change with `--precise 0.23.46`.
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