Windows TLS 1.3 data corruption risk with schannel 0.1.28
While investigating a Windows TLS issue, I noticed that Codex still resolves schannel 0.1.28 in both codex-rs/Cargo.lock and MODULE.bazel.lock.
On Windows, Codex's default reqwest configuration can use this dependency path: reqwest -> hyper-tls -> native-tls -> schannel
That version has a known TLS 1.3 bug in its nonblocking stream handling. When reads and writes are interleaved while application data is still buffered, a post-handshake message can cause the pending data to be sent twice. The server then receives corrupted application data
schannel 0.1.29 includes a fix for TLS 1.3 data corruption caused by buffered application data being sent twice while handling SEC_I_RENEGOTIATE:
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗