aws
Allow overriding aws-lc with ring
Problem:
In some environments and build systems, the dependency on aws-lc makes it much more difficult to compile because now you need CMake.
Solution:
A feature flag that lets you pick if you want to use ring or aws-lc for crypto.
- Does this change what s2n-quic sends over the wire? no
- Does this change any public APIs? It would add a feature flag to the crates s2n-quic-crypto and s2n-quic
Requirements / Acceptance Criteria:
aws-lc is the default, but a feature flag (something like crypto-backend-ring) can be used to use ring instead.
Unfortunately, ring doesn't expose a libcrypto-compatible interface that can be used in the s2n-tls dependency. Instead, I would prefer to remove the CMake dependency in aws-lc-rs (see https://github.com/aws/aws-lc-rs/issues/297).
Until that is solved, the only way to avoid CMake from the s2n-quic build would be to use the rustls provider instead of s2n-tls.
Until that is solved, the only way to avoid CMake from the s2n-quic build would be to use the rustls provider instead of s2n-tls.
Unfortunately, setting provider-tls-rustls does not remove the dependency on aws-lc-rs in many situations. Using provider-address-token-default pulls in s2c-quic-crypto, which depends on aws-lc-rs on non-windows platforms here.
Before s2n-quic-crypto version 0.32, aws-lc-rs was only set for linux, but since that version, it is set for cfg(not(target_os = "windows")).
I would love the ability to use ring in s2n-quic-crypto again, since aws-lc-rs is causing build issues for me on some platforms.
We're not planning on supporting ring going forward. If there are any further build issues with aws-lc-rs, we suggest opening an issue to aws-lc. Please see this comment for more information.
