-
Notifications
You must be signed in to change notification settings - Fork 595
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
Ensuring that a provider based on the one built-in is used #1920
Comments
If I submit a PR moving the Based on the naming of |
That seems like a large architectural change best done by the maintainers. What are your aims in wanting do to that? It may be worth revisiting the discussion on #1184 which proposed a similar multiple-crates solution. We didn't go that direction because a) people seemed to dislike using Cargo.toml |
Concretely, what are the failure modes you've seen? Do people pull in an extra dependency that builds a Maybe it would be feasible to ask cargo-deny if they could check for features or upstream dependency edges, so you could enforce that no crates (other than perhaps your own) rely on |
I've seen people using
Even if I was able to ensure that only my crate activates the
After reading through the discussion, I think that my proposition is different. From what I understand, people would have to choose which crate the |
This feels like a very niche concern... I think it might be better to try the avenue of getting |
I'm not so sure it is so niche, I suppose that the vast majority of people that want to customize the provider will do that based on the ones that are built-in into I don't know how |
I mean, I think you could "see" whether the optional dependency edge is enabled in |
I think there is not enough information in the Cargo.lock to differentiate the case if the feature is activated by a crate which is not the custom provider: [[package]]
name = "foo"
version = "0.1.0"
dependencies = [
"rustls",
]
[[package]]
name = "foo-custom-provider"
version = "0.1.0"
dependencies = [
"rustls",
]
[[package]]
name = "rustls"
version = "0.23.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7fecbfb7b1444f477b345853b1fce097a2c6fb637b2bfb87e6bc5db0f043fae4"
dependencies = [
"aws-lc-rs",
"once_cell",
"rustls-pki-types",
"rustls-webpki",
"subtle",
"zeroize",
] We could imagine that cargo deny support adding exception to the features ban. Maybe adding a "skip" or something like that. [[ban.features]]
crate = "rustls"
deny = ["ring", "aws-lc-rs", "aws_lc_rs"]
skip = [ { crate = "foo-custom-provider" } ] But even in that case, maybe it will just detect that the feature is not activated by anything other than the custom provider but, because of feature unification, Maybe the workaround is to separate the custom provider from the workspace to prevent feature unification and then ban the |
Checklist
Is your feature request related to a problem? Please describe.
I work on a very big project with multiple applications that uses rustls and which dependencies also use rustls. We have a custom provider based on aws-lc-rs, that we want to be used by all of our crates.
Besides, some of our dependency relies on a static provider has been installed in the current process.
My problem is sometimes, when new codes that need tls is added, the original aws-lc-rs is silently used instead of our custom one.
For instance, if in a crate someone does
rustls_platform_verifier::tls_config
without installing our custom provider before, no error will be thrown and this will use the classic aws-lc-rs providerI thought how I could detect this with some tooling, like clippy or cargo deny and I didn't figure it out.
Describe the solution you'd like
I would like that ring and aws-lc-rs provider to be moved on a separate crate. They could still be added as dependency to ruslts under feature flag to keep the current behavior.
If aws-lc-rs provider were in a separated crate, I could use this crate directly for my custom provider. I could then deny the feature aws-lc-rs and ring with cargo deny
Then if somebody forgets to install the custom provider, it will be caught thanks to a panic in
get_default_or_install_from_crate_features()
. This can work right now for providers that aren't based on ring or aws-lc-rs, but in my case I must activate the aws-lc-rs feature so I can base my custom provider on it.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Option A: force users to always use
builder_with_provider
I can tell users to not use the process default provider and add this to my clippy.toml:
The problem is that I must also scan dependencies that my use the default provider and so each time a new version is issued.
Besides we have a patched dependency which relies on the process default because it makes the patch a lot simpler.
Option B: reexport rustls and dependencies that use rustls under an inner crate
Another solution is to have an inner crate that has rustls has a private dependency and force use to use my crate with cargo deny
This requires less auditing of dependencies, because I only have to do a cargo tree to see the one that depends of rustls. In the clippy solution I would also have to check if they use
ClientConfig::builder()
internally.Additional context
I´m not a provider expert and maybe I missed something. If so I would be grateful if you can provide additional guidance. Otherwise the proposed solution, moving the providers to a crate, that I remember to have already been discussed, seems to be a reasonable option.
The text was updated successfully, but these errors were encountered: