feat(tls): AWS Libcrypto Support
Motivation
I want to use aws-lc-rs with tonic.
Solution
adds a feature flag tls-aws-lc in parallel to tls, removed tls feature flag dependency from tls-*-roots features
@jenr24-architect could you try to force push again to see if we can get CI to kick off again?
@jenr24-architect could you try to force push again to see if we can get CI to kick off again?
Does it have to be a force push?? It doesn't look like my last push triggered it
With this change, users can enable both ring and aws-lc-rs, and when they enable both at the same time, users will need to specify which of these they want to use as the default provider. This setting was already an exposed dependency of rustls as an interface for setting the default provider for rustls, but this was not an issue until now as only ring was supported. I think it would be needed to wrap these configuration APIs in tonic so that users can set which crypto provider to use when both are enabled in order to allow us to use rustls as an internal dependency. It also seems necessary to state that setting the default provider using rustls directly is not intended to be stable for tonic.
With this change, users can enable both
ringandaws-lc-rs, and when they enable both at the same time, users will need to specify which of these they want to use as the default provider. This setting was already an exposed dependency ofrustlsas an interface for setting the default provider forrustls, but this was not an issue until now as onlyringwas supported. I think it would be needed to wrap these configuration APIs intonicso that users can set which crypto provider to use when both are enabled in order to allow us to userustlsas an internal dependency. It also seems necessary to state that setting the default provider usingrustlsdirectly is not intended to be stable fortonic.
I had thought about this -- I initially had written some code to add ClientTlsConfig::provider(provider: rustls::CryptoProvider) and ServerTlsConfig::provider(provider: rustls::CryptoProvider) so that I could write both a connect_handles_tls_ring and connect_handles_tls_aws_lc integration test, but the scope of that change started to get out of hand.
I would be willing to add that feature, in either this or a separate PR if we're interested in adding that functionality :)
@jenr24-architect looks like there are some more CI failures
@LucioFranco The CI failure does not seem to be caused by this pull request's change. I opened #2021 to address it.
merged master after #2021 merged, this PR is ready for CI to re-run and to enter the merge queue