Packaging aws-lc Rust bindings (aws-lc-rs / aws-lc-sys) to replace rust-ring - Rust - Fedora mailing-lists

6 Mar 2025


      Hi all,
*tap tap* - is this thing on?
I have been working on packaging the aws-lc-rs / aws-lc-sys [0]
crates, which provide low-level cryptography Rust APIs based on
aws-lc, a BoringSSL fork maintained by Amazon [1]. I hope to be able
to replace usages of the "ring" crate [2] with it (another BoringSSL
fork, irregularly maintained by a single person), and eventually drop
the "rust-ring" package from Fedora.
I am not sure if the guidelines for "Crypto Policies" can even be
reasonably applied to low-level cryptography APIs like this (aws-lc by
default only provides symbols equivalent to OpenSSL's libcrypto.so,
but not those from libssl.so, as far as I can tell), but this is the
mandatory email to the crypto-team list according to the Crypto
Policies guidelines [3].
More details and context below the fold.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2350145
[1]: https://github.com/aws/aws-lc
[2]: https://github.com/briansmith/ring
[3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/
---
Many networking libraries for Rust (for HTTP/1,2,3, WebSockets, etc.)
support both OpenSSL and Rustls, but some only support Rustls. In
turn, many applications *only* support building with Rustls and don't
even have an option to link against OpenSSL instead. For example,
quinn (the only HTTP/3 library for Rust we have in Fedora)
hard-requires Rustls. According to the upstream project, writing an
OpenSSL backend would not be possible due to the limited APIs that
OpenSSL provides - see comments on the GitHub issue [4] I filed two
years ago.
[4]: https://github.com/quinn-rs/quinn/issues/1389#issuecomment-1200453026
So we need to support Rustls in Fedora, just because quite a few
applications we already have in Fedora hard-require it (ntpd-rs,
cargo-deny, rbw, routinator, rustup, selenium-manager, uv), and
because the Rust ecosystem seems to be unhappy with the APIs that are
provided by OpenSSL, and much happier with Rustls.
Rustls supports *two* cryptography backends: ring and aws-lc-rs (both
are based on BoringSSL with very similar interfaces). rustls < 0.22
only supported ring, rustls 0.22+ had backends for both ring and
aws-lc, with ring as the default, and with rustls 0.23, the aws-lc-rs
backend became the default. We are currently patching rustls to revert
the default back to ring because the dependencies for the aws-lc
backend are not available from Fedora (yet).
However, upstream maintenance of the "ring" crate has reached a point
where I think it is no longer a good idea to default to it, and that
we should move to aws-lc instead. The ring crate is a project with a
single maintainer, who has limited time to work on merging changes
from BoringSSL into ring and for dealing with potential security
issues. It was even temporarily marked as unmaintained [5], though the
maintainer has now withdrawn that advisory. On the other hand, aws-lc
itself and the aws-lc-rs are both official AWS / Amazon projects with
multiple people working on it.
[5]: https://rustsec.org/advisories/RUSTSEC-2025-0007.html
Rustls 0.23+ provides APIs for implementing external crypto providers,
and there are multiple third-party ones available. While there *is* an
OpenSSL-libcrypto based backend listed there, it is unofficial,
feature-incomplete, and developed out-of-tree - it would not be
possible to use this in Rustls for our purposes.
So I think migrating from "ring" to the "aws-lc-rs" backend for Rustls
(aligning with upstream defaults), and working towards dropping the
"rust-ring" package from Fedora eventually is the least bad option
here.
Fabio