alexcrichton / curl-rust

Rust bindings to libcurl
MIT License
1k stars 234 forks source link

static link on windows is not working? #449

Closed bigdogs closed 2 years ago

bigdogs commented 2 years ago

Hi,

I build the demo code with static-ssl enabled, but the final binary is only 500kb, checked the binary dependency, there seems system ssl is linked. and open ssl is not linked to the binary.

Not sure if I miss something

image

curl = { version = "0.4.43", features = ["static-curl", "static-ssl"] }
use std::io::{stdout, Write};

use curl::easy::{Easy, SslVersion};

// Print a web page onto stdout
fn main() {
    let mut easy = Easy::new();
    easy.url("https://www.rust-lang.org/").unwrap();
    easy.ssl_version(SslVersion::Tlsv12).unwrap();
    easy.write_function(|data| {
        stdout().write_all(data).unwrap();
        Ok(data.len())
    }).unwrap();
    easy.perform().unwrap();

    println!("{}", easy.response_code().unwrap());
}
sagebind commented 2 years ago

The static-ssl crate feature only takes effect when already using OpenSSL. On Windows and macOS OpenSSL is never used, the system SSL implementation is used instead.

There is not currently a way of configuring curl-sys to use OpenSSL on Windows or macOS aside from building curl yourself with that configuration and linking to it. I can't think of a super-compelling reason to use OpenSSL on those operating systems, as the system SSL implementation is guaranteed to be always-available, and OpenSSL isn't typically desirable for its quality. Its also a tricky dependency to statically link generally.

bigdogs commented 2 years ago

Hi,

Thanks for the reference. I would like to support legacy windows, and I'm looking for a solution to replace system ssl. (BTW, Maybe we should make comipling fails if static-ssl is specified on non-supported target )

Legacy Windows and SSL
Schannel (from Windows SSPI), is the native SSL library in Windows. However, Schannel in Windows <= XP is unable to connect to servers that no longer support the legacy handshakes and algorithms used by those versions. If you will be using curl in one of those earlier versions of Windows you should choose another SSL backend such as OpenSSL.

I also checked rustls, but I have no idea to fix the certificate error , and I'm not sure rustls is a good choice for production :(

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { description: "SSL peer certificate or SSH remote key was not OK", code: 60, extra: Some("invalid peer certificate signature") }', examples\libcurl.rs:14:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
sagebind commented 2 years ago

(BTW, Maybe we should make comipling fails if static-ssl is specified on non-supported target )

If we did that, then it would be impossible to use the feature practically, since until very recently there was no way of enabling or disabling dependency features in Cargo on a per-target basis. Enabling the feature would make your crate no longer cross-platform.

I also checked rustls, but I have no idea to fix the certificate error , and I'm not sure rustls is a good choice for production :(

Rustls is definitely suitable for production, and is used in production a lot. However, I am not sure if curl's integration with rustls is production-ready yet or not. It was marked as experimental a while ago, but maybe it is ready now.

but I have no idea to fix the certificate error

Rustls does not provide any way of using the system-wide trusted root certificates out of the box, so when using rustls you must set your trusted CAs manually. This error is being returned because the default set of trusted roots is empty, and so rustls cannot verify any certificates.

To add trusted certificates, you could use ssl_cainfo_blob to set one or more certificate authorities to trust. You could combine this with rustls-native-certs, a separate crate that implements detecting and reading the trusted certificates from the operating system. Or, you could provide your own known certificates if you don't trust the operating system's native TLS stack anyway.

bigdogs commented 2 years ago

Thanks for the detailed explanation :)