-
Notifications
You must be signed in to change notification settings - Fork 209
add secondary 'tls-rustls-webpki' and 'rustls-webpki' features that don't implicitly enable rustls-native-certs #4017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Here's a sample dependency closure that illustrates what I'm trying to fix:
|
…on't implicitly enable rustls-native-certs
Cc @aajtodd |
Hmm, just now seeing #3985
Sounds like there is some context I'm missing (unless maybe this was a typo, and you are referring to modifying features based on *a config flag / platform target? I'll drop you a line tomorrow, Aaron. Sounds like you have some wheels in motion that might satisfy this use case along with some grander ones. Glad to close this out if so. A feature flag just for this is a bit awkward, though still worth it if it's the best path out of requiring rustls to use openssl for pki (in my opinion). |
The context is we were/are trying to default the TLS provider to be s2n-tls for unix platforms and rustls+aws-lc for windows since s2n doesn't work on Windows. You can't do this today with feature flags alone (i.e. you can't conditionally enable different features of a dependency based on a feature flag). Instead I introduced a new crate that acts as a proxy, or you could think of it as representing the feature itself. I haven't looked at the PR in detail but I would really prefer to work on this in the context of the hyper1 work. One of the biggest changes is moving all the HTTP/TLS concerns we can into a new |
Thanks for the explanation! That makes a lot of sense to wait for hyper 1 since it solves this class of problem. I'm fine to go ahead and close this out in the meantime as it's just a small paper cut. Thanks for your eyes! |
Motivation and Context
I'm trying to remove
openssl
entirely from my package's dependency closure.Currently
aws-smithy-runtime
andaws-config
both implicitly bring in openssl, even under their respectiverustls
features, because they have defaulthyper-rustls
features enabled. That in turn enablesrustls-native-certs
, which then brings in OpenSsl.Description
I've handled this in a non-breaking manner by adding a new feature to both packages,
tls-rustls-webpki
, andrustls-webki
, respectively. I made sure to explicitly enable all default features forhyper-rustls
besidesrustls-native-certs
(which now is moved to thetls-rustls
feature only).I also added a
__rustls
feature that bothrustls/rustls-webpki
andtls-rustls/tls-rustls-webpki
resolve to, which all the conditional compilation inside application code now checks for. This is the convention I see in the hyper ecosystem.Testing
I'm publishing this as a draft for initial feedback, as I need to do more testing. Still sorting out my local build. It looks like I should check in
Cargo.lock
files as well?Related - are there any CI/CD updates needed to test the new featureset?
Checklist
.changelog
directory, specifying "client," "server," or both in theapplies_to
key..changelog
directory, specifying "aws-sdk-rust" in theapplies_to
key.It's not clear if this merits a changelog entry... probably?
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.