We encountered issues with builds(pi3/pi3/nuc) in CI and after short search - it seems musl builds are broken in some cases? I'm not a TLS pro but this seems like some new ring dependency or aws-lc is complicated to build, which I have a very opaque knowledge on how to solve.
This led us to switch to openssl to fix builds for now and I couldn't help but wonder is there a difference of the two in the long run? I read that rustls is the superior in terms of actual cryptography, but for whose who just want their CI to build artifacts and look at CI configs as rare as possible it's a downside.
And there is no modern posts about it, so it felt like a good moment to refresh this comparison.
Rustls has built-in optional support for two built-in cryptography libraries: ring or aws-lc-rs. The default provider used to be ring but recently changed to aws-lc-rs.
If you want to use the default aws-lc-rs provider, see their User Guide for instructions on installing its build requirements.
If you want to switch back to ring instead, you can disable the default aws-lc-rs feature and enable ring like this:
[dependencies]
rustls = { version = "0.23.7", default-features = false, features = ["ring", "logging", "std", "tls12"] }
this is nice to know, but what do I do if rustls is deep down the dependency stack like tokio or bollard?
specify rustls this way in cargo manifest of each crate I have? the aws-lc-rs way seems to not support older Pi archs if I got it right
You could submit a pull request to bollard (or other relevant dependencies) to let downstream crates enable/disable the rustls/aws_lc_rs and rustls/ring features. As an example, tokio-rustls does this already: tokio-rustls/Cargo.toml at v/0.26.0 · rustls/tokio-rustls · GitHub
It looks like it supports arm-unknown-linux-gnueabihf but not arm-unknown-linux-gnueabi.
Have you installed the required tools (CMake, libclang, and bindgen) in your build environment? What error do you get when building?
You might also need to enable the aws-lc-sys/generate_bindings feature:
Thanks you for help, but I do not really look forward to add and maintain rustls and aws-lc-sys manually to all our crates. And since I depend on it only through lapin I'll just use vendored openssl version in there for now.
FWIW with cargo-edit this is easily scriptable, so the number of crates that would need this dependency ultimately doesn't even have to matter, as long as the script can access the relevant local repos.
To be fair, I've tried rustls in the past and have found openssl easier to work with for extant crates that I'm just trying to build and also offer build options to switch between rustls and openssl.
The seeming irony of that statement isn't lost on me, but from what I've empirically and anecdotally observed, it's true.
Truth be told, part of that is also my use of Nix, which turns dependency hell into not-a-thing.
For greenfield I'd definitely pick rustls and make that work.
For greenfield I'd definitely pick rustls and make that work.
I'm generally with you here, but unfortunately in the environment where multiple teams have to collaborate and compile target being simply dropped/omitted by aws-lc-rs, I would rather use more stable approach.