Rust

rust@lists.fedoraproject.org

163 discussions

Re: Rebuilds of Rust packages for recent security vulnerabilities (openssl, sequoia)
by Fabio Valentini 12 May '26

12 May '26

On Tue, May 12, 2026 at 10:26 AM Viktor Ashirov <vashirov(a)redhat.com> wrote: > > Hi Fabio, > > On Tue, May 12, 2026 at 1:24 AM Fabio Valentini <decathorpe(a)gmail.com> wrote: >> >> I am also unable to address this issue in (almost all) packages that >> vendor their Rust dependencies: >> >> - 389-ds-base > > For the record, 389-ds-base is not affected because it uses NSS as the primary crypto library. > The openssl crate is used only by the pwdchan plugin for PBKDF2 password hashing. > That said, we will rebuild the package to include bug fixes and bump the openssl crate version. Thanks for checking! Fabio

1 0

Rebuilds of Rust packages for recent security vulnerabilities (openssl, sequoia)
by Fabio Valentini 11 May '26

11 May '26

Hi all, A number of security issues in two "widely-used" Rust crates have been published recently: - openssl (Rust bindings for OpenSSL): CVE-2026-41676, CVE-2026-41677, CVE-2026-41678, CVE-2026-41681, CVE-2026-41898, CVE-2026-42327, CVE-2026-44662 - sequoia-openpgp (our favourite OpenPGP implemenation): CVE-2026-42783, CVE-2026-42784, and CVE-requested-but-not-assigned-yet I am currently processing the package rebuilds that are necessary for applications to pick up these fixes (yay, static linking). The rebuilds for sequoia-openpgp 2.3.0 are done: https://bodhi.fedoraproject.org/updates/?search=rust-sequoia-openpgp-2.3.0 These were also built against the latest version of the "openssl" crate. The rebuilds for fixes included in "openssl" 0.10.78 / 0.10.79 are still running and I will submit them to bodhi as they finish. I am handling rebuilds of all packages that I maintain, co-maintain, or where the Rust SIG is co-maintainer. Maintainers of packages in none of these three categories will need to check whether their packages are affected and rebuild them themselves. This includes: - aw-server-rust - awatcher - clevis-pin-tpm2 - clevis-pin-trustee - envision - fido-device-onboard - keyring-ima-signer - krun-awsnitro-eif-ctl - python-cryptography - s390utils - trustee - trustee-guest-components - virt-firmware-rs I am also unable to address this issue in (almost all) packages that vendor their Rust dependencies: - 389-ds-base - arapuca - bcvk - bootc - bpfman - chunkah - cosmic-settings-daemon - fractal - goose - rpm-ostree - rust-bootupd - rust-zincati - trunk - vaultwarden Fabio --- Advisories for the "openssl" crate: - CVE-2026-41676: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-pqf5-… - CVE-2026-41677: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-xmgf-… - CVE-2026-41678: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-8c75-… - CVE-2026-41681: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-ghm9-… - CVE-2026-41898: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-hppc-… - CVE-2026-42327: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-xp3w-… - CVE-2026-44662: https://github.com/rust-openssl/rust-openssl/security/advisories/GHSA-xv59-… NEWS for version 2.3.0 of the "sequoia-openpgp" crate: https://gitlab.com/sequoia-pgp/sequoia/-/raw/openpgp/v2.3.0/openpgp/NEWS

1 0

Orphaned a bunch of Rust CLI tools
by Fabio Valentini 02 May '26

02 May '26

Hi all, I have orphaned a bunch of CLI tools (that happen to be written in Rust). The people who originally added them to Fedora are no longer around or are no longer interested, and I myself don't use any of them. - rust-dutree (last upstream activity >5 years ago) - rust-heatseeker (a few versions behind upstream) - rust-procs (one patch-version behind upstream) - rust-tealdeer (behind upstream and requires some dependency work for newer versions) - rust-varlink-cli (major version behind upstream, unresolved package conflict with the C reference implementation) I would classify heatseeker and procs as low-maintenance packages. dutree seems to be abandoned upstream, and tealdeer and varlink-cli both would require significant time investment (and packaging work for new and updated dependencies) to get them into shape again - so beware. Fabio

1 0

Intent to retire: rust-pore in EPEL 8 and 9
by Michel Lind 05 Mar '26

05 Mar '26

Dear all, I currently maintain `rust-pore` across Fedora and EPEL, but unfortunately development on the open source repo has stalled - this was used at work but recent activity is mostly on an internal fork (alas). Since it's causing an issue with keeping the set of Rust crates up to date (it's needed patching to either compile with newer crates, or has to be compiled with compatibility packages), I'd like to request having it retired in EPEL 8 and 9. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 1

Packaging wayscriber
by W. Michael Petullo 11 Feb '26

11 Feb '26

I would like to package wayscriber [1], which is written in Rust, for Fedora. I have not yet created a package for software written in Rust, but I have packaged software written in C, Python, Go, and other languages. My hugo package is an example of Go a package that makes use of vendored dependencies. The trouble with wayscriber is twofold: it relies on Rust crates that are not yet packaged, and it relies on Rust crates that are packaged, but at an incompatible version. Here is what I see when I try to build: [...] error: Failed build dependencies: (crate(iced/canvas) >= 0.12.0 with crate(iced/canvas) < 0.13.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(iced/default) >= 0.12.0 with crate(iced/default) < 0.13.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(iced/tokio) >= 0.12.0 with crate(iced/tokio) < 0.13.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(png/default) >= 0.17.0 with crate(png/default) < 0.18.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(schemars/default) >= 0.9.0 with crate(schemars/default) < 0.10.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(schemars/derive) >= 0.9.0 with crate(schemars/derive) < 0.10.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(smithay-client-toolkit) >= 0.20.0 with crate(smithay-client-toolkit) < 0.21.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(smithay-client-toolkit/calloop) >= 0.20.0 with crate(smithay-client-toolkit/calloop) < 0.21.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 (crate(smithay-client-toolkit/xkbcommon) >= 0.20.0 with crate(smithay-client-toolkit/xkbcommon) < 0.21.0~) is needed by wayscriber-0.9.9.3-1.fc43.x86_64 The first three dependencies (iced/*) are not packaged, and the others are packaged at incompatible versions. Does anyone have any advice on how to proceed? I see from the Rust packaging guidelines [2] that vendored dependencies are discouraged. I did fiddle around with rust2rpm (I am familiar with go2rpm). However, I do not think that wayscriber itself in at crates.io. It looks like cosmic-panel.spec also uses iced and as a vendored dependency. I thought that might be a good model, but I have not successfully generated vendor-config-X.toml and vendo-X.tar.gz (using rust2rpm?). [1] https://wayscriber.com/ [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ -- Mike :wq

2 1

Upcoming mini-mass rebuild of Rust applications for RUSTSEC / CVE advisories
by Fabio Valentini 08 Feb '26

08 Feb '26

Hi all, The Rust SIG is currently preparing updates to address potential security issues in four Rust crates (and libgit2), and bytes https://rustsec.org/advisories/RUSTSEC-2026-0007.html git2 https://rustsec.org/advisories/RUSTSEC-2026-0008.html jsonwebtoken https://www.cve.org/CVERecord?id=CVE-2026-25537 time https://rustsec.org/advisories/RUSTSEC-2026-0009.html The "bytes", "git2", and "time" crates are very widely used, so the lists of affected applications are long and have significant overlaps between these three. As such, we decided that it made sense to just handle all four issues simultaneously with one mini-mass-rebuild. The list of affected Rust applications that will be attempted to be rebuilt for the listed issues is included below. Packages that are co-maintained by the Rust SIG will be handled by me. Packages that are not will need to be handled by their respective package maintainers, with provenpackager help, or will be skipped. The following side-tags are used to collect the necessary library updates (already done) and application rebuilds: - f45-build-side-128366 - f44-build-side-128368 - f43-build-side-128370 - f42-build-side-128372 - epel10.2-build-side-128374 - epel9-build-side-128376 Fabio ============================================================ Affected applications: bytes ===== - asciinema - atuin - aw-server-rust - awatcher - bustle - clamav - clevis-pin-trustee - crun-vm - envision - fido-device-onboard - glycin - gotify-desktop - greetd - helix - keylime-agent-rust - librsvg2 - matrix-synapse - mirrorlist-server - nispor - nmstate - ntpd-rs - python-orjson - python-uv-build - rust-afterburn - rust-below - rust-busd - rust-cargo-c - rust-cargo-deny - rust-coreos-installer - rust-crypto-auditing-agent - rust-crypto-auditing-client - rust-crypto-auditing-event-broker - rust-crypto-auditing-log-parser - rust-gst-plugin-dav1d - rust-gst-plugin-reqwest - rust-ingredients - rust-jql - rust-monitord - rust-monitord-exporter - rust-muvm - rust-nu - rust-oo7-cli - rust-podman-sequoia - rust-pore - rust-procs - rust-rbspy - rust-rbw - rust-redlib - rust-routinator - rust-sccache - rust-sequoia-chameleon-gnupg - rust-sequoia-keystore-server - rust-sequoia-octopus-librnp - rust-sequoia-sq - rust-sevctl - rust-sigul-pesign-bridge - rust-snpguest - rust-tealdeer - rust-weezl - rust-ybaas - rustup - sad - selenium-manager - trustee - trustee-guest-components - tuigreet - uv git2 ==== - envision - rust-bat - rust-cargo-c - rust-git-delta - rust-git-interactive-rebase-tool - rust-gitui - rust-heatseeker - rust-lsd - rust-pore - rust-pretty-git-prompt - rust-tokei jsonwebtoken ============ - trustee - uv time ==== - atuin - aw-server-rust - clevis-pin-tpm2 - clevis-pin-trustee - envision - fido-device-onboard - gotify-desktop - keylime-agent-rust - librsvg2 - maturin - nmstate - retis - rust-add-determinism - rust-afterburn - rust-bat - rust-below - rust-btrd - rust-cargo-c - rust-cargo-deny - rust-crypto-auditing-agent - rust-crypto-auditing-client - rust-crypto-auditing-event-broker - rust-crypto-auditing-log-parser - rust-dua-cli - rust-eif_build - rust-git-delta - rust-gitui - rust-gst-plugin-reqwest - rust-nu - rust-onefetch - rust-oo7-cli - rust-pleaser - rust-procs - rust-rd-agent - rust-rd-hashd - rust-rd-util - rust-redlib - rust-resctl-bench - rust-resctl-demo - rust-routinator - rust-scx_layered - rust-scx_rustland - rust-scx_rusty - rust-sequoia-chameleon-gnupg - rust-snpguest - rust-speakersafetyd - rust-wiremix - tbtools - trustee - trustee-guest-components - tuigreet - uv

1 1

HEADS-UP: cargo-rpm-macros v28 headed to stable branches soon
by Fabio Valentini 20 Nov '25

20 Nov '25

Hi all, I am planning to submit updates for cargo-rpm-macros v28.0, rust2rpm v28.0.0, and cargo2rpm v0.3 to Fedora 43 and 42 shortly. Release notes linked below. These updates have already landed in rawhide and have not caused issues there (except for two packages that used the "%cargo_install" macro in a way that just "happened" to work previously - both of which I have submitted PRs for, and I have included a workaround in cargo2rpm v0.3.1 to avoid the issue entirely). Despite this being a "major" version bump for cargo-rpm-macros, this is mostly symbolic - there are no user-visible changes. Only some internal implementation details have changed since v26, which allow for more correct / less surprising behaviour in some cases, and easier future maintenance. More features are now implemented in Python in cargo2rpm rather than as shell scripts in the RPM macros directly. The accompanying rust2rpm v28.0.0 *does* have some user-visible changes. Some deprecated features have been removed, and a few new features have been added. The default workflow of running "rust2rpm foo" to generate a "rust-foo.spec" file for the "foo" crate is not affected by the removal of deprecated functionality. Release notes: - https://codeberg.org/rust2rpm/cargo-rpm-macros/releases/tag/v28.0 - https://codeberg.org/rust2rpm/rust2rpm/releases/tag/v28.0.0 - https://codeberg.org/rust2rpm/cargo2rpm/releases/tag/v0.3.0 - https://codeberg.org/rust2rpm/cargo2rpm/releases/tag/v0.3.1 Fabio

1 0

Request for Rust SIG Organization + Team on forge.fp.o
by Fabio Valentini 11 Nov '25

11 Nov '25

Hi all, I filed a request to create an Organization and Teams for the Rust SIG on forge.fp.o, where I intend to move the remaining projects from the pagure.io/fedora-rust namespace (that haven't already been migrated to codeberg.org) https://pagure.io/fedora-infrastructure/issue/12911 Please comment there if you spot any mistakes or missing things. Fabio

1 0

gtk-rs / gstreamer-rs packager points of contact
by Fabio Valentini 07 Nov '25

07 Nov '25

Hello packagers, I recently went over the packages related to gtk-rs / gstreamer-rs and noticed that a lot of them had "main admin"s that haven't touched the packages in years. In practice, I have already been the sole maintainer of the GTK / GLib / GStreamer Rust bindings for the past ~four years. If you are in the CC of this email, you are the "main admin" of package(s) related to gtk-rs / gstreamer-rs, and I would ask that you consider assigning the "main admin" role to me, just to reflect who is / will be (and was, for the past 4 years) actually doing the maintaining. Thank you, Fabio atim: - rust-gstreamer-sys - rust-gstreamer-audio - rust-gstreamer-audio-sys - rust-gstreamer-base - rust-gstreamer-base-sys - rust-gstreamer-pbutils - rust-gstreamer-pbutils-sys - rust-gstreamer-video - rust-gstreamer-video-sys jistone: - rust-glib-macros mclasen: - rust-ashpd - rust-gdk4-wayland - rust-gdk4-wayland-sys - rust-gdk4-x11 - rust-gdk4-x11-sys - rust-gst-plugin-gtk4 - rust-gstreamer-gl - rust-gstreamer-gl-sys - rust-gstreamer-gl-egl - rust-gstreamer-gl-egl-sys - rust-gstreamer-gl-wayland - rust-gstreamer-gl-wayland-sys - rust-gstreamer-gl-x11 - rust-gstreamer-gl-x11-sys - rust-gvdb - rust-libadwaita - rust-libadwaita-sys

1 0

Packaging "rollup"
by Gordon Messmer 05 Nov '25

05 Nov '25

Hello, rust sig, I'm trying to package a NodeJS program, "rollup". Rollup uses wasm-pack to build some internal Rust crates. Early attempts to package this fail because cargo is trying to access the network. I probably need to adapt the cargo rpm macros for this case, but that is somewhat difficult because cargo is being called by wasm-pack. I might be able to introduce a shell script called "cargo" (and put that at the beginning of PATH) that expands the rpm macros and calls the real cargo binary with a combination of the rpm macro arguments and the arguments passed by wasm-pack, but I am wondering if you might have a more elegant solution? Thanks for any suggestions you might have. https://github.com/rollup/rollup/blob/master/package.json#L43 https://github.com/drager/wasm-pack

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust