Copilot commented on code in PR #3638: URL: https://github.com/apache/thrift/pull/3638#discussion_r3594427837
########## doc/thrift-threat-model.md: ########## @@ -1308,10 +1308,12 @@ The claim is correct for Go: validation is on by default, and the system store i InsecureSkipVerify: true in their *tls.Config, which is outside Thrift's control. --- -Rust — No TLS support +Rust — Validation is controlled by the supplied rustls configuration -The Rust library (lib/rs/src/transport/socket.rs) implements only plain TCP via TcpStream. There is no TSSLSocket type, no TLS transport, and no SSL dependency. The claim is -inapplicable. +When the optional `rustls` feature is enabled, `TTlsClientChannel` requires the caller to supply an `Arc<ClientConfig>` and a `ServerName`. The handshake, chain validation, +and server-name verification complete before `connect()` returns. `TTlsServerChannel` and `TServer::listen_tls()` similarly require an `Arc<ServerConfig>`; client-certificate +authentication is whatever that configuration selects. Thrift does not construct a default configuration or automatically load system roots, so there is no implicit trust-store +fallback. Applications may also supply rustls custom verifiers; their behavior is outside Thrift's control. Review Comment: The threat-model text currently states that certificate chain validation and server-name verification always complete before `TTlsClientChannel::connect()` returns. That’s only true insofar as the supplied `ClientConfig` (and its verifier) actually performs those checks; rustls custom verifiers can change/disable validation. Please rephrase to make it clear that verification behavior is controlled by the provided rustls configuration. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
