Decide what to do about rustls defaulting to aws-lc-rs instead of ring
Diggsey opened this issue · comments
rustls
now requires aws-lc
as a default dependency, which doesn't build without a load of extra dependencies. This crate should specify default-features = false
so that end users can continue to use the ring
backend of rustls
Hi @Diggsey, welcome to ureq!
I haven't made up my mind on how to deal with this situation. ureq was built on the idea of having very few dependencies. When rustls
changed to aws-lc-rs
, I think we end up with some tough decisions. There might be some way forward I can't see, so I'm happy for input. Observations in no particular order:
- Rustls wants the application to set their process default provider, libraries like ureq should not touch this
* Rustls defaults toaws-lc-rs
and noring
, whilerustls-webpki
defaults toring
and noaws-lc-rs
(as of 23 Apr 2024).
* Ureq depends on bothrustls
andrustls-webpki
, which means if we do nothing, we get bothaws-lc-rs
andring
(which goes against the idea of having minimal amount of deps) - aws-lc-rs claims to not require
cmake
for non-fips builds as of 1.7.0 - I still see cmake as a build dep despite aws-lc-rs being 1.7.0, pulled in via
aws-lc-sys
. Unclear what they mean by (aws-lc-rs not requiring cmake)[https://github.com/aws/aws-lc-rs/blob/4216305d6fdff26d95713fad32d45d3f75b44ef5/aws-lc-sys/Cargo.toml#L54] (as of 23 Apr 2024) - Additional problems around
nasm
being required on windows
$ cargo tree -i cmake
cmake v0.1.50
[build-dependencies]
└── aws-lc-sys v0.15.0
└── aws-lc-rs v1.7.0
I've had no ureq user asking for us to upgrade to rustls 0.23 – obviously just a matter of time though. I hope we can stall and have a clearer way forward once the dust settles.
- Ureq depends on both
rustls
andrustls-webpki
, which means if we do nothing, we get bothaws-lc-rs
andring
(which goes against the idea of having minimal amount of deps)
Just on this point, I don't see any direct use of rustls-webpki
in ureq
. Maybe I missed it. Could that dependency could be dropped?
Updated my above comment to reflect this.
Rustls wants the application to set their process default provider, libraries like ureq should not touch this
Right, all ureq
needs to do is specify default-features = false
when depending on rustls
. No further changes are necessary.
If you don't want users of ureq
to need to explicitly enable the feature on rustls
then you could also choose to pass-through the features to rustls
.
Libraries in general should always be passing default-features = false
as to do otherwise prevents downstream crates from having the choice.
Libraries in general should always be passing
default-features = false
as to do otherwise prevents downstream crates from having the choice.
Yeah. I know.
Right, all
ureq
needs to do is specifydefault-features = false
That doesn't work because it make ureq unusable "out of the box". If you depend on ureq, you'd additional have to depend on rustls with a selection of backend, or ureq won't compile. I think we'll go with the advice here:
Dirkjan Ochtman:
IMO for your minimal-dependencies use case it is fine to stick with ring for the time being -- and I don't think you're the only library making that choice
That doesn't work because it make ureq unusable "out of the box". If you depend on ureq, you'd additional have to depend on rustls with a selection of backend, or ureq won't compile. I think we'll go with the rustls/rustls#1913 (comment):
You can re-expose the features from ureq
- for example, ureq
could have a default-feature which enables ring, and a separate feature which enables the aws-lc
feature of rustls
.
You can re-expose the features from
ureq
- for example,ureq
could have a default-feature which enables ring, and a separate feature which enables theaws-lc
feature ofrustls
.
True, I'm just not convinced I want to introduce more feature flags unless I absolutely have to. ureq is > 1.x.x, which means there's a kind of "contract" to be non-breaking. It's also rustls
intention that the user picks backend using CryptoProvider
and I'd like to avoid confusion how ureq would need to be configured in relation to this.
Having read up some more on aws-lc
(I never encountered it before), I find the situation perplexing. aws-lc
implements OpenSSL API, which means it already got a TLS frontend. Rustls is using the same crypto as aws-lc, but provides its own TLS API. So we got two TLS frontends for the same crypto backend.
I always thought Rustls ambition was to provide a "pure Rust" TLS implementation. The original README said "Rustls is a modern TLS library written in Rust". However, I clearly read things into that which was never stated.
With ring, it was of course never pure (it's a mix of asm/C/Rust) and from my limited understanding of crypto, many of the optimizations required for modern crypto primitives are hand written assembly, which will take a long time, if ever, to replace with any Rust equivalent (or at least the asm! macro). However I used to believe Rustls ambition was to aim towards a pure Rust TLS library.
From my (extremely Rust centric) view, aws-lc
seems like "Yet Another OpenSSL API" derivative – why I would pick that one over another (BoringSSL, LibreSSL, OpenSSL, etc) with a safe Rust wrapper? Maybe they are at the forefront of quantum resistance, FIPS or something – but clearly there are reasons people much closer to the problem see that I don't.
For me, cmake, nasm and golang (uhm, lol?) as build requirement (yes I know golang is only for FIPS) moves rustls much further away from any "pure Rust" ideals – but then again, that was probably never the goal.
Did you mean to post this on the other other issue? (I agree completely btw)
Did you mean to post this on the other other issue? (I agree completely btw)
No, I don't have the emotional bandwidth to engage and argue a case. In the other thread someone already said that it's about different prioritizations – which is of course true. I also know that everyone involved in rustls are deeply invested in Rust in many different projects. They are closer to this problem and likely have different prioritizations than me.
My comment is to document this for ureq's side, where I do get to pick the priorities. I'm perplexed (and sad), that a project I rate very highly took this turn, but I also don't have any choice that is more closely aligned with what I want. It is what it is.