devel October 2025

devel@lists.fedoraproject.org

117 participants
204 discussions

Findings by static analyzers in Fedora 44 Critical Path Packages
by Siteshwar Vashisht 13 Nov '25

13 Nov '25

Hello, I am writing this message to get feedback from the community on new findings by static analyzers in Critical Path Packages that have changed in Fedora 44. TLDR: This report[1] contains a total of 47352 findings and 843 new findings identified since Fedora 43. Please review the report and provide feedback. False positives can now be recorded in the known-false-positives[5] repository. A mass scan was performed on the packages that have changed in Fedora 44. This report[1] contains all the findings that have been identified in the Critical Path Packages. Newly added findings since Fedora 43 are listed under ‘+’ column and these should be prioritized while reviewing the findings (and fixing them upstream). Not all findings reported by OpenScanHub may be actual bugs, so please verify reported findings before investing time into fixing or reporting them. We have used the current development version of GCC to perform the scans, which may increase the likelihood of having false positives in the GCC reports. False positives can now be recorded in the known-false-positives[5] repository. These findings are automatically suppressed by OpenScanHub in scans that are triggered later. Also, you can filter findings with the csgrep utility to make it easier to review reports that may contain a large amount of false positives. Examples of csgrep invocation are available on the Fedora wiki[4]. We hope this is helpful for the packages you maintain and for the upstream projects. Questions can be asked on the OpenScanHub mailing list[2]. If you want to see the full logs of the scans, they are available on the tasks[3] page. User documentation for performing a scan is available on the Fedora wiki[4]. Please keep the feedback on this thread constructive. Thank you! [1] https://svashisht.fedorapeople.org/openscanhub/mass-scans/f44-28-Oct-2025/ [2] https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraproje… [3] https://openscanhub.fedoraproject.org/task/ [4] https://fedoraproject.org/wiki/OpenScanHub [5] https://github.com/openscanhub/known-false-positives

7 20

yajl - call for new maintainer and/or to stop using it
by Daniel P. Berrangé 13 Nov '25

13 Nov '25

I've been maintainer of the yajl package in Fedora forever, as it was a dep of libvirt. yajl upstream has been dead since 2015, so the current release tarball has multiple CVEs, which I've patched downstream by grabbing patches from github issue comments from third parties or other distros [1]. In the libvirt 10.8.0 release that just hit rawhide, we've switched to using json-c instead. Aside from libvirt in stable Fedora release branches, there are a few other packages in Fedora still using yajl that I see: Io-language collectd crun grive2 i3 i3-gaps i3status libmodsecurity mod_security raptor2 xen If anyone is cares about the above packages enough to want to take over ownership of 'yajl', either now or in future, please let me know. I'm willing to keep ownership of yajl until the Fedora 41 branch goes end of life, at which point no version of libvirt will still use it If no new volunteer has stepped forward by then I'll be orphaning yajl. If you are the Fedora maintainer of any of the above packages, I'd strongly recommend talking to their respective upstream about switching JSON library to json-c instead of yajl, to avoid being stuck using a dead project forever. With regards, Daniel [1] I collect patches in src-git at https://github.com/berrange/yajl/tree/fedora-dist-git -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

3 3

F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
by Ben Cotton 11 Nov '25

11 Nov '25

https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions == Summary == The legacy wireless extensions interface was replaced by the new mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions support has been long deprecated and only supports long EOL WiFi encryption like WEP so it's time to disable it and remove it. == Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org] == Detailed Description == The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA. == Benefit to Fedora == More secure and advanced features in wireless. In most cases most users won't notice a difference. The vast majority of users use NetworkManager to use 802.11 based wireless interfaces which has long ceased to support wireless extensions/wireless-tools, if it evere did. == Scope == * Proposal owners: ** Disable the wireless extensions interface in the kernel and any drivers that depend on it. The only driver that is currently enabled that requires wireless extension support is the Intel Pro Wireless 2100/2200 drivers, this hardware was released in 2003-2005 as part of the original Centrino laptop platforms and all officially supported devices were 32 bit so it's unlikely there's any current users but as they were mPCI cards it's possible there's a few users that put them into 64 bit machines. ** Retire the wireless-tools package, retirn any packages that depend on it, or migrate them to use libnl3. * Other developers: ** No impact * Release engineering: [https://pagure.io/releng/issue/10386 #10386] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == A handful of packages still use the libiw interface and hence depend on the wireless-tools package. Some projects look dead upstream, a number have already been migrated in the last year or so. Where the project is alive upstream tickets have been filed requesting migration. The current remaining package list is: * conky * lxpanel * reaver == How To Test == * Check that the wireless extensions kernel options are disabled: (CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WEXT_SPY CONFIG_WEXT_PRIV CONFIG_CFG80211_WEXT CONFIG_CFG80211_WEXT_EXPORT) * Check the wireless-tools package is no longer available == User Experience == Generally users should notice little to no difference. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Leave WEXT enabled in the kernel, leave wireless-tools package in Fedora package repository. * Contingency deadline: GA * Blocks release? No. * Blocks product? No. == Documentation == N/A (not a System Wide Change) == Release Notes == N/A -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 12

Looking for early feedback about the new artifact install approach in tmt / Testing Farm
by Petr Šplíchal 10 Nov '25

10 Nov '25

Hi! Have you had issues with a tmt test not working due to a package installation issue? Maybe you had a big side-tag update not passing some gating test on bodhi or testing-farm? Good news, we are on our way to resolving these issues and your feedback would be greatly appreciated. Recently we've started work on the new approach for installing tested artifacts (e.g. rpm packages) on the guest before the testing starts. We would like to gather early feedback on the proposed design as this is quite a significant change. Here we'll be demonstrating the approach on a koji build and included rpm packages but the same/similar might be applied for brew builds, copr builds, local rpms and other artifact sources. We also want to keep the implementation open for possible future extensions (e.g. container images). What are the most significant changes? Before: Testing Farm takes each requested koji build, downloads and installs all rpm packages included on the guest. There are some special hacks for the "exclude" key which allow handling conflicting rpms in a single build. After: Testing Farm hands over the koji build id to tmt which installs from the koji build **only** those packages which are explicitly requested by the test or plan. Which artifact sources will be supported? Currently we have the following sources on the list: - koji/brew build <https://github.com/teemtee/tmt/issues/253> (identified by build id, task id or nvr) - copr build <https://github.com/teemtee/tmt/issues/3993> (identified by <build-id>:<chroot-name>) - dnf repository <https://github.com/teemtee/tmt/issues/3994> (identified by baseurl of the repo) - dnf repository file <https://github.com/teemtee/tmt/issues/3995> (identified by url to the repo file) - rpm files <https://github.com/teemtee/tmt/issues/3992> (individual file paths or a directory, local or remote) But more are expected in the future. See the linked issues for more details and the outlined implementation. Feel free to ask questions or suggest changes directly there. How exactly will this work? All packages from the koji build are downloaded on the guest. List of the exact package nvrs is stored. A dnf repository is created from the packages and enabled with a suitable priority. Packages mentioned in test `require` or `recommend` keys, or in the plan prepare step are installed. Versions of the installed packages are verified to make sure the right packages were installed. Here’s an example prepare step config: prepare: summary: Prepare repository with packages how: artifact stage: prepare provide: - koji.build:1234 - koji.task:5678 - repo-file:https://another.url/repofile - repo-url:https://another.url/repo You will most likely not interact with it via the static files, instead testing-farm will take care of injecting this step via the command line: tmt run --all prepare --insert --how artifact --provide koji.build:1234 --provide koji.task:5678 What are the benefits? Consistent way to prepare artifacts for testing, e.g. when developing tests locally on your laptop you would get the very same result as when run in the Testing Farm. Simplified tmt reproducer line. This will also allow us to fully move to the new pipeline <https://issues.redhat.com/browse/TFT-3696> which supports multihost testing. No problems when conflicting packages are included in the koji build as only the right subset of packages is installed on the guest. Possibility to test minimal install or various combinations of packages which can reveal bugs hidden by always installing all packages. If a test needs to perform some advanced package handling actions (e.g. verifying that reinstalling a package is working as expected) it can make use of the dnf repository with the fresh packages to perform the desired dnf operations. No extra steps should be needed from either Testing Farm or the user. What is expected from the users? Make sure that all packages necessary for testing are included in the require <https://tmt.readthedocs.io/en/stable/spec/tests.html#require> or recommend <https://tmt.readthedocs.io/en/stable/spec/tests.html#recommend> key of the test or are explicitly installed using one of the prepare <https://tmt.readthedocs.io/en/stable/plugins/prepare.html> step plugins. What do you think? Does the proposed design look ok? Do you have any concerns? Are there any important use cases or corner cases we should keep in mind when working on the implementation? See the tracking issue for some more details about the design and the current progress: https://github.com/teemtee/tmt/issues/3990 We would be especially interested in suggestions regarding what would be the best way to set the correct priority for the repository so that it plays well with other defaults. Also, would you have any recommendations about what should happen if there are multiple nvrs for the same package included in the source repository? Looking forward to your feedback. psss...

2 2

Heads up: openQA test failures on Rawhide updates
by Adam Williamson 09 Nov '25

09 Nov '25

Hey folks, just a quick note to say yep, we're aware of the ongoing issue with all Rawhide updates failing openQA tests (well, server, cloud and everything-boot-iso tests, at least one of which is gonna affect most updates). I *think* this - at least all of it aside from the Cloud kiwi build issue, which might be something else? - stems from the new shim builds we tagged in recently. But I'm not 100% sure. I'm getting releng to untag the shim builds so we can see if the tests start passing again. Will try to have this resolved ASAP. Sorry for the trouble. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 1

"Extracting debug info from <n> files"
by Sam Varshavchik 07 Nov '25

07 Nov '25

I am rebuilding my packages in mock for F43, and things are noticeably slow. Something regressed, somewhere… find-debuginfo is taking …many minutes. I just looked up in ps, and find- debuginfo has been running for seven minutes, on 32 cores: /usr/bin/find-debuginfo -j32 --strict-build-id -m -i --build-id-seed 0.26.1-1.fc43 --unique-debug-suffix -0.26.1-1.fc43.x86_64 --unique-debug-src- base libcxxbase-0.26.1-1.fc43.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /builddir/ build/BUILD/libcxxbase-0.26.1-build/libcxx-0.26.1 find-debuginfo: starting Extracting debug info from 14 files Eight minutes, and going… 'ps' is showing various 'dd' and 'ar' processes coming, and going, and coming, and going. … It just came up for air. dwz ran for a few seconds, and rpmbuild also ground its gears for a while, finishing up the packaging. Just to make sure I was not seeing things, I immediately rebuilt the same package in mock in the F42 root, and find-debuginfo only needed a few seconds to take care of business. Instead of 8+ minutes. I'm curious if anyone else is also seeing this.

4 4

[copr] GNOME X11 Session in Fedora 43
by Frantisek Zatloukal 07 Nov '25

07 Nov '25

Hello, As probably everyone is aware, GNOME in Fedora 43 comes without support for X11/Xorg sessions. There still might be scenarios, where one needs to use a non Wayland session, and doesn't fancy switching over to different DE just because of that. For situations like these, I've dumped my work into a copr repo: https://copr.fedorainfracloud.org/coprs/frantisekz/GNOME-X11/ that restores "GNOME on Xorg" option back on Fedora 43 (and 44 too, for now). In order to get it going, the following should be enough (for both upgrades and clean installs): sudo dnf copr enable frantisekz/GNOME-X11 sudo dnf update sudo dnf install xorg-x11-xinit gnome-session-xsession gnome-classic-session-xsession Just two disclaimers at the end: I'll try to keep up with minor releases and patch backports as they come to Fedora 43, and the more important one is that the packages replace the distribution ones by an epoch bump, and it's necessary to keep that and its implications in mind. -- Best regards / S pozdravem, František Zatloukal Senior Quality Engineer Red Hat

5 9

libbluray and libudfread soname bump
by Xavier Bachelot 06 Nov '25

06 Nov '25

Hi, I've updated libbluray from version 1.3.4 to version 1.4.0 in rawhide, which implies a soname bump. I've also updated libudfread from version 1.1.2 to 1.3.0 in rawhide, which is needed by libbluray 1.4.0 and implies a soname bump too. The libbluray and libudfread builds were done in f44-build-side-119911. The following packages need to be rebuild: ffmpeg gvfs mpv vlc xine-lib ffmpeg needs to be taken care of before mpv, vlc and xine-lib. I should be able to take care of all the rebuilds with multimedia SIG privileges, but I'd rather double check if it's fine before possibly stepping on any toe. gvfs can be rebuilt anytime, but I don't have privileges on this package. Both ffmpeg and gvfs were successfully scratch-built. Regards, Xavier

3 4

F44 Change Proposal: Enforcing_signature_checking_by_default [SystemWide]
by Allison King via devel-announce 06 Nov '25

06 Nov '25

Wiki: https://fedoraproject.org/wiki/Changes/Enforcing_signature_checking_by_defa… Discussion Thread: https://discussion.fedoraproject.org/t/169774 **This is a proposed Change for Fedora Linux.** This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Change the RPM default package verification mode to enforcing signature checking, to follow upstream RPM 6.0 default: only packages with a verified signature can be installed, unless explicitly overridden by `--nosignature` or corresponding API. == Owner == * Name: [[User:pmatilai| Panu Matilainen]] * Email: pmatilai(a)redhat.com == Detailed Description == On RPM level, this is a one-line configuration change: `%_pkgverify_level` default is changed from `digest` to `all`, which requires packages to have both a verified signature(s) and digest(s) to be installable. This means `rpmkeys -K/--checksig` will fail on unsigned packages, and `rpm` will refuse to install such packages, unless explicitly overridden with `--nosignature` (or corresponding API). This change was originally intended to happen as a side-effect of https://fedoraproject.org/wiki/Changes/RPM-6.0 but was postponed to Fedora 44 due to time and resource reasons. DNF5 >= 5.2.14.0 (in Fedora >= 42) has the necessary integration to allow disabling the verification on per-package basis to support repositories with disabled signature checking. This is used by mock to handle newly built, unsigned packages, and continues to work without further changes. Mock has a plugin for signing locally built packages, and COPR has it's own automatic signing. For packages locally built with rpmbuild, RPM >= 6.0 supports automatic signing by a passwordless key to make local `rpmbuild` use almost as seamless as before, and comes with a easy one-time setup script: `/usr/lib/rpm/rpm-setup-autosign`. == Feedback == == Benefit to Fedora == The traditional RPM <= 4.x behavior was to verify a signatures if they are present and verifiable, but never require it. That behavior may have been somehow acceptable in the nineties, but does not meet the security expectations of modern times. Besides being insecure, the semantics cause quirky and non-obvious behavior in various situations. Higher level package managers like yum and dnf/dnf5 have implemented their own enforcing signature modes, enabled by default since the beginning of Fedora. This change brings the RPM side default behavior to this millenium. == Scope == * Proposal owners: ** Change the RPM configuration. ** Assist with with adoption as necessary, and address possible unforeseen / newly found issues in rpm/dnf/mock * Other developers: ** Adjust their local package building workflows to either use signed packages or explicitly disable the signature checking where necessary (see compatibility impact). * Release engineering: [https://pagure.io/releng/issues/13027 #13027] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Improved security should align with Fedora strategy, whether written down or not. == Upgrade/compatibility impact == There's no impact on the average system only utilizing packages from official or 3rd party repositories. Dnf, mock, the official Fedora buildsystem and COPR should be fully compatible with this change as-is. However, this change will almost certainly require some changes to rpm/rpmbuild related workflows that the RPM team hasn't even heard of. In some cases it might be sufficient to import relevant keys before operating on packages. Ideally, workflows involving unsigned packages are updated to use signed packages. Where that is not immediately or easily feasible, explicit `--nosignature` (or corresponding API) switches or local configuration change to a more permissive policy may need to be added to scripts / system configuration. Changes might be needed if there are local rpmbuild-related workflows, see Scope. == How To Test == This will receive thorough testing in everyday system use through system updates and on the buildsystem side, building packages. Specific items to test locally include: * Try to install or verify an unsigned package (must fail) * Try to install or verify a signed package whose key is not imported (must fail) * Try to install or verify both of the above with `--nosignature` (should succeed if legit package) * Test automatic signing in rpmbuild: ** Run `/usr/lib/rpm/rpm-setup-autosign` ** Import the key as indicated by rpm-setup-autosign output ** Build some package(s) ** Try to install those packages (must not fail due to signature) == User Experience == * Packages without verifiable signature(s) cannot be installed without an explicit override. == Dependencies == * dnf, mock, koji, copr are related but the buildsystem(s) are expected to work with no further changes * there may be unforeseen / unknown dependencies in the infrastructure * `dnf --no-gpgchecks` needs [ https://github.com/rpm-software-management/dnf5/issues/2479 integration] == Contingency Plan == * Contingency mechanism: Revert back to digest verification by default for F44 and try again in F45. * Contingency deadline: beta freeze * Blocks release? Yes == Documentation == The package verification policy configurables (`%_pkgverify_*`) are documented in the [https://rpm.org/docs/6.0.x/man/rpm-config.5 rpm-config(5)] manual. == Release Notes == -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

10 18

Orphaned my GNOME related Rust packages
by Fabio Valentini 03 Nov '25

03 Nov '25

Hi all, I no longer have time or energy to deal with the packages mentioned in $SUBJECT. They should be in good shape. There is a (very fresh) pending patch-level version update for the GLib / GTK4 / GStreamer bindings and the GStreamer plugins, which (if time permits) I will still handle ~next week as Rust SIG member (which remains co-maintainer on all affected packages). Fabio

4 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2025