Summary
The Rust crate (rust/Cargo.toml) hard-codes the OpenSSL-backed native-tls stack for its HTTP and WebSocket clients, with no way to opt into rustls:
reqwest = { version = "0.12", default-features = false, features = ["stream", "http2", "default-tls"] }
tokio-tungstenite = { version = "0.24", default-features = false, features = ["connect", "native-tls"] }
default-tls (reqwest) and native-tls (tokio-tungstenite) both pull in openssl-sys, which links the system OpenSSL on Linux. These deps were introduced with the HTTP request callback support in #1689.
Impact
- musl / fully-static targets fail to build. Cross-compiling to
*-unknown-linux-musl fails in the openssl-sys build script with Could not find openssl via pkg-config / Could not find directory of OpenSSL installation, because there is no OpenSSL sysroot for the musl target. Consumers that ship static binaries (Alpine, distroless, hardened CI) cannot build the Rust SDK without vendoring OpenSSL.
- glibc binaries gain a dynamic libssl runtime dependency. Even where the build succeeds, the resulting binary now dynamically links
libssl.so.3 / libcrypto.so.3, narrowing portability for consumers that previously shipped self-contained rustls binaries.
Request
Make the TLS backend rustls-based, or feature-gate it so consumers can choose. Two shapes:
- Default to rustls — reqwest
rustls-tls (or rustls-tls-native-roots) and tokio-tungstenite rustls-tls-native-roots. The ring / aws-lc-rs backends cross-compile to musl with no system OpenSSL, keeping the SDK OpenSSL-free out of the box.
- Expose cargo features (e.g.
native-tls vs rustls-tls) so downstreams pick a backend, while keeping native-tls available for those who want it.
Option 1 keeps the SDK cross-compilable by default; option 2 preserves choice. Happy to open a PR once you confirm the preferred shape.
Repro
With musl-tools installed:
cargo build -p <rust-sdk-crate> --target x86_64-unknown-linux-musl
fails in the openssl-sys build script.
Summary
The Rust crate (
rust/Cargo.toml) hard-codes the OpenSSL-backednative-tlsstack for its HTTP and WebSocket clients, with no way to opt into rustls:default-tls(reqwest) andnative-tls(tokio-tungstenite) both pull inopenssl-sys, which links the system OpenSSL on Linux. These deps were introduced with the HTTP request callback support in #1689.Impact
*-unknown-linux-muslfails in theopenssl-sysbuild script withCould not find openssl via pkg-config/Could not find directory of OpenSSL installation, because there is no OpenSSL sysroot for the musl target. Consumers that ship static binaries (Alpine, distroless, hardened CI) cannot build the Rust SDK without vendoring OpenSSL.libssl.so.3/libcrypto.so.3, narrowing portability for consumers that previously shipped self-contained rustls binaries.Request
Make the TLS backend rustls-based, or feature-gate it so consumers can choose. Two shapes:
rustls-tls(orrustls-tls-native-roots) and tokio-tungsteniterustls-tls-native-roots. Thering/aws-lc-rsbackends cross-compile to musl with no system OpenSSL, keeping the SDK OpenSSL-free out of the box.native-tlsvsrustls-tls) so downstreams pick a backend, while keeping native-tls available for those who want it.Option 1 keeps the SDK cross-compilable by default; option 2 preserves choice. Happy to open a PR once you confirm the preferred shape.
Repro
With
musl-toolsinstalled:fails in the
openssl-sysbuild script.