Review use of aws-lc for cryptography (past, present, and future) #3679
Labels
No labels
document it
fast track
meeting
next release
nonresponsive maintainer
packager revocation
pending announcement
provenpackager
python 2 exception
self contained change
stalled
Status
Accepted
Status
Duplicate
Status
Insufficient data
Status
Invalid
Status
Rejected
system wide change
updates policy exception
vote-in-progress
No milestone
No project
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fesco/tickets#3679
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Previous discussions of this topic:
The most popular, cross-platform library for doing TLS in the Rust ecosystem is Rustls. Most projects really, really don't like using OpenSSL, some avoid or hesitate to add optional support for it, and some are actively dropping support for OpenSSL backends where it was previously available.
Rustls originally only supported one library to handle the underlying cryptography - the "ring" crate, a single-developer BoringSSL fork for Rust which only receives sporadic maintenance. More recent versions have added support for aws-lc, another BoringSSL fork that is maintained and supported by a team at Amazon / AWS, and the latest stable branch defaults to using aws-lc over "ring".
The Fedora package for Rustls has a downstream patch to revert to using the "ring" crate and to drop support for aws-lc. Other packages require similar patches, since many now officially only support rustls/aws-lc with rustls/ring effectively being deprecated.
When the "ring" crate was packaged for Fedora, it did not go through the "crypto review" that was still required then. When I attempted to package aws-lc-rs (Rust bindings for aws-lc) as the modern and maintained replacement that is now preferred by default, it got blocked by this "crypto review" requirement. From my point of view, Fedora is now in the position to have the worst of both options - depending on a mostly unmaintained library for cryptography, while migrating to a library that is officially supported by AWS is blocked.
The way the aws-lc-sys / aws-lc-rs Rust crates are set up, code from aws-lc would only be available for use in Rust crates, where it would get built on demand and then statically linked into final executables. In all cases that I reviewed so far, this was limited to usage of APIs from what is equivalent to OpenSSL
libcrypto, and not any usage of APIs from the equivalent oflibssl- since the actual TLS implementations projects use is provided by Rustls, which only uses thelibcryptoAPIs.As such, any integration with the
crypto-policiesframework would need to happen at the level of Rustls, and could probably not even be reasonably integrated into the low-level cryptography APIs provided by aws-lc-sys / aws-lc-rs. It was requested that I file a request for Rustls to support system-wide cryptography policies like the ones implemented in crypto-policies in the FCR ecosystem, which I have done here: https://github.com/rustls/rustls/issues/2402What followed seems like a moving of goal posts to me: At first, the issue was about following system-wide crypto policies (which requires upstream work in Rustls), but then, inclusion of aws-lc in Fedora (even for a limited use case like this) seemed to be getting blocked by the Red Hat Crypto team on principle.
It might be worth noting that the next major version of Rustls will have fully modularized its cryptography backend code, with previously "internal", official backends (aws-lc, ring) being migrated to the same public APIs that external / third-party cryptography providers (BoringSSL, Graviola, MbedTLS, OpenSSL, RustCrypto, SymCrypt, etc.) use, which should hopefully make it easier to patch libraries and applications to a preferred cryptography backend.
Assuming that one of the two competing OpenSSL provider implementations is considered stable and feature complete enough for general use in Fedora, it might be possible to use this backend for everything that uses Rustls going forward - but this will only affect Rustls v0.24+, and will not help anything that is or will still be stuck on "older" versions - including the current stable version v0.23.
Both "ring" and "aws-lc-rs" add unique prefixes for symbols from libcrypto/libssl to avoid symbol collisions in applications that also get linked to OpenSSL (or other *ssl implementations). I don't think un-bundling aws-lc from the aws-lc-sys crate and dynamically linking it to applications would work, since it would reintroduce symbol collisions in applications that use both aws-lc and openssl (whether directly or transitively through their dependency tree).
I request that FESCo reviews usage of AWS-LC in Fedora (past, present, and future):
aws-lc-sysandaws-lc-rscrates in Fedora, primarily to replace "ring" usage via Rustls - at least until such time as using an OpenSSL libcrypto backend for Rustls is feasible.Applications that support OpenSSL backends (either via the
native-tlscrate or theopenssl/osslRust bindings for OpenSSL) will continue to use the OpenSSL backend, so this would only affect applications and libraries that do not support an OpenSSL backend at all, or have dropped OpenSSL backend support in recent versions.aws-lcin packages that use bundled dependencies.Regardless of the outcome of the previous point, I have to note that a bunch of existing Fedora packages bundle aws-lc. It looks like these packages did not initially use aws-lc when they passed package review (or the fact that aws-lc was not allowed in Fedora was missed during review), which might or might not be considered acceptable:
I'm definitely +1 to allowing the aws-lc-* rust crates to replace the previous ring create. It has the same downsides re. system crypto policies and static linking but is actively maintained... which is important for a crypto library.
As for the Rust packages that use a vendor tarball containing aws-lc, I'm more hesitant. I think the Rust SIG has a process for rebuilding all affected packages when a vulnerability is found in one of the rust-*-devel packages, but that process doesn't apply to packages that vendor dependencies.
This is correct. The Rust SIG regularly rebuilds applications to apply fixes for security issues in their statically linked dependencies, but this process doesn't cover packages that use vendored dependencies: They would all need to be patched individually - quite painfully, due to how cargo handles vendored dependencies - which is beyond what support the Rust SIG (usually it's me who handles security fixes) can provide, so applying security fixes to these packages falls onto the individual package maintainers.
I'm definitely +1 to allowing all
aws-lc-*rust crates into Fedora and doing whatever we can to eliminaterust-ring. It was the bane of my existence when I was doing Fedora Rust stuff way back in the beginning and I'd be happy to see it gone now.I think we are probably going to need to request all these packages to devendor their usage of crypto libraries. Or at least start talking to upstreams about this, because it's a serious problem.
I think we should vote on whether to approve the
rust-aws-lc-*-devellibrary packages now (that seems mostly uncontroversial and was also discussed in the previous ticket about Fedora crypto guidelines) and figure out how to handle the existing vendored copies of aws-lc separately. @decathorpe, do you want to write a concrete proposal to vote on? Or do we have a different direction in mind?For what it's worth,
rust-ringis now fairly standard to build (only requiresperlto regenerate all sources at build-time), and supports all architectures we need OOTB.rust-aws-lc-sysis less well-behaved and needs both golang and perl at build-time ...I wanted to file this ticket with all the context I have, so you all have information about why things are the way they are now, and what potential solutions might become feasible in the future - but right now, if I had to make a concrete proposal for the present, it would be:
Proposal: The aws-lc-sys and aws-lc-rs crates are allowed to be packaged for Fedora, for low-level cryptography and to enable TLS functionality via Rustls (i.e. the "ssl" feature is not provided by the aws-lc-* crates). They will replace usage of the
ringcrate whereever possible.+1
+1
I'm +1 as I think we are better off even if there's more crypto setups.
+1
+1
(including decathorpe as implicit +1)
After one week: APPROVED (+6, 0, -0)
This exception needs to be documented in the Packaging Guidelines.
Thank you! I'll submit a pull request to the packaging guidelines to document this.
I've also updated my pending review requests to the latest versions, so they should now be ready for review.
EDIT: Pull request submitted: packaging/guidelines#1566
Announced with today's meeting agenda: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LHIPD44PUJMABJZQV5ETBVC33GSOMO4H/
Also documented in the packaging guidelines now:
https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_aws_lc