fidzu : Fedora

The third quarter of 2026 is over, and so in this post we'd like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn't be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!

If you haven't participated yet in testing Fedora, perhaps you'd like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.

Testing proposed updates

When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.

Test period: Q3 2026 (2026-07-01 - 2026-09-30)
Contributors: 414
Updates commented¹: 8077

¹ If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

Test days participation

Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.

Test period: Q3 2026 (2026-07-01 - 2026-09-30)
Contributors: 67
Test cases executed: 598

…and also 25 other testers who executed less than 5 test cases each, but submitted 44 test results combined!

We sincerely thank all contributors!

Are you also interested to help? Please look at our Fedora Quality homepage.

08 Oct 2026 1:28pm GMT

The Podman and Fedora Quality teams are organizing a test week from Monday, October 12, through Sunday, October 18, 2026. We want your help testing conmon v3, the Rust-based container monitor used with Podman. If you use Podman, try the same containers and commands with conmon v3 and report any differences.

Why we're testing conmon v3

Conmon is the small process that keeps watching a container after the Podman command that started it has finished. Podman uses an OCI runtime such as crun or runc to start the container; conmon attaches to its input and output, provides the connection for podman attach, collects logs, and records its exit status.

Conmon v3 replaces the C implementation with a Rust version. This helps prevent common memory errors in safe code. It also gives the logging backends a shared interface, making them easier to extend and test.

We already run Podman's system tests against conmon v3. Now we'd like help checking development containers, interactive sessions, and Quadlet services on other people's setups.

Getting started

We've prepared a test week wiki page with setup instructions, links to the test cases, and information on reporting results. Start there to check the Fedora and package requirements, then use a test machine or VM with no important data.

Install the new monitor with this command:

sudo dnf install conmon-v3

To select it system-wide, create /etc/containers/containers.conf.d/99-conmon-v3.conf with the following content:

 [engine]
 conmon_path = ["/usr/bin/conmon-v3"]

Run podman info and check that the conmon path is /usr/bin/conmon-v3 and its version starts with 3. If you use both rootless and rootful Podman, check sudo podman info as well. User configuration can override the system setting.

Start new test containers after making this change. Containers that are already running retain their existing monitor.

To switch back after testing, remove the drop-in. New containers will then use your previous configuration.

What to test

Here are the areas we'd particularly like you to check:

• Open an interactive shell, resize the terminal, and detach and attach again.
• Run podman exec, including interactive commands, and check the output and exit status.
• Check file and journald logs with large output and lines without a final newline.
• Start, stop, and restart containers, including services managed by Quadlet or systemd.
• Try rootless or rootful Podman, and crun or runc where available.

Watch for hangs, missing output, incorrect exit statuses, unexpected CPU usage, or behaviour that differs from conmon v2. The wiki links to the test cases, which include the conmon-specific checks.

Results and help

Record your results in the test day application. Please record successful tests too. They tell us which setups have been checked.

Report conmon problems in the conmon v3 issue tracker. For other Podman issues, follow the bug-reporting instructions on the wiki page. Include your Fedora version, relevant package versions, reproduction steps, relevant logs, and the output of this command:

podman info --debug

Link the bug report when submitting your test result.

For help with testing or reporting a problem, join us on Matrix in #podman:fedoraproject.org.

This article was co-written by Petr Sklenar and Jan Kaluza.

Note about AI usage: : The core technical content and claims are completely our own. Claude (Anthropic) was used only as an editing tool to enhance grammar and readability.

07 Oct 2026 4:25pm GMT

06 Oct 2026 2:07pm GMT

05 Oct 2026 6:24pm GMT

Across the Fedora ecosystem this week, groups are heavily focused on stabilizing the upcoming Fedora 45 release, with teams like Quality, Release Engineering, and Workstation actively coordinating blocker reviews, test weeks, and freeze exceptions. Another major common thread is the ongoing modernization of project infrastructure, particularly the transition toward Forgejo-guided by the Council's newly approved Fedora Forge Usage Policy-and the strategic workflow planning for Red Hat's upcoming Bugzilla sunset, which is actively impacting discussions within EPEL and Design. Finally, navigating the integration of Artificial Intelligence has become a prominent focal point; the newly rebranded Fedora AI Working Group is establishing formal AI assistance disclosure policies, while several groups including Fedora Join, Diversity & Inclusion, and CoreOS are actively debating data privacy and opt-in boundaries regarding the collection of their communications for this report.

Announcements

The Fedora QA team is calling for community participation in the Anaconda F45 features Test Week, running through October 2, 2026. This is a highly focused opportunity for contributors to help shape the upcoming Fedora 45 installer by testing significant new capabilities, ensuring a smooth transition and avoiding disruptive surprises upon release. Key features needing real-world virtual or bare-metal testing include the modern WebUI for Atomic Desktops, browser-based remote installation support, and integrated Stratis storage configuration.

In broader ecosystem news, the Fedora Project recently supported a highly successful Software Freedom Day Bukidnon 2026 in the Philippines, bringing together students, educators, and professionals to celebrate open-source innovation with sessions ranging from automotive Linux to running local AI models. Meanwhile, on the technical discussion front, contributors are actively sharing best practices for installing the Navidrome music server on Fedora using Podman. Recent forum activity highlights how to optimize the setup using native systemd container files, rootless user namespaces, and automatic SELinux context tagging, providing a more robust, Fedora-native alternative to standard Docker configurations.

Council

During this period, the Council primarily focused on establishing clear governance for core project infrastructure and ensuring the continuity of Fedora's external partnerships. A key theme across both tickets was formalizing responsibilities and defining clear boundaries for project resources to maintain a sustainable ecosystem for all contributors.

Notably, the group concluded voting on the comprehensive usage policy for the Fedora Forge and successfully coordinated a transition plan for Fedora's ongoing representation in the global Digital Public Goods Alliance (DPGA).

Decisions

• Approved the new Fedora Forge Usage Policy by an 8-0 vote. This significantly affects the broader community by restricting the Forgejo instance strictly to Fedora-related work rather than serving as a general-purpose host. The policy mandates FAS authentication, establishes a soft repository size limit of 500MB, enforces a 10-minute timeout for shared CI runners, and outlines a formal exception process for ecosystem upstreams.
• Decided (by a 9-0 vote) to transition the responsibility of representing Fedora in the Digital Public Goods Alliance (DPGA) away from the Fedora Community Architect role. The Council agreed to formally request that the Fedora Mindshare Committee assume this long-term relationship, while immediate 2026 renewal tasks will be handled by current members. Documented in Issue 576.

Learn more about the Council team.

FESCo

This week, FESCo held one meeting but did not reach quorum, deferring formal votes. The committee briefly discussed the Forge Usage Policy and the process for appointing a new member. In the issue trackers, FESCo debated Koji build performance expectations for secondary architectures, analyzed requirements for the upcoming Bugzilla replacement, and tracked incomplete Fedora 45 Changes. Additionally, three new Change proposals (Crystal Language, Thin LTO Build Flag, and Libical4) were opened for voting, and community members discussed a proposal to preserve Git-derived modification timestamps for source packages.

Decisions

• Processed a non-responsive maintainer ticket, transferring ownership of actively maintained packages to new volunteers and orphaning the remainder.
• Authorized the retirement of the NetworkManager-vpnc and NetworkManager-fortisslvpn packages, intentionally using Obsoletes in the main NetworkManager package to forcefully uninstall them from user systems due to a critical privilege escalation vulnerability.
• Resolved the issue of kmscon breaking certain display managers after a workaround was pushed to stable for lightdm, noting that similar issues in other display managers should be handled as normal bugs.
• Confirmed the completion of the 'Filter Fedora Flatpaks for Atomic Desktop v2' Change and formally retargeted the 'Disable Vendor Change by Default' Change to Fedora 46.

Learn more about the FESCo team.

Packaging Committee

During its weekly meeting, the Packaging Committee processed multiple routine documentation updates and engaged in a lengthy discussion regarding a major simplification of snapshot versioning. Several minor updates concerning Emacs packaging and documentation restructuring were successfully merged.

The most significant ongoing topic is issue #1570, which proposes standardizing snapshot versioning to a single <number>.<revision> format to reduce complexities that have historically caused upgrade path breakages for packagers. While initial meeting votes favored the simplification, formal voting is continuing on the ticket to ensure the required committee majority is met.

Decisions

• Adopted a new fast-track rule allowing trivial or non-controversial pull requests to be merged before the next meeting if they receive two FPC member approvals.
• Approved and merged issue #1573 to move legacy complex versioning instructions into a separate versioning appendix page, streamlining the main versioning guidelines.
• Approved and merged issue #1574 to clarify that references to Emacs compilation in the guidelines specifically mean byte compilation.
• Approved and merged issue #1575 to reflect that the Pure GTK Emacs build is now provided by the emacs-pgtk package.
• Closed issue #1576 regarding the deprecation of the Group tag.

Learn more about the Packaging Committee team.

Mindshare

This week, Mindshare celebrated successful community events, reviewing reports and finalizing logistics for IndiaFOSS 2026, Data Con LA 2026, and Software Freedom Day Bukidnon 2026. Driven by the success of APAC events, the committee resolved to create a dedicated event box stationed at the Red Hat Pune office to streamline regional swag distribution and significantly reduce international shipping costs for local organizers.

Governance and activity levels were also a major focus, prompted by Ticket #153. To address recent delays in ticket triage and ongoing vacant representative seats (such as Comm Ops and Marketing), the committee discussed modifying its rules to formally reallocate representation to more active sub-teams, ensuring consistent and timely support for contributors and organizers across the broader Linux community.

Decisions

• Agreed to establish a new Fedora event box based in the Red Hat Pune office to better serve the APAC region without the prohibitive costs of international shipping from the US or EU. (Mindshare Meeting)
• Initiated a process to review and potentially change Mindshare representation rules, aiming to replace statically designated seats (like Comm Ops and Marketing) with flexible seats assigned annually to the most active community subgroups. (Mindshare Meeting)

Contribution opportunities

• Mindshare is seeking contributors to get involved with AI, documentation, and moderation efforts, providing opportunities for active individuals to eventually step into committee representative roles. (Ticket #153)
• Local event organizers in the Philippines (such as those behind SFD Bukidnon) are actively looking for resident Fedora Ambassadors to partner with for future open-source events. (Ticket #146)

Learn more about the Mindshare team.

Fedora Join

This week, the Fedora Join group welcomed two new contributors who introduced themselves via the forum and the mailing list, expressing interest in Docs, Python, and infrastructure. In the issue tracker, the group actively collaborated on shaping the new contributor experience by providing feedback for the Fedora Docs front page.

Additionally, the group approved the collection of their public activity for this report, explicitly exempting their Matrix chat to preserve a relaxed environment for newcomers. Work also began on auditing and updating the Fedora Apps directory.

Decisions

• The group decided to permit the collection of their mailing list, Discourse, and issue tracker data for the This Week in Fedora report, but explicitly excluded the Join Matrix channel from being scraped in order to protect it as an informal, friendly space for new members.

Contribution opportunities

• The Fedora Docs team is seeking time-sensitive feedback on adding a "Contribution" section to the Docs homepage. They are looking for ideas on which topics, SIGs, and non-technical contributions to highlight to attract newcomers.
• Exploratory work has started to update apps.fedoraproject.org. While a contributor has been assigned, the issue highlights ongoing infrastructure needs such as reviewing current web apps, finding unlisted services, and updating software stacks.

Learn more about the Fedora Join team.

Ambassadors

Planning for FOSDEM 2027 has officially begun, with Justin Wheeler and Daniel Mellado acting as event co-owners for Fedora. Applications for a Fedora stand and the Distributions DevRoom have already been submitted. Additionally, organizers are currently negotiating a single, larger hotel block for Fedora and CentOS contributors at the DoubleTree by Hilton Brussels City.

Decisions

• Applications for a Fedora stand and the Distributions DevRoom at FOSDEM 2027 have been officially submitted.
• A single, shared hotel block at the DoubleTree by Hilton Brussels City is being negotiated for Fedora and CentOS contributors attending FOSDEM 2027.

Contribution opportunities

• Contributors planning to attend FOSDEM 2027 are encouraged to monitor the mailing list and wiki for upcoming details on booking rooms within the Fedora and CentOS hotel block.
• Community members with questions or ideas about the event are invited to engage with the organizers by replying directly to the mailing list thread.

Learn more about the Ambassadors team.

Diversity & Inclusion

This week, the Diversity & Inclusion team resolved a discussion regarding the automated collection of group data for this weekly report. The team evaluated which communication platforms should be included in the data ingestion.

They concluded that while indexing asynchronous platforms like Discourse and the issue tracker is acceptable, the Matrix chat room should be excluded. This decision was made to ensure the chat remains a safe space for discussing sensitive and evolving topics without the risk of incomplete thoughts being broadcasted broadly.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation / GNOME group prepared for the upcoming Fedora 45 release by organizing Blocker Review Meetings to evaluate blocker bugs and freeze exceptions. On the issue tracker, members discussed a proposal to add LiveFaceSwap Desktop to Fedora's third-party software repositories and reviewed a request to include the group's communication channels in this weekly report.

Additionally, the group continued discussions on the need to automatically update the appstream-data package to ensure modern software store GUIs like GNOME Software and KDE Discover have up-to-date metadata. A community member volunteered to look into the current manual data update process to help move the automation effort forward.

Contribution opportunities

• Review and vote on proposed blocker bugs and freeze exceptions for the Fedora 45 release using the blockerbugs app prior to the weekly review meetings.

Learn more about the Workstation / GNOME team.

KDE

During the week, the KDE SIG focused on refining the default Fedora KDE Plasma installation and resolving release blockers. A major effort is underway to reduce the default installation footprint by transitioning Akonadi's default backend from MySQL to SQLite. Additionally, the group is modernizing the default application set by swapping out the K3b optical mastering tool in favor of Fedora Media Writer.

The team also investigated and implemented a workaround for a Fedora Kinoite login bug triggered during OS rebases, securing the fix in time for the Fedora 44 Beta. Routine Fedora 45 Blocker Review meetings were scheduled to evaluate and vote on outstanding final blockers and freeze exceptions.

Decisions

• Initiated a transition to replace k3b with Fedora Media Writer as the default image writer in the desktop comps (issue #729).
• Merged a change to the akonadi-server package alternatives priorities so new installations default to SQLite, while safely preserving the MySQL backend for existing users to avoid disruption (issue #730).
• Implemented and deployed a systemd service workaround for missing /etc/shadow entries during Kinoite rebases to unblock the Fedora 44 Beta (issue #684).

Contribution opportunities

• Community members are encouraged to vote on proposed blockers and freeze exceptions in the blockerbugs app prior to the weekly Fedora 45 Blocker Review Meetings.
• Testing and feedback are needed for developing an automated migration path or user alert strategy for existing Akonadi MySQL users transitioning to SQLite (issue #730).
• Developers can contribute to the long-term structural fix for user provisioning in atomic desktops by helping the project move away from nss-altfiles (issue #684).

Learn more about the KDE team.

Server

The Server Working Group focused heavily on Fedora 45 release testing and advancing the Ansible support project this week. Testing of the F45 20261003 build yielded successful results across various installation methods, while a critical blocker involving the Server KVM image and initial-setup hanging on the serial console was diagnosed and resolved via a patch to the systemd service.

In addition, the group continued to refine its Ansible support strategy. Members are finalizing continuous integration for the fedoraserver.general Ansible collection and are preparing to package it for Fedora once published on Ansible Galaxy. The group also discussed outreach strategies for upcoming conferences, such as FOSDEM and the Ohio Linux Fest, and prepared for the upcoming F45 Blocker Review meetings.

Decisions

• Decided to restore the quiet-console.conf drop-in lines for initial-setup.service to resolve the Server KVM image boot issue on serial consoles (Ticket #216).
• Agreed to develop a "turnkey solution" to simplify Ansible usage for end-users, consisting of a core fedoraserver.general collection to be published on Ansible Galaxy and a secondary management wrapper package (Ticket #194).
• Decided that Fedora 45 RC testing must be divided among working group members and completed within 1-2 days of a test release's availability (Meeting 2026-09-30).
• Decided to follow the US schedule for the upcoming winter time switch for meeting times (Meeting 2026-09-30).

Contribution opportunities

• Emmanuel Seyman requested testing for the experimental Wildfly RPMs available in their Copr repository before submitting them to Fedora proper (Meeting 2026-09-30).
• The group is seeking volunteers to help test the upcoming Fedora 45 Release Candidates, specifically requesting assistance with the default partitioning and remote install tests (Meeting 2026-09-30).

Learn more about the Server team.

Infrastructure

The Infrastructure group focused heavily on system maintenance this week, successfully executing a major planned outage to apply package updates, perform firmware upgrades, enable SecureBoot on x86 bare-metal hosts, and migrate several backend databases (including Koji and Datanommer). The team also actively troubleshot various access and system issues, such as clarifying that hardware security keys (ed25519-sk) will fail against legacy RHEL 8 systems, and resolving a configuration error that caused 403 errors on www.fedoraproject.org due to aggressive anti-scraper rules.

Additionally, the Forgejo migration continues to make progress, with MultiVM runnerhost support implemented on the distgit-staging environment. The team is also beginning a formal investigation to document workflow impacts and tooling requirements ahead of Red Hat's planned Bugzilla sunset and the proposed move to Forgejo.

Decisions

• The team confirmed that hardware-backed SSH keys (id_ed25519_sk) will remain unsupported on pkgs.fedoraproject.org. The server runs RHEL 8, which lacks the required OpenSSH 8.2+ package, and the team decided not to risk uplifting the OS or maintaining a custom OpenSSH fork prior to the upcoming Forgejo migration.
• Scraper-blocking rules that inadvertently returned 403 errors on www.fedoraproject.org have been narrowed in scope to only protect the wiki. This ensures regular users routed by search engines can view the site normally, and the www alias will now redirect 301 to the apex domain.
• The sysadmin-eln group has been granted permissions to execute the elnbuildsync.yml Ansible playbook on batcave, empowering the ELN team to trigger deployments without requiring manual intervention from Infrastructure team members.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on stabilizing Fedora 45 ahead of its release, holding multiple blocker review meetings to evaluate and vote on blocker bugs and freeze exceptions. Alongside release preparations, the team addressed several Fedora 46 Rawhide compose breakages, resolving issues related to SELinux policy mismatches during offline labeling, oversized images on aarch64, and missing packages in the f46 tag. Additionally, a new community discussion was opened proposing the preservation of meaningful, per-file modification times for Git-derived source packages (such as linux-firmware) to improve traceability for users.

Decisions

• Accepted as a Final Blocker: Bug 2541402 - systemd-imds-early-network.service fails at boot with AVC denials.
• Accepted as a Final Blocker: Bug 2537341 - oo7-portal not installed by default after upgrading to F45.
• Accepted as a Final Freeze Exception: Bug 2536815 - dnf command not available in kickstart, f45 netboot installer (rejected as a hard blocker).
• Accepted as a Final Freeze Exception: Bug 2530897 - F45 grub boot fails with "invalid magic number" when installed to FW RAID multiple times from the GTK installer.
• Added Fedora-Server-NetworkInstaller and Fedora-Everything-NetworkInstaller to the f46 tag to fix broken Rawhide composes.
• Processed non-responsive maintainers lkundrak and gui1ty, effectively orphaning their unmaintained packages.
• Blocked and retired the Charliecloud repository for F46 onward to prevent it from triggering FTBFS errors during mass rebuilds.

Contribution opportunities

• Maintainers and community members are invited to provide input on a proposal to preserve meaningful per-file mtimes for Git-derived sources (such as linux-firmware), specifically regarding implementation methods and whether to use Git author or committer dates.
• Release Engineering assessment and coordination is requested on the F46 Change: LMDB 1.0 transition ticket to plan side-tag merging and potential rollback procedures before F46 branching.

Learn more about the Release Engineering team.

Quality

The Quality team is heavily focused on Fedora 45 Final release validation and blocker bug reviews. Testing activities are in full swing, with the CoreOS test days concluding and the Anaconda installer features test days (covering WebUI, Remote WebUI, and Stratis support) currently running. Additionally, the team successfully exported the results for the KDE Plasma 6.7 test days and is preparing for upcoming test days focusing on Podman Conmon-v3 and GRUB EFI for Confidential Computing.

In addition to release preparations, the team contributed their workflow requirements for the upcoming Bugzilla sunset and proposed transition to Forgejo, highlighting critical needs like Bodhi integration, anonymous access, and cross-component search capabilities. There is also an ongoing community discussion regarding a proposal to preserve meaningful per-file modification timestamps (mtimes) for Git-derived sources, which could significantly improve the inspectability of packages like linux-firmware.

Decisions

• It was decided to downgrade rpmlint spelling errors to warnings rather than turning them off globally across all packages (Ticket #591).
• Accepted Bug 2541402 as a Final Blocker due to systemd-imds-early-network.service AVC denials, noting that disabling the service by default would be an acceptable resolution (Blocker Review).
• Rejected Bug 2538553 (Czech keyboard layouts) as a final blocker due to the high risk of regressions and because the behavior only triggers on custom configurations rather than the default installer path (Blocker Review).
• Rejected Bug 2536815 (dnf not available in kickstart environment) as a Final Blocker, but accepted it as a Freeze Exception (Blocker Review).
• The _check_install_source test will no longer look for /tmp/syslog on network installers following the migration to image-builder (Ticket #948).
• The Podman Conmon-v3 test day is postponed by one week to 2026-10-12 to allow time for adjustments to a Podman PR (Ticket #941).

Contribution opportunities

• Testers are encouraged to participate in the Anaconda installer test days to evaluate WebUI for Atomic desktops, Remote WebUI, and Stratis support.
• Community feedback is sought on the proposal to preserve Git-derived per-file mtimes in RPM packages.
• A reviewer is needed for a pull request to fmf-tests to update Azure consumer cloud test results to the wiki (requested during the Quality Meeting).
• Help is requested to manually test SAS controllers and disks for F45 or to collaborate with the Server SIG for future automated testing (Ticket #946).

Learn more about the Quality team.

Websites and Apps

The Websites and Apps team implemented a clearer visual distinction on the Fedora download pages to highlight release-blocking deliverables. Star icons are now displayed next to images that have passed basic functionality tests performed by the Quality team, helping users identify the most stable and recommended installation options.

Other activities this week included identifying outdated references to Zanata on the Flock Call for Proposals template which need to be removed to avoid unnecessary work for translators. The team also fielded infrastructure meeting reminders and greeted new contributors offering UI/UX and web development help in the Websites chat.

Decisions

• A design change is now live on the Fedora download pages adding a star icon and a "Learn More" footnote to all release-blocking deliverables to clarify which images have guaranteed testing from the Fedora Quality team.

Contribution opportunities

• Contributors can help clean up outdated CMS templates (such as old Zanata references in the Call for Proposals page) to prevent translators from doing unnecessary work on disabled or obsolete text.
• New contributors looking to help with redesigns, UI/UX, bug fixes, or documentation are encouraged to read the room details in the Fedora Websites chat to discover current website projects and needs.

Learn more about the Websites and Apps team.

Design

This week, the Design team focused on creating initial concepts and technical specifications for the new CDUX logo, which will feature a duck incorporating UI elements and the Bezier tool. The team also began planning visual assets for the upcoming F45 Virtual Release Party and committed to providing a higher-resolution SVG Fedora logo for the fedora-logos package. This fix will address pixelation issues on the GDM login screen that occur when fractional scaling is enabled in Fedora 41 and later.

In the Design Matrix chat, team members discussed logo approval for Microsoft Ignite stickers and exchanged ideas with GNOME engagement members regarding Penpot automations and AI-assisted workflows. Finally, congratulations are in order for Emma, who recently began a part-time Masters in Service Design!

Decisions

• The Design team is no longer taking Fedora Badge requests in their main ticket queue; these must now be logged directly in the badges queue, which is currently facing a lack of dedicated designers. (Ticket #86)
• The official EPEL Steering Committee badge design was approved by the committee, finalized, and successfully published to the badges system. (Ticket #60)
• The team approved the inclusion of their public Matrix chat data for the collection of these weekly reports. (Ticket #83)
• The team confirmed they have no workflow dependencies on Bugzilla and are completely unaffected by its upcoming sunset, as they exclusively use Forgejo. (Ticket #88)
• The upcoming CDUX logo will be designed using simple black line art and solid colors without gradients to guarantee easy CMYK color conversion and sticker production. (Meeting Notes)

Contribution opportunities

• Anyone in the Fedora community is welcome and encouraged to contribute sketches and visuals inspired by the mindmap for the upcoming F46 Wallpaper.
• The Fedora Community Operations team is seeking design support and visual assets (thumbnails, Matrix room icons, Restream backgrounds) for the Fedora Linux 45 Virtual Release Party happening on October 30, 2026.

Learn more about the Design team.

Docs

This week, the Docs team implemented important changes to standardize contribution workflows. Direct pushes to main and prod branches have been disabled across all docs/* repositories; all contributors must now use forks and pull requests to submit changes. The team is also testing a new real-time collaborative writing tool via a CryptPad instance hosted in CommuniShift.

Additionally, discussions are ongoing regarding structural improvements to the Docs site. This includes evaluating whether to merge Antora components so content from different SIGs can be combined seamlessly, and determining the best way to consolidate scattered multimedia documentation. Finally, the team opted into having the "This Week in Fedora" summary bot monitor their ticket trackers to boost the visibility of their work.

Decisions

• Direct pushing to main branches is now disabled across all docs/* repositories. Non-admin contributors must fork the repository and submit a pull request, which now requires at least one approval before merging.
• The team agreed to let this weekly report collect the entire Docs organization's ticket trackers rather than summarizing their Matrix alert chat room.

Contribution opportunities

• The team is seeking volunteers for the Fedora Docs Captains pilot program to act as documentation liaisons for SIGs like Kernel, Multimedia, and AI/ML.
• Contributors are needed to write detailed image descriptions (alt text) for screenshots in the Beginner's Guide to meet accessibility standards.
• Help is requested to review, categorize, and organize scattered multimedia documentation across Quick Docs into a unified section.
• The team is looking for someone to help configure Zabbix monitoring for OpenShift Docs site builds to automatically track and report failures.

Learn more about the Docs team.

Legal

This week, a question was raised on the legal mailing list regarding the licensing of the Slint UI Framework. A contributor is looking to package the software and asked for clarification on whether utilizing the framework solely under the GPL-3.0-only option of its multi-license scheme is acceptable for Fedora. Additionally, they sought input on how the project's inbound MIT-0 contribution license interacts with its outbound licensing options.

Contribution opportunities

• Legal experts and community members can contribute by replying to the licensing inquiry regarding the Slint UI Framework, specifically confirming the viability of using the GPL-3.0-only option for Fedora packaging and explaining the compatibility of its inbound MIT-0 contribution policy.

Learn more about the Legal team.

COPR

Pavel Raiskup announced a planned Fedora Copr outage scheduled for October 1, 2026, at 06:00 UTC, lasting approximately two hours. During this window, build queue processing was paused and the frontend/web UI was unavailable to accept new tasks, though DNF packages and repositories remained accessible.

The purpose of this downtime was to deploy the latest development versions of the copr-* packages to the infrastructure machines, tracked under infrastructure ticket #13597.

Decisions

• The Copr team scheduled a two-hour infrastructure outage on October 1, 2026, temporarily halting build queues and web UI access to deploy package updates.
• It was decided to keep the Copr download server online during the update so that hosted DNF packages and repositories remained continuously available to external users.

Learn more about the COPR team.

EPEL

The EPEL team discussed the potential sunset of Red Hat's Bugzilla instance and its impact on EPEL's workflows, noting a strong preference for a Fedora Bugzilla instance over Forgejo due to the operational need to transfer issues between components. Maintenance efforts are currently heavily focused on an upcoming Qt6 update in EPEL9 to proactively handle llvm22 changes before the RHEL 9.9 release, alongside various CVE fixes for djvulibre and ffmpeg.

The release engineering team is preparing automation playbooks for koschei minor mass branching and minor EOL processes. They are also actively tracking infrastructure changes for the upcoming EPEL 9.8 archive snapshot and the complex EPEL 10.2 retirement / EPEL 10.3 switch.

Decisions

• Due to a lack of maintainer response, proven packager privileges were used to merge a fix for CVE-2025-53367 in djvulibre.

Contribution opportunities

• A community member is seeking a sponsor or an existing packager to co-maintain and branch autossh for EPEL 10.
• Contributors are needed to bring mailman3 to EPEL 10 to assist Releng with moving mailman to RHEL 10.
• Help is requested to get the incus package into EPEL 10 following its 7.0.0 LTS release on Rawhide.
• Assistance is needed to backport a fix for an ffmpeg heap-buffer-overflow CVE in EPEL 10 (version 8.1).

Learn more about the EPEL team.

ELN

The ELN SIG held a brief meeting on September 29. The main topic of discussion was a large Architectural Decision Record (ADR) pull request focused on the unification of bootc and CoreOS. Contributors discussed how ELN is envisioned to fit into this new structure as a layer built upon one of the proposed flavors.

Learn more about the ELN team.

Atomic

The Atomic group met to review the first draft of an Architectural Decision Record (ADR 002) proposing a unified strategy for Fedora CoreOS and Atomic. The draft outlines a three-tier architecture (base, flavor, and product) and standardizes on Konflux for image building; it is currently open for community review and feedback.

On the issue tracker, significant attention was given to improving the experience for downstream consumers building derived OCI images. This included discussions on how to handle Fedora trademark compliance (Ticket #125) and exploring ways to publish OCI images without Fedora-specific packages (Ticket #132). Other notable activities included a proposal to ship smartmontools for disk health monitoring (Ticket #135), fixing systemd checks that break the composefs backend (Ticket #133), and addressing package versioning and compose bugs across Fedora 45 and Rawhide.

Decisions

• It was decided that official Atomic Desktops images cannot use generic package replacements because Fedora branding is required. To aid downstream users, the team will instead focus on simplifying the package swap process and writing proper rebranding documentation (Ticket #125).

Contribution opportunities

• Reviewers and Subject Matter Experts (SMEs) are requested to provide feedback on the draft ADRs for unifying Fedora CoreOS and Atomic.
• Help is needed to identify which GUI applications can be included to display SMART data for users across the various desktop environments.
• A contributor is requested to submit a Pull Request removing the ConditionPathExists=/run/ostree-booted condition from specific systemd unit files to fix compatibility with the composefs backend.

Learn more about the Atomic team.

CoreOS

The CoreOS team successfully wrapped up the Fedora 45 Test Week, reporting that the F45 release schedule is on track without any failing packages requiring retirement. In infrastructure and pipeline matters, several issues were resolved, including failing kola-azure jobs, an insecureAcceptAnything policy block causing upgrade failures, and Vim installation conflicts on testing-devel. The team is actively investigating a new SELinux denial related to systemd 262 that breaks cloud tests on F45/F46, and working around dead AWS regions that caused garbage-collection job failures.

During their weekly meeting, the group discussed allowing this weekly report to gather data. They opted to pause Matrix channel data collection for the bot until the Fedora Council finalizes a formal opt-in policy, choosing to rely on GitHub repositories and meeting logs in the meantime. Additionally, members agreed to consolidate legacy meetings to improve cross-team collaboration.

Decisions

• Merge the legacy CoreOS Wednesday meeting and the legacy bootc Tuesday meeting into a single meeting to encourage cross-pollination between the communities. (Meeting log)
• Hold off on allowing LLM bot data collection in the CoreOS Matrix room until the Fedora Council establishes a formal opt-in privacy policy. (Meeting log)

Learn more about the CoreOS team.

IoT

The Fedora IoT Working Group reviewed their release status, noting that the Fedora 45 Beta freeze is complete and the final freeze begins next week. Both stable and Rawhide composes are currently healthy, and contributors are conducting hardware upgrade and installation tests leading into the final freeze.

In addition to routine release management, the team opened investigations into moving toward device-specific ARM images using arm-image-builder, assessing the impact of recent DNF repository path changes on image builds, and establishing a VM-based testing workflow to make hardware testing more accessible. The group also agreed to collaborate with the Fedora RISC-V Working Group to enable IoT support for RISC-V boards.

Decisions

• Drop support for Fedora 42 and older releases; any tracker issues related to these versions will be closed. (Meeting Log)
• Investigate transitioning from generic images to device-specific ARM images via arm-image-builder and IoT Compose. (Issue #141)
• Assess the impact of the new DNF .repo path configuration on bootc and Bootable Image Builder (BIB) workflows. (Issue #140)

Contribution opportunities

• Help is needed to run Fedora 45 nightly tests on any available physical hardware (especially aarch64 devices or modern hardware with accelerators like Orin) to assist with the final freeze.
• Community members with spare cycles are encouraged to review the Fedora IoT issue tracker to help close or fix open bugs.
• Contributors interested in QA can assist in evaluating VM-based hardware testing strategies to better share the validation workload across the team.

Learn more about the IoT team.

ARM

The ARM mailing list received announcements for two Fedora 45 Blocker Review meetings. The first meeting was held on September 28 to review four proposed blockers for the Final release. The second meeting was scheduled for October 5 to evaluate two proposed blockers and two freeze exceptions.

Contribution opportunities

• Review and vote on proposed blockers and freeze exceptions for Fedora 45 via the blockerbugs app prior to the review meetings to help shorten the meeting durations.

Learn more about the ARM team.

Cloud

The Cloud group's recent activities focused on refining image configurations to maintain feature parity and security alignment with upstream changes. A new request asks to add the SUSPEND_SAFE_FPR guest OS feature to Google Cloud Platform (GCP) images, specifically those patched for a page_reporting suspend Use-After-Free vulnerability (CVE-2026-74481). Additionally, a proposal was made to include the google-noto-sans-mono-fonts package in Cloud images to ensure the console appearance remains consistent with other Fedora editions following the recent kmscon update.

Contribution opportunities

• Provide feedback or assist with adding the SUSPEND_SAFE_FPR tag to GCP images containing the CVE-2026-74481 patch.
• Discuss the potential inclusion of google-noto-sans-mono-fonts to ensure consistent console rendering across editions by participating in Issue #448.

Learn more about the Cloud team.

Hummingbird

This week, the Hummingbird community saw ongoing forum discussions following the cancellation of their September meeting. A community member expressed enthusiasm regarding the project's use of superintelligence (SI) and container technology for building packages and customizing bare-metal systems.

Several inquiries were raised during the discussion, particularly regarding whether Fedora users have public access to this SI and any associated costs. The participant also asked about the feasibility of using SI agents to generate, lint, and highly optimize bootable container images-such as pruning irrelevant firmware or unused packages-based on specific hardware descriptions.

Learn more about the Hummingbird team.

Kernel

The Fedora kernel team discussed a proposal to split perf out of the kernel packaging and build it as a standalone package. Proponents noted that a standalone build would reduce BuildRequires (such as Java) for the kernel, lower the barrier to entry for new contributors intimidated by the massive kernel.spec file, and help resolve inconsistencies with perf headers.

However, reviewers raised concerns about the overhead of maintaining two separate packages, the risk of breaking user expectations if the perf version no longer perfectly matches the shipped Fedora kernel, and the potential disruption to vanilla kernel COPR builds that currently catch upstream bugs early. The primary blocker for the proposal is alignment with RHEL.

Contribution opportunities

• Contributors interested in the proposal to split perf out of the kernel packaging are welcome to join the effort to draft and submit a Change Proposal for Fedora 46.
• Community members and maintainers (specifically perf upstream maintainers) are encouraged to help advocate for this packaging split within RHEL, as their buy-in is a strict prerequisite for the change.

Learn more about the Kernel team.

AI & ML

During the week of September 28 to October 4, 2026, the AI & ML group focused on two major themes: group identity evolution and documentation modernization. The team successfully formalized its evolution into the Fedora AI Working Group (WG), reflecting a broader scope that encompasses both technical hardware enablement and community stewardship of open AI best practices.

On the documentation front, the group merged new issue templates that introduce lightweight bug reporting, structured content proposals, and a mandatory AI assistance disclosure checkbox. Furthermore, an active proposal was opened to migrate comprehensive packaging workflows and AI reference material from the legacy Fedora Wiki to the modern Fedora Docs platform to improve discoverability and maintainability.

Decisions

• The AI/ML SIG officially evolved into the Fedora AI Working Group (WG). This rebranding affects the broader community, as Matrix channels, Forgejo repositories, and the documentation site are being updated to reflect the unified identity.
• The group adopted structured issue templates containing an AI assistance disclosure checkbox for its documentation site to ensure all external community contributions comply with the Fedora AI policy.

Contribution opportunities

• An active project to migrate AI/ML content to Fedora Docs needs help converting legacy Wiki markup, structuring pages, and setting up :page-alias: redirects for existing Quick Docs.
• Contributors with automation experience are needed to help develop a new Fedora Agent Skill for reviewing Fedora Docs components and content.
• Help is requested to write automated ingestion scripts that pull build and release statuses directly from Koji and dist-git to maintain dynamic package tracking tables.

Learn more about the AI & ML team.

RISC-V

This week, the RISC-V group celebrated the release of the Fedora 45 RISC-V Beta images. Extensive testing on physical hardware-including Jupiter, P550, K3, and Titan boards-showed that the new images work smoothly. The group also made major strides preparing for Fedora 46, bringing the RISC-V content set almost fully into sync with the primary Fedora repositories, with over 19,000 packages now up to date.

Community members have been actively patching several packages that currently fail to build on the architecture, such as gdl, cmake, os-autoinst, and vxl. Meanwhile, kernel development continues for the upcoming 7.3 kernel, alongside stability improvements for the Omni kernel on ESWIN and P550 boards. Discussions in the Fedora RISC-V chat room and the fortnightly meeting confirmed that development is progressing well with no major blockers.

Decisions

• Users upgrading to Fedora 45 via dnf will need to manually install the fedora-repos-omni repository. The team decided to document this manual step on the wiki to assist users.
• The group agreed that removing board-specific kernel patches (such as the VisionFive 2 PCIe patch from the non-omni kernel) should only occur during major release transitions (like F45 to F46) to avoid disrupting existing users mid-cycle.

Contribution opportunities

• Assistance is needed to submit pull requests for fixing cmake tests on RISC-V.
• The group is looking for contributors to help test and maintain python-torch on the riscv64 architecture.

Learn more about the RISC-V team.

NeuroFedora

NeuroFedora contributors are preparing updates for the hdmf-common-schema, python-hdmf, and python-pynwb packages. During this process, the team noted that the listed maintainer has not performed a build or update in four years. These packages avoided the standard inactive packager flags because the broader NeuroFedora team has been keeping them up to date in the interim. A contributor has reached out directly and plans to initiate the nonresponsive maintainer policy if there is no reply within a few days. Further details can be found in the NeuroFedora Matrix room.

Learn more about the NeuroFedora team.

Gaming

This week, the Gaming group discussed packaging nbsdgames, a collection of 21 terminal-based games. The upstream maintainer reached out to the SIG to suggest its inclusion, noting it is easy to build and depends only on ncurses.

A packaging attempt revealed a binary name conflict between one of the games and the existing sos package. This was quickly resolved by building the games with an upstream option that prefixes all binaries with "nb" (e.g., nbsos). Additionally, the upstream maintainer noted that the games have been dual-licensed under Apache 2.0 to simplify the review process. An initial RPM is currently being prepared for official review.

Decisions

• To resolve a binary name conflict with the sos package, the upcoming nbsdgames package will use an upstream build flag to prefix all game binaries with 'nb' (e.g., nbsos).
• An initial RPM for nbsdgames was created and will be submitted for official Fedora package review.

Contribution opportunities

• Community members are encouraged to help review the upcoming package submission for nbsdgames once it is officially submitted.

Learn more about the Gaming team.

Perl

This week, the Perl group focused on routine package updates and minor configuration adjustments across several repositories. Maintainer Jitka Plesnikova successfully opened and merged pull requests to bump perl-Imager to version 1.037 and perl-DBI to version 1.654. Additionally, a change to the default fixed-width font in perl-podlators (switching from CW to CR) was implemented and merged into the project.

Decisions

• Merged a pull request to update perl-Imager to version 1.037 (Source).
• Merged a pull request changing the default fixed-width font from CW to CR in perl-podlators (Source).
• Merged a pull request to update perl-DBI to version 1.654 (Source).

Learn more about the Perl team.

Python

Miro Hrončok announced a plan to retire pypy3.10 from Fedora 46 and onwards, following the successful packaging of pypy3.12 and the cessation of upstream releases for pypy3.10.

To avoid disruptive surprises for existing contributors and users, pypy3.10 will be retained in Fedora 45 due to the proximity to the final freeze.

Decisions

• pypy3.10 will be retired from Fedora 46+ because upstream has stopped making releases and pypy3.12 is now available.
• pypy3.10 will remain in Fedora 45 since the release is very close to the final freeze.

Contribution opportunities

• Community members are asked to speak up and provide feedback if they have a compelling reason to keep pypy3.10 in Fedora 46+.

Learn more about the Python team.

Other Discussions

• In EPEL, ELN and Fedora packaging requirements, Jef Spaleta sparked a conversation about whether packages in the EPEL and ELN namespaces strictly adhere to Fedora packaging guidelines, which clarified that EPEL-only packages still must pass standard Fedora package reviews.
• A discussion regarding Bodhi: require_bugs and require_testcases have never been enforced - should they be? resulted in a consensus that previously ignored flags should default to off, and existing updates must be mass-edited to false before enforcing gating rules.
• Priscila Gutierres posted a Bioinformatics SIG Proposal to package essential genetics and computational biology tools, leading to cross-collaboration talks with the NeuroFedora SIG on the devel list.
• Christopher noted that GMail will remove ability to send email from @fedoraproject.org addresses soon, prompting contributors to seek alternative SMTP solutions and email clients for interacting with mailing lists.
• Miroslav Suchý asked contributors to Donate 1 minute of your time to test upgrades from F44 to F45 using an assumption-less dry run to preemptively catch and report package dependency issues.
• Gordon Messmer inquired about How can I contact the crypto team? to add AWS s2n-tls and AWS-LC; the thread detailed Fedora's crypto-policy constraints and concerns regarding AWS-LC's configuration format.
• Gordon Messmer also asked Would your package be easier to build if you could select specific releases of dependencies?, proposing upstream-release tracking branches in dist-git to build complex apps like vLLM as containers without hindering Rawhide maintenance.
• While coordinating an update of libxml2 and mini mass rebuild for F45, Zbigniew Jędrzejewski-Szmek prompted a side-debate over the etiquette of committing directly to branched package repositories without maintainer consultation.
• Julian Sikorski started a thread on the NTFS drivers situation, concluding that user-space tools and guestfs should continue relying on the mature ntfs-3g driver rather than the newer, less stable in-kernel ntfs3 driver.
• Several users reported Problems with https://koji.fedoraproject.org/ leading to 403 errors, which Kevin Fenzi attributed to temporary IP bans designed to block aggressive data scrapers hitting expensive endpoints.
• Other discussions included a proposal to pass --noclean to rpmbuild in Mock, a search for help for the Potentially non-responsive maintainer for julia, an RFC: splitting perf out of the kernel packaging, announcements for Fedora 45 RISC-V (non-official) Beta images and a Wiki resource for Fedora RISC-V + KVM, a scheduled Fedora Copr Outage on the buildsys list, the upcoming Fedora 45 Blocker Review Meeting, a warning about Package builds / updates accidentally missing from Fedora 45(+), and a request for IBus in update testing on the i18n list.

Package Orphaning

• Jakub Martisko gave a heads up about Deprecating and later Orphaning Atlas package (including the subpackages) due to upstream inactivity since 2018.
• Ben Beasley announced he is Orphaning python-fastapi and related packages due to the mounting maintenance burden caused by new opentelemetry dependencies.

Package Updates

• Yann Collette shared Some news about the Audinux activity for September, highlighting a successful F45 beta build, 16 new packages, and 336 updates.
• Pavel Raiskup announced the release of Mock v6.9 (cross-posted on the buildsys list), which introduces an unconditional --noclean flag to skip the obsolete %clean section during RPM builds.

All contribution opportunities

There are numerous highly accessible opportunities for community members to contribute to Quality Assurance, testing, and feedback, even without being part of a specific Special Interest Group (SIG). Anyone can help shorten review meetings by voting on proposed blocker bugs and freeze exceptions for Workstation, KDE, and ARM. Hands-on testers are needed to evaluate Anaconda F45 features, run IoT nightly tests, perform Fedora 44 to 45 upgrade dry-runs, and validate F45 Server Release Candidates. If you have specific hardware, testing is requested for SAS controllers and the new RISC-V Beta images. Furthermore, the broader community is encouraged to weigh in on structural proposals, such as keeping pypy3.10 in Fedora 46+, preserving Git-derived mtimes in RPMs, and resolving a GPL/MIT-0 licensing inquiry regarding the Slint UI Framework.

For contributors with skills in writing, design, and event coordination, there are excellent entry-level tasks available. Writers can help meet accessibility standards by authoring image alt-text for the Beginner's Guide, organizing scattered multimedia documentation, or structuring migrated AI/ML Wiki content. The Docs team is also recruiting Fedora Docs Captains to act as liaisons and seeks feedback on building a "Contribution" section for their homepage. Designers are invited to contribute visual assets for the F45 Virtual Release Party, sketch ideas for the F46 Wallpaper, or tackle UI/UX projects in the Websites chat. On the community front, Mindshare is seeking moderators, and open-source event organizers in the Philippines are looking to partner with local Fedora Ambassadors.

Contributors with backgrounds in packaging, development, and automation can assist several teams with critical maintenance and coding tasks. The EPEL group urgently needs packagers to branch autossh, bring mailman3 and incus to EPEL 10, and patch an ffmpeg heap-buffer-overflow CVE. Developers can also help maintain python-torch on RISC-V, rescue the julia package from retirement, or review the nbsdgames submission. Those with DevOps or automation experience are encouraged to update apps.fedoraproject.org, configure Zabbix monitoring for OpenShift Docs, write automated ingestion scripts for AI/ML tracking, or submit pull requests fixing systemd units for Atomic desktops.

05 Oct 2026 9:38am GMT

A bit late with the weekly recap this week, possible due to lower energy from getting my flu and covid boosters friday, but lets go...

04 Oct 2026 11:24pm GMT

04 Oct 2026 8:00am GMT

03 Oct 2026 3:29pm GMT

I have begun adding git repositories on my GitHub instance with code samples in a variety of programming languages. These languages are C, C++, Java and others as time passes. These samples may help people in their learning of coding, but it also is fun for me to write basic programs in varying languages and keep my hand in.

kathenasdg on GitHub

03 Oct 2026 10:39am GMT

Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it's just too hard for even experienced developers to do properly.

The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.

There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don't find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.

Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.

Have you heard that most AI bug reports are "slop?" Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)

AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don't have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.

That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.

Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.

I propose the following:

• GNOME maintainers should rewrite their AI contribution policies to permit AI-generated vulnerability reports, as I previously requested four months ago.
• Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.

We don't have to tolerate bad issue reports, but AI use alone should not be disqualifying.

Shouldn't humans rewrite AI-generated bug reports?

When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI's report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.

Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it's much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.

Rewriting issue reports also does not scale. Let's say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI's claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That's more work than everything else combined, and is unrealistic.

Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won't be as useful as a full report.

The CVE Wave Hits GNOME

The current wave of vulnerability reports is reflected in GNOME's CVE issuance trends:

The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.

(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)

Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.

The CVE Wave Hits WebKitGTK

A similar pattern holds for WebKitGTK:

CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit's own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.

There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.

I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.

Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program

My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It's already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)

The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany's Sovereign Tech Agency. I'm not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had - naively - seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.

I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:

Those numbers for 2026 reflect less than two months' worth of issue reports, so you can see why it was no longer sustainable.

After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack's professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.

At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.

Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.

Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it's not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.

Lessons from the Bug Bounty Program

Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.

I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.

I had hypothesized that GLib would be much better than libsoup. I'm not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.

A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It's likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.

Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.

Red Hat Scans GLib

Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I'm not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.

Red Hat's scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these "vulnerabilities" are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let's count all of them as false positives. That alone creates a 40% false positive rate. Ouch.

I don't have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.

It's rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.

Humans Still Useful

In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in critical findings.

Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.

Humanity Still Desired

Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It's pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.

We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.

Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:

• Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
• Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I'd like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
• Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
• Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You're not fooling anybody.

Maintain Perspective

Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they're not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.

I don't want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.

Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It's certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline - because issue reports should not stay confidential indefinitely - not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that's how you want to spend your volunteer time.

Rust

Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.

Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably - I would even say probably - outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME's Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.

To Be Continued…

I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.

02 Oct 2026 6:08pm GMT

Some like myself change many settings in whichever Operating System (OS) we are using. Under MacOS I change the naming for screenshots. On the commandline it can be accomplished with the command below.

defaults write com.apple.screencapture name "YourCustomName"

Have the naming you want. That is it.

02 Oct 2026 5:53pm GMT

This weekend has become the one where I have setup my new Elegoo Neptune Pro 3 3D printer. We will be testing and getting used to the device and working towards building some useful projects.



One of the first projects is to print cases for my Arduino UNO R3 devices.

Watch this space for future projects that incorporate 3D printed elements.

02 Oct 2026 5:30pm GMT

As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).

Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat's suggestions to encrypt your mail using GPG, and use the following email template:

Hi, I request a CVE for:

Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:

Request a CVE after making your issue report public. It's possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.

GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.

02 Oct 2026 3:00pm GMT

01 Oct 2026 10:00pm GMT

01 Oct 2026 8:00pm GMT

01 Oct 2026 6:00am GMT