Repository navigation
fix(deps): take the rustls fix for RUSTSEC-2026-0285 - #445
Merged
Merged
Conversation
rustls before 0.23.45 accepts TLS 1.3 handshake messages across an encryption-level boundary instead of terminating the connection with an `unexpected_message` alert, as RFC 8446 section 5.1 requires. The transcript stays authenticated, so this is a conformance defect rather than a break of authentication, but a peer can send in plaintext handshake messages that belong after the key change and rustls will not reject them. It reaches us through `ureq`: a runtime dependency whose only caller is the enrichment layer's HTTPS client, and a build dependency where `build.rs` fetches the SPA's vendored JavaScript under the `spa` feature that released binaries enable. The SHA pinning bounds the build-time half, since altered bytes fail the digest check rather than being embedded. Lockfile only -- `rustls` 0.23.40 -> 0.23.45 and `rustls-webpki` 0.103.13 -> 0.103.15 are patch releases inside the range already requested, so no manifest changes. This is why `cargo-deny` has been failing: the identical commit ccf6340 passed the gate on 2026-09-14 and failed it on 2026-09-21 and 2026-09-28, so `main` has been red on a published advisory rather than on any change, and every open pull request inherits that failure. Verified by probe -- `cargo deny check advisories` reproduces RUSTSEC-2026-0285 on the old lockfile and reports `advisories ok` on the new one. Claude-Session: https://claude.ai/code/session_01LRZ8yoFPCFgfZ8raBUeDeP
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.
mainhas been red for two weeks, and not because of anything anyone merged.Diagnosis
The
cargo-denyjob fails on RUSTSEC-2026-0285. The proof that this istime-based rather than change-based is that the identical commit flipped
verdict:
cargo-denyccf6340bccf6340bccf6340bccf6340bThe advisory was published between the 14th and the 21st. Every open pull
request inherits the failure, which is why the Dependabot runs look broken —
neither #442 nor #444 caused it, and #442 does not contain
rustls, somerging it would not clear it either.
The advisory
rustls before 0.23.45 accepts TLS 1.3 handshake messages across an
encryption-level boundary rather than terminating with an
unexpected_messagealert, as RFC 8446 §5.1 requires. The handshake transcript stays authenticated,
so a network-position attacker cannot alter or complete a handshake — it is a
conformance defect, not an authentication break, and the same bug as Go's
CVE-2025-61730.
It reaches us through
ureq, in two places:[dependencies], whose only caller isenrichment/client.rs, the advisory narrative layer's HTTPS client. Exposureis limited to runs that opt into narratives and contact a model endpoint.
[build-dependencies], wherebuild.rsfetches the SPA'svendored JavaScript under the
spafeature that released binaries enable.The SHA pinning bounds this half: altered bytes fail the digest check rather
than being embedded.
The fix
Lockfile only.
rustls0.23.40 → 0.23.45 andrustls-webpki0.103.13 →0.103.15 are patch releases inside the range already requested, so no manifest
change is needed.
Verification
cargo deny check advisoriesreproducesRUSTSEC-2026-0285 on the old lockfile and reports
advisories okon the newone — so the pass comes from the bump, not from a stale local advisory DB.
cargo deny check—advisories ok, bans ok, licenses ok, sources ok.cargo clippy --workspace --all-targets --all-features -- -D warningsclean.cargo fmt --all --checkclean.Once this lands, #442 and #444 need their branches updated to pick it up
before their own
cargo-denywill go green.https://claude.ai/code/session_01LRZ8yoFPCFgfZ8raBUeDeP