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 45.
TLDR: This report[1] contains a total of 52267 findings and 1419 new
findings identified since Fedora 44. Please review the report and
provide feedback. False positives can be recorded in the
known-false-positives[5] repository.
A mass scan was performed on the packages that have changed in Fedora
45. This report[1] contains all the findings that have been identified
in the Critical Path Packages. Newly added findings since Fedora 44
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.
False positives can 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 raw scan results, 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/f45-28-Apr-2026/
[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
Hi,
Fedora Workstation Working Group is tentatively planning to remove the
ABRT user interface (gnome-abrt) in Fedora 44. For more information,
see:
https://pagure.io/fedora-workstation/issue/130#comment-992075
ABRT is currently in maintenance mode, receiving primarily bugfixes
rather than feature development. The Working Group would prefer to keep
gnome-abrt, but only if it were to receive considerable new feature
development. If anybody is interested in working on ABRT, help would be
welcome.
Removing the user interface will not affect the automatic crash report
functionality. Crashes will still be reported to
https://retrace.fedoraproject.org/faf/summary/ which contains a
treasure trove of crash telemetry. It's a shame that Fedora developers
rarely look at it! This data could be quite useful for improving
software quality. If anybody is interested in this topic, it might be a
good opportunity to integrate AI, which could identify crash patterns
or perhaps even suggest fixes.
So that's two possible projects, in case anybody is looking for an itch
to scratch.
Michael
Hi all,
Last November, Red Hat announced Project Hummingbird [1], a catalog of
minimal, hardened container images designed to accelerate application
development with a minimal CVE strategy. The images include the latest
languages and runtimes (Node, Go, .NET, Java, Python, Rust, Ruby),
developer databases (PostgreSQL, MariaDB), web servers and proxies
(Nginx, Caddy, HAProxy), and other foundational components for modern
application stacks [3].
What's interesting for Fedora: Project Hummingbird is built using the
open source development process, originating from Fedora Linux
components (some Rawhide, some Stable). The press release notes that
unsupported images are freely available and redistributable, following
a similar model to Red Hat Universal Base Image (UBI) [5]. The work is
already happening in the open [2] with images available [3].
We'd like to explore bringing this work more formally into the Fedora
community and creating a space where this innovation can continue in
the open. This would follow similar patterns we've seen with other
successful incubation efforts in Fedora like ELN [4].
Before we go down the formal Change Proposal path, I wanted to gauge
community interest and see if there's appetite for this kind of
project.
Thoughts?
P.S. I'm heading on PTO tomorrow April 23rd, but I'll be back on
Monday, April 27th. I commit to reading and responding to any messages
when I return.
Kind Regards
Scott McCarty
References:
[1] https://www.redhat.com/en/about/press-releases/red-hat-introduces-project-h…
[2] https://gitlab.com/redhat/hummingbird/containers
[3] https://quay.io/organization/hummingbird
[4] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[5]: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
Hello,
How do I get around this... when dnf brakes in rawhide with
# dnf -y update --nogpgcheck --refresh --no-best --allowerasing
dnf: symbol lookup error: /lib64/libdnf5.so.2: undefined symbol:
rpmteSetVfyLevel
tia!
steved.
The 'fedora-active-user' script is mentioned in the 'non-responding
maintainer' process document. But link there goes to 7 years old script
which is no longer maintained by its' original author Pierre-Yves Chibon.
So I decided to take over the script, rewrote it into working version
which queries FAS, Koji, Bodhi, Bugzilla and Fedmsg services to check
for activity.
The https://fedora.juszkiewicz.com.pl/fedora-active-user/ directory
provides spec file, src.rpm file, results of 'fedora-review' run and
also results of 'fedpkg mockbuild' run from my system.
I opened a new package review bug for anyone to review:
https://bugzilla.redhat.com/show_bug.cgi?id=2463785
Dear colleagues,
As many of you know, I tried to land the OpenSSL 4 in Fedora and it was
rolled back by FESCo decision [1] because of disruptions caused by the
changes in OpenSSL 4. It was agreed [2] the following steps:
1. Undo the change in Rawhide (untag openssl4, untag builds that link to
openssl4)
2. Rebuild/re-tag missing packages
3. Add new provides to the openssl v3 packages
4. Create a COPR with openssl 4 and rebuild packages to get at least a
buildroot & container image in a working state
FESCo appointed @yselkowitz and @sgallagh as Shepherds for the OpenSSL 4
Change to aid the maintainers in getting the packaging in order.
After that decision was made, Yaakov, Stephen, Simo Sorce and I had a
meeting. We agreed that having OpenSSL 4 in rawhide is a must and agreed on
the following steps forward:
A COPR repo [3] was created to perform a mass prebuild. Then patches were
proposed to fix the builds for the packages for which the builds failed,
some of the failures are tracked there.
We are going to fix the critical subset of the packages, it’s an ongoing
work. Not all such packages will be fixed immediately. Simo, Yaakov,
Stephen and I will provide assistance to anyone adapting their packages,
but we cannot do all the work ourselves. For some (the fewer the better),
staying on OpenSSL 3 will be a viable option in the short term. It is
important to note that subtle problems can arise when a package and its
linked libraries attempt to load both OpenSSL 3 and 4 into the same
process. Not all packages can be updated at once due to the limited
capacity of this team, and these issues are an acknowledged risk.
The most prevalent adaptation we have had to make in our initial
investigation is a straightforward replacement of direct access to
ASN1_STRING members with accessors (which have been in the code forever, so
there will be no backward compatibility problems). Another common change
has been F41+ conditional BuildRequires on openssl-devel-engine; these need
to be limited to e.g. "%if 0%{?fedora} >= 41 && 0%{?fedora} < 45". (If a
package doesn't build with that even with openssl 3, then it needs to be
made to compile with OPENSSL_NO_ENGINE defined). It’s also worth noting
that constification of some functions and arguments in OpenSSL 4 can break
compatibility with OpenSSL 3. In most cases, this can be worked around
quite easily, either by adding ‘const’ to the variable declaration or
making a copy of the returned value.
More invasive changes have been required, but infrequently, demonstrating
that this should be a less difficult transition than OpenSSL 1.x to 3.0 was.
We proposed, and the shepherds agreed, that we should have a flag day
before the mass rebuild of Fedora 45. By that moment the transition of the
critical path packages to OpenSSL 4 will be completed. At the flag day
we're going to bump to 4.0, restore the openssl3 compatibility package, and
rebuild as much as possible in a side tag; the flag day will be when we
merge that side tag. The planned date is no later than June 24th: 3 weeks
before the mass rebuild.
As of now there are ~300 [3] packages with problems so help from the
maintainers is very welcome.
Last but not least. I want to apologize that I didn’t request assistance of
FESCo before attempting to land OpenSSL 4. I should request help at an
earlier stage instead of trying to push stuff. My other mistake was
expecting that if the system is reachable via ssh, that’s enough at the
early stage of the rawhide life cycle.
[1] https://pagure.io/fesco/issue/3596
[2] https://pagure.io/fesco/issue/3596#comment-1011313
[3] https://copr.fedorainfracloud.org/coprs/yselkowitz/openssl-4.0/monitor/
[4]
https://docs.google.com/spreadsheets/d/1uBrJ8JVTd6apmCPksRvXCMnGp7e0xPm1RCV…
--
Dmitry Belyavskiy
The copy fail security flaw in the Linux kernel [1] has been fixed
in the following versions of Fedora CoreOS:
- stable 43.20260413.3.2 (released today)
- testing 44.20260419.2.1 (released 04/28)
- next 44.20260414.1.1 (released a few weeks ago)
Since there were multiple `stable` releases this week you may want
to force an update manually if you have a periodic update strategy
configured [2] as there is currently a bug [3] that can cause the already
staged older update to be the one that gets applied during your window.
To force an update now and immediately reboot into the update you can
run `sudo /usr/bin/zincati-update-now`.
The Fedora CoreOS Team
[1] https://github.com/coreos/fedora-coreos-tracker/issues/2140
[2] https://coreos.github.io/zincati/usage/updates-strategy/#periodic-strategy
[3] https://github.com/coreos/zincati/issues/928
In one week, 2026-05-07, or slightly later, I plan to update llhttp to
9.4.1[1] in Rawhide.
Based on the source diff[2], this release contains no obvious security
fixes or exceptionally serious bug fixes. Therefore, although this
package has a permanent exception under the Updates Policy[3][4], I
currently have no plans to update llhttp in F44, F43, F42, or EPEL9.
This could change in the future if I learn that this release did in fact
fix a serious bug or security flaw.
A COPR impact check did not reveal any incompatibilities with dependent
packages: AusweisApp2, libgit2, libgit2_1.8, ocserv, python-aiohttp,
tank, and uxplay. Maintainers of affected packages should have received
this email directly by bcc.
I will use a side tag to rebuild the dependent packages, using either
co-maintainer or provenpackager privileges, including handling the
documented bootstrapping loop with libgit2 and rpmautospec.
[1] https://src.fedoraproject.org/rpms/llhttp/pull-request/35
[2] https://github.com/nodejs/llhttp/compare/v9.3.1...v9.4.1
[3] https://pagure.io/fesco/issue/3115
[4] https://pagure.io/epel/issue/262