Bump rustls to 0.23.45 for RUSTSEC-2026-0285 - #9
Closed
mattpodwysocki wants to merge 1 commit into
Closed
mattpodwysocki wants to merge 1 commit into
mattpodwysocki wants to merge 1 commit into
Conversation
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`.
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 — The verification carries over either way: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
advisoriesjob 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
rustls0.23.44:rustlsis reached throughreqwest, 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 singleversionline:Well inside the range
reqwestalready declares, so no manifest edit and no semver decision.Verified with the tool CI uses, not by reading the version number
cargo audit --filemain, as a controlerror: 1 vulnerability found!— RUSTSEC-2026-0285The 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.lockexcept #6 (rand 0.10), which will need a trivial lockfile rebase afterwards. I'll handle that.mapbox-cli-private'smainis red on the same advisory, since it audits this repo's lockfile through theoss/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.