Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Rust SDK hard-codes native-tls (OpenSSL); offer a rustls TLS backend so musl/static builds work

未关闭
#1,805 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
rust

调研方向

首先检查 rust/Cargo.toml,并为 x86_64-unknown-linux-musl 运行所述的 cargo build。跟踪 reqwest 和 tokio-tungstenite 的 TLS features,然后确认所选的默认或 feature-gated backend 可以在不要求系统 OpenSSL 的情况下构建,同时保留所请求的客户端功能。

由索引模型根据 Issue 内容生成。

描述

enhancement
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:

  1. 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.
  2. 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.

主要语言
Java
星标
10.5k
派生
1.5k
平均合并
1 天 9 小时
30 天内合并 PR
130

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

github/copilot-sdk 的其他 Issue

查看 github/copilot-sdk 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。