Add support for MesaLink as a TLS backend

[sagebind]

This adds support for compiling libcurl with MesaLink as the TLS backend on all platforms, disabled by default using a crate feature.

This is a potentially valuable feature for several reasons:

• MesaLink is written primarily in Rust and uses rustls under the hood, so we can benefit from the security, safety, ans performance it offers even in curl.
• Less compile-time and run-time dependencies. We can always link MesaLink statically on any supported platform, and MesaLink can be compiled with just Rust, gcc, and a few build tools installed. Curl also no longer needs openssl headers installed on the build system.

Note that using MesaLink also requires using the bundled curl version statically (e.g. the static-curl feature).

This is a work-in-progress. I've compiled and ran some binaries using a setup like this with great success so far, very smooth. The primary difficulty I am working out is how to "vendor" MesaLink like we do curl; with curl we just run the required commands inside build.rs, but MesaLink is a Rust project. Do we run Cargo commands inside build.rs inside Cargo? Right now I am using path dependencies, but those are not allowed when publishing to crates.io.

[alexcrichton]

Thanks for this!

This seems fine to add, and yeah the tricky part here is going to be the build. I'm also worried about the libstd in Rust and how we don't want to duplicate it by accident or cause it to be built twice. Ideally we'd build a crates.io shim which pulls in the C symbols for the library to use, and that way we'd ensure we only link libstd once. Otherwise calling Cargo-in-Cargo I think should probably be avoided.

Could this perhaps assume that there's a dylib pre-installed and work with that for now?

[sagebind]

That certainly could be a first iteration, though MesaLink is much more likely to be used statically linked, as it is not packaged for installation in most systems and is unlikely to be available on the target system.

[alexcrichton]

Do you know if mesalink has documentation about how to be consumed in a Rust project? I'm curious if the pieces of handling libstd and this sort of integration has been handled before.

[sagebind]

Not from what I've found, this might be the first time MesaLink would be used in this type of scenario. I decided to open an issue on their repo too to see if they have any thoughts on this use-case: mesalock-linux/mesalink#28

[sagebind]

OK, the good people over at MesaLink have published a Crates.io specific version of 1.0.0 that uses the upstream versions of Rustls and friends, with a few features disabled until a better solution arises. These features are not needed by curl, so I think it may be possible now to roll with what we have so far so that we can start experimenting with the mesalink feature.

I decided to copy and paste the generated MesaLink C headers for curl's consumption, as pulling in MesaLink as a submodule just for those headers did not seem like it was worth it to me.

I also did not artificially restrict MesaLink to any particular platforms, as in theory it should support most platforms (though not guaranteed).

[alexcrichton]

Nice! Since this is all relatively security sensitive though it seems like it'd be best if we could avoid copying the headers around. I wonder if the mesalink folks would be interested in shipping the header files with the crate itself (perhaps as part of the publication process) and then we could use the header files from the crate?

[sagebind]

Agreed, that's definitely the better solution. In theory it should be doable inside their build.rs like a typical -sys crate might. I'll go down that route first before continuing.

[alexcrichton]

👍

Looks great!

[sagebind]

OK, this PR should be ready now that MesaLink 1.1.0-cratesio has been published with everything we need.

[alexcrichton]

Nice!