Make the ring dependency optional#173
Merged
Merged
Conversation
djc
reviewed
Jun 12, 2026
1e21e11 to
f0d0766
Compare
Contributor
Author
|
Thank you for the review so far! I now split it up into two commits:
|
djc
reviewed
Jun 18, 2026
For the token providers that don't sign JWTs to keep working, without a default feature, the HTTPS client must be able to pick up a crypto provider at runtime, for example through: `CryptoProvider::install_default()`. Use the `with_provider_and_*` constructors, handing them a provider from `default_provider()`: the `ring` or `aws-lc-rs` provider when the respective feature is enabled (`ring` wins when both are), otherwise the per-process default (which can error upon construction). We also now depend on `rustls` directly to pull in the `CryptoProvider`. Without this, `cargo check --no-default-features` fails to resolve the constructor: ``` error[E0599]: no method named `with_native_roots` found for struct HttpsConnectorBuilder<State>` in the current scope --> src/types.rs:40:14 | 39 | let https = HttpsConnectorBuilder::new() | - 40 | .with_native_roots() | -^^^^^^^^^^^^^^^^^ method not found in | `HttpsConnectorBuilder<WantsTlsConfig>` ```
Make the dependency on `ring` truly optional. It is still used by default through the `ring` feature, but when disabling we don't depend on the `ring` dependency anymore. This also means that the signature is now created by the configured crypto provider as opposed to unconditionally by ring, which was the case before. E.g.: Before, even without the `ring` dependency and with the `aws-lc-rs` feature enabled signing of the `JWT` token was done through the `ring` signatures. This also makes signing itself conditional on the crypto features. Closes: djc#153
f0d0766 to
2d2bc3c
Compare
Owner
|
LGTM, thanks! |
Contributor
Author
|
Thank you for the reviews! |
|
Thanks! Is it possible to tag a release with this, so downstream consumers can use it? |
Owner
|
Yup: 0.12.7. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Make the dependency on
ringtruly optional.It is still used by default through the
ringfeature, but when disabling we don't depend on theringdependency anymore.This also means that the signature is now created by the configured crypto provider as opposed to unconditionally by ring, which was the case before. E.g.: Before, even without the
ringdependency and with theaws-lc-rsfeature enabled signing of theJWTtoken was done through theringsignatures.When adding
gcp_authwithout any features enabled and without default features, it will not compile anymore and instead throw acompile_error!, which explains that we need at least one provider and how to enable it.Which was in essence already the case, look at, when compiling with
--no-default-features:Closes: #153