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
Hi Rust packagers,
this is my first time attempting to package a Rust package in Fedora.
My end goal is to package Evolution EteSync, the EteSync plugin for
Evolution:
https://gitlab.gnome.org/GNOME/evolution-etesync
Evolution EteSync requires packaging libetebase
(https://github.com/etesync/libetebase) a C client library for Etebase
which basically wraps the Rust client library etebase-rs
(https://github.com/etesync/etebase-rs) and exposes a C interface on
top of it.
So, I first looked into packaging etebase-rs crate and its dependencies
(that are not already packaged).
Running `cargo tree` gives a scarily large dependency tree.
If I limit it to direct dependencies (i.e. `cargo tree --depth 1`), the
number becomes more manageable:
etebase v0.6.1 (/home/tadej/Code/etebase-rs)
├── ed25519 v1.5.3
├── openssl v0.10.73
├── openssl-sys v0.9.109
│ [build-dependencies]
├── remove_dir_all v0.8.4
├── reqwest v0.11.27
├── rmp-serde v1.3.0
├── serde v1.0.219
├── serde_bytes v0.11.17
├── serde_repr v0.1.20 (proc-macro)
├── sodiumoxide v0.2.7
└── url v2.5.4
[build-dependencies]
└── cc v1.2.27
I have a few questions here:
1. Is there a tool that would check Fedora's dist-git and give you an
overview of which dependencies are already packaged (and at what
versions)?
2. How to handle dependencies' versions?
- For example, the current ed25519 version in Fedora is 2.2.3, but
etebase-rs requires version >=1.5.3 and <1.6.0.
- A 'safe' approach seems to require adding an additional "compat"
version for each dependency that is not satisfied?
- A 'quick' approach would be to try patching Cargo.toml with the
versions that are provided in Fedora?
- Which approach to take?
Thanks for your advice and best regards,
Tadej