Repository navigation
Conversation
rustls-ffi defaults to aws-lc-rs, which needs cmake (and a C/C++ toolchain for the target) at build time and seeds its RNG from CPU jitter at startup. The jitter seeding alone costs hundreds of milliseconds of CPU per process on slow ARM cores, which matters for short-lived programs; the cmake requirement makes cross-compiling, for example to a static musl target, harder than it needs to be. `rustls-ring` selects rustls-ffi's `ring` feature instead. ring is pure Rust plus assembly, builds with cargo alone, and has no startup cost. rustls-ffi's default features are now off in curl-sys and the `rustls` feature enables them explicitly (`aws-lc-rs` and `prefer-post-quantum`), so existing `rustls` users get exactly the provider they had before. The C side is the same for both features, so `rustls-ring` compiles the same vtls backend.
With `static-curl`, the bundled libcurl has no compiled-in CA bundle
path. For OpenSSL the crate handles that by probing the system
certificate locations with openssl-probe and setting CURLOPT_CAINFO /
CURLOPT_CAPATH on every easy handle. The rustls backend was left out,
although it reads its roots from the same options: libcurl only falls
back to rustls' platform verifier when CURLSSLOPT_NATIVE_CA is set,
and without either it builds a client config with no verifier at all.
A `rustls` + `static-curl` build therefore failed every HTTPS request
unless the program set `cainfo` itself:
SSL connect error (35): failed to build client config: no server
certificate verifier was configured on the client config builder
Run the probe for the rustls backends as well. With it the `https`
example works on both `rustls` and `rustls-ring` with `static-curl`.
This was referenced Oct 10, 2026
CarloTUM
added a commit
to CarloTUM/curlite-bench
that referenced
this pull request
Oct 11, 2026
The rustls-ring feature is sagebind/curl-rust#687; the minimal feature (an HTTP(S)-only libcurl, used by build-lean.sh) is not proposed upstream and lives on the fork branch rustls-ring-minimal. Both come in through [patch.crates-io] pinned to a commit, which drops the 801 vendored files and makes it clear which numbers depend on what.
This branch has not been deployed
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.
Two small changes for people who build libcurl statically on the rustls backend.
1.
rustls-ring: rustls on ring instead of aws-lc-rsrustls-ffi defaults to aws-lc-rs, which needs cmake and a C/C++ toolchain for the target at build time, and seeds its RNG from CPU jitter at startup. On a slow ARM core that seeding costs hundreds of milliseconds of CPU per process, which matters for short-lived programs. Measured on a Cortex-A53 (Orange Pi Zero 2W, Debian 13), one
GET https://per process, CPU time:rustls+static-curl(aws-lc, jitter entropy on)rustls+static-curl,AWS_LC_SYS_NO_JITTER_ENTROPY=1at build timerustls-ring+static-curlThe env var is a workaround one has to know about; ring builds with cargo alone (no cmake, which also makes a static musl cross build a one-liner) and has no startup cost.
rustls-ringselects rustls-ffi'sringfeature. To make that possible, rustls-ffi's default features are turned off in curl-sys and the existingrustlsfeature enables them explicitly (aws-lc-rs,prefer-post-quantum), so currentrustlsusers get exactly the provider they had. The C side is the same for both features.cargo tree --no-default-features --features rustls-ring,static-curlcontains noaws-lc-rsorcmake.2. Probe for CA paths on static rustls builds
With
static-curlthe bundled libcurl has no compiled-in CA bundle path. For OpenSSL the crate probes the system certificate locations with openssl-probe and setsCURLOPT_CAINFO/CURLOPT_CAPATHon every handle; the rustls backend was left out, although it reads its roots from the same options. libcurl only falls back to rustls' platform verifier whenCURLSSLOPT_NATIVE_CAis set, and without either it builds a client config with no verifier. Sorustls+static-curlfailed every HTTPS request unless the program setcainfoitself:This runs the probe for the rustls backends as well. It is a separate commit, since it is an independent fix for the existing
rustlsfeature.Tested
On Linux x86_64, with
static-curl:--features rustls-ring:examples/httpsfetches https://example.com,cargo testpasses.--features rustls(aws-lc):examples/httpsfetches https://example.com.--features rustls-ringwithout the second commit:examples/httpsfails with the error above.