Rust August 2025

rust@lists.fedoraproject.org

3 participants
5 discussions

Packaging aws-lc Rust bindings (aws-lc-rs / aws-lc-sys) to replace rust-ring
by Fabio Valentini 27 Oct '25

27 Oct '25

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

2 2

First three beginner questions
by troels＠arvin.dk 01 Sep '25

01 Sep '25

Hello, I would like to propose the following tool as a Fedora page: https://gitlab.com/troelsarvin/topnfiles/ I have RPM-packaged other software before, but never Rust-based software. So I have some questions. I've been reading https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ where I'm wondering: It states "The RPM macros that provide basic functionality for building Rust code are included in rust-rpm-macros". What's "rust-rpm-macros", I cannot find such a package. When I run "rust2rpm ." in my Git clone, I get the following error: ERROR: 400 Client Error: Bad Request for url: https://crates.io/api/v1/crates/7.0.0/download And then I have a general question: Does packing for Fedora require that the software exist on crates.io? Kind regards, Troels Arvin

2 2

Firecracker 1.13 crate updates
by David Michael 28 Aug '25

28 Aug '25

Hi, Firecracker 1.13 will be released soon (tomorrow?), and it has two dependency updates not in Fedora: - vhost-0.14.0 (from 0.13.0) - vm-memory-0.16.2 (from 0.16.1) I could update vm-memory if you want, if you add me as a co-maintainer. The vhost API bump requires updating vhost-device-* crates. They updated dependencies in Cargo.toml upstream but most of them aren't tagging new versions. I think last time you released the new versions upstream yourself. Are you able to do that again? I've started side tags if you want to use these. I can then add Firecracker and push everything together when ready. f41-build-side-117726 f42-build-side-117728 f43-build-side-117730 f44-build-side-117732 Thanks. David

1 0

Re: Upcoming retirement of gtk3-rs, gtk-rs-core v0.18, and gtk4-rs v0.7
by Fabio Valentini 25 Aug '25

25 Aug '25

On Sun, Aug 24, 2025 at 2:55 PM Link Dupont <link.dupont(a)mac.com> wrote: > > I’ve orphaned system76-keyboard-configurator. I don’t have the determination to port it to gtk4. I can leave it orphaned for now in case anyone else wants to pick it up, or I can manually retire it if that’s preferred. Thank you, that's fine for now. Also, 1) it doesn't look as if it were easy to port to GTK4, and 2) it seems there is not much upstream activity in this project in general now. :( If nobody steps up, the package can still be retired from Fedora 43 until the start of the final freeze (October 7). Fabio

1 0

Upcoming retirement of gtk3-rs, gtk-rs-core v0.18, and gtk4-rs v0.7
by Fabio Valentini 21 Aug '25

21 Aug '25

Hi all, I am planning to implement this Fedora 43 Change in one week (on Aug 20, 2025): https://fedoraproject.org/wiki/Changes/Retire_gtk3-rs,_gtk-rs-core_v0.18,_a… The packages in the Change document will be retired in both rawhide and f43 branches. Not all affected applications have yet been ported from GTK3 to GTK4 (or from gtk-rs 0.18 to a more recent version). I will try to backport the necessary changes from upstream (where available). Applications that have not or cannot be ported (for example, because of dead upstream projects) will need to be retired. (Alternatively, the packages can be adapted to build with vendored Rust dependencies, but I recommend not doing this for applications that are dead and depend on dead libraries.) Fabio

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust August 2025