Comments (12)
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.
from ureq.
- 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?
from ureq.
@ctz Yes I believe it can! Thank you for pointing it out!
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?
from ureq.
Updated my above comment to reflect this.
from ureq.
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
.
from ureq.
Libraries in general should always be passing default-features = false
as to do otherwise prevents downstream crates from having the choice.
from ureq.
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
from ureq.
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
.
from ureq.
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.
from ureq.
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.
from ureq.
Did you mean to post this on the other other issue? (I agree completely btw)
from ureq.
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.
from ureq.
Related Issues (20)
- Timeout not working when having packet losses HOT 1
- Support Multipart Forms HOT 1
- Timeout not always respected HOT 5
- Invalid transformation to http::Response<Vec<u8>> for non utf8 response bodies HOT 3
- Example of requesting a continuous stream HOT 1
- Timeout not taking in consideration TimeoutConnect HOT 2
- ureq 2.9.3 fails to compile with errors in `hoot` HOT 3
- `ureq` 2.9.3 compilation fails due to `hoot` requiring rustc 1.65 HOT 4
- Keep-alive is disabled when using SOCKS HOT 1
- Update requirement of `url=2.3.1` HOT 3
- hootbin is a required dependency HOT 2
- Stream panics in drop during test
- Redirect history not available HOT 2
- Add support for configuring default headers in AgentBuilder HOT 1
- Potential to modify ordering for IS_TEST in lib module HOT 1
- Change `send_json` `data` argument HOT 4
- Add `Error::as_response` HOT 3
- Middleware cannot modify query string parameters? HOT 2
- Agent should be able to accept `http::Request` HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ureq.