Skip to content

Bump rustls to 0.23.45 for RUSTSEC-2026-0285 - #9

Closed
mattpodwysocki wants to merge 1 commit into
mainfrom
rustls-advisory
Closed

mattpodwysocki wants to merge 1 commit into
mainfrom
rustls-advisory

Conversation

@mattpodwysocki

Copy link
Copy Markdown
Contributor

The advisories job went red on every open PR at once (#3–#7), which is the shape of a new advisory rather than of a broken change.

RUSTSEC-2026-0285 was published today against rustls 0.23.44:

TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
Severity: 5.3 (medium) — Solution: Upgrade to >=0.23.45

rustls is reached through reqwest, so every HTTPS request this CLI makes was using the affected version. Nothing in this crate had to change.

The change

cargo update -p rustls. Lockfile only, and one crate — the diff is a single version line:

-version = "0.23.44"
+version = "0.23.45"

Well inside the range reqwest already declares, so no manifest edit and no semver decision.

Verified with the tool CI uses, not by reading the version number

Lockfile cargo audit --file
this branch 207 crate dependencies scanned, nothing reported
main, as a control error: 1 vulnerability found! — RUSTSEC-2026-0285

The control matters: it proves the bump is what clears it, and that no second advisory is hiding behind the first.

539 tests pass with --locked.

Merge order

This should go in first, ahead of #3–#7 — all five are failing only on this, and none of them touches Cargo.lock except #6 (rand 0.10), which will need a trivial lockfile rebase afterwards. I'll handle that.

mapbox-cli-private's main is red on the same advisory, since it audits this repo's lockfile through the oss/ submodule. It clears once this merges and the submodule pin there advances — worth doing promptly, since that pin is the only way the fix reaches the private repo's CI.

The `advisories` job went red on every open PR at once, which is the shape of
a new advisory rather than a broken change: RUSTSEC-2026-0285 was published
today against `rustls` 0.23.44 — "TLS 1.3 handshake messages incorrectly
accepted across encryption level boundaries", 5.3 medium, fixed in 0.23.45.

`rustls` is reached through `reqwest`, so every HTTPS request this CLI makes
was using the affected version, and nothing in this crate had to change.

Lockfile only, and one crate: `cargo update -p rustls` moves 0.23.44 to
0.23.45 and touches nothing else — the diff is a single `version` line.

Verified with the tool CI uses rather than by reading the version number.
Against this lockfile, `cargo audit` scans 207 crate dependencies and reports
nothing. Against `main`'s, as a control, it reports `1 vulnerability found`
and names RUSTSEC-2026-0285 — so the bump is what clears it, and no other
advisory is hiding behind it.

539 tests pass with `--locked`.
@mattpodwysocki

Copy link
Copy Markdown
Contributor Author

Closing as a duplicate of #2, which is merged.

I'd reached for the same fix before spotting that PR. Worth recording that the two derivations came out byte-identical — cargo update -p rustls on a clean checkout produced a Cargo.lock with the same sha256 as #2's branch — so there was nothing to choose between them, and #2 was first.

The verification carries over either way: cargo audit scans 207 crate dependencies against the merged lockfile and reports nothing, where main before it reported RUSTSEC-2026-0285.

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