You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
aws_lc_rs has a superset of the features of ring, but right now we default to using ring's types when both are specified. This was fine until #230, but that PR made it a problem. It hurts the additive nature of cargo's features, ideally the superset of both backends should work.
I see two possible solutions:
use aws_lc_rs if both ring and aws_lc_rs are specified. this does not mean that aws_lc_rs should be turned on by default, that is not a good idea. this approach works until ring gets a feature aws_lc_rs doesn't provide. I don't think this is something we need to worry about though (it's unlikely).
using both ring and aws_lc_rs if both are specified, ring in the cases where only ring related features are used, aws_lc_rs otherwise. This is manageable for rsa key generation and Support ECDSA_P521_SHA512 when using aws_lc_rs feature #241 , but becomes more complex with more complex features, like entire key pair kinds.
Personally I prefer 1 but would be ok with both. Opinions @djc@cpu?
The text was updated successfully, but these errors were encountered:
aws_lc_rs
has a superset of the features of ring, but right now we default to using ring's types when both are specified. This was fine until #230, but that PR made it a problem. It hurts the additive nature of cargo's features, ideally the superset of both backends should work.I see two possible solutions:
Personally I prefer 1 but would be ok with both. Opinions @djc @cpu?
The text was updated successfully, but these errors were encountered: