In Some Changes to GNOME Security Tracking, I reported:

I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

27 Aug 2026 2:56pm GMT

27 Aug 2026 11:02am GMT

In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky. First, keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don't get an answer. More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account. It behooves the project to keep the maintainer (or other privileged role) list tidy.

There are a few reasons that trimming the maintainer list doesn't happen. First, it's boring, tedious work. Who wants to do that? Second, it's complicated work. What does it mean to be "inactive"? Third, it can lead to hurt feelings. People who earn privileges absorb that role into their identity and they don't want to let it go. This is a case where the perfect quickly becomes the enemy of the good (or okay-ish). Let's look at each of the reasons in turn.

Overcoming the objections

Project and community management tasks often end up on the "avoid: no fun" pile. They only seem like no fun because they are. But "fun" and "important for the project" aren't the same. Changing the air filter in my furnace isn't fun, but it's important for the health and safety of my family. Ideally, the inactive maintainer process is automated and runs regularly, but building that automation takes work. So if you go through the list and identify inactive maintainers once or twice a year, that's better than nothing.

"Inactive" can mean a lot of things. Does one activity in a six month period count? Does the activity have to be "sustained"? You can define it in the way that's most convenient to you. The goal isn't to be rigorous and precise, it's just some spring cleaning. You can start by just asking yourself "have I seen So-and-so around lately?" If the answer is "yes", then they're active. Again, it would be nice if you could automate it. You don't need to wait for that.

The feelings objection is the hardest one. We're all friends here and we don't want to hurt our friends' feelings. Unlike the other two, you can't really half-ass this one, so you need a policy that treats people with kindness. Let's move on to that.

Creating an inactive maintainers policy

Here are some features of a good inactive maintainers policy:

• Define "inactive" unambiguously. "We will remove maintainers who have not been active in N months, where 'active' means having done X, Y, Z." Six or twelve months is probably a good place to start. Be sure to include as many activities as you can reasonably determine. Think about what's important to keep that status: commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts, and so on.
• Define "inactive" generously. For the most part, the bigger concern is "is this person still in control of their account?" not "is this person earning enough points to keep their privileges?" So if someone's activity isn't what you'd want for them to initially earn maintainer status, that's probably okay.
• Check for inactive maintainers at a set time. If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point.
• Automate what you can. The time spent really does pay off pretty quickly. Fedora is a large and complicated project, so evaluating activity requires checking half a dozen services. Mattia Verga wrote a script that handles the checks and creates issues in a repo to track the inactive packagers.
• Don't remove anyone without notice. This is a big part of the "don't hurt your friends' feelings" requirement. Give people a chance to respond. Some will respond by being more active. Some will respond by saying "yeah, I no longer have the time and/or interest, so go ahead and drop me." Some won't respond at all. If someone wants to remain, let them.
• Conspicuously acknowledge the people you're removing. Add people as a "maintainer emeritus". Mention them in a blog post, release notes, or other vehicle for public praise.
• Allow easy reinstatement. If someone lapses and later wants to return, let them. Don't make them go through the whole process again. It's much easier to let a role go if you know you can easily get it back later.
• Leave some privileges for people on emeritus status. Keeping their name on a list of historical maintainers, letting them keep a project email address, giving them voting privileges on certain issues, and other privileges will help people who are inactive still feel valued in the project.

It will take a few tries to get the policy just right. Don't be afraid to try it.

This post's featured photo by Jan Canty on Unsplash.

The post Removing inactive maintainers appeared first on Duck Alignment Academy.

26 Aug 2026 12:00pm GMT

26 Aug 2026 5:30am GMT

26 Aug 2026 4:04am GMT

#
# https://github.com/rosset/myconfig/tree/master/brother-t420w-2026
#

                         ┌───────────────────────┐
                         │   Brother DCP-T420W                          │
                         │  (final architecture)                              │
                         │   IPP / PWG-Raster                                │
                         └──────────▲────────────┘
                                                         │
                         ┌──────────┴───────────┐
                         │      Network / IPP    │
                         └──────────▲───────────┘
                                                         │
              ┌─────────────────────┴─────────────────────┐
              │                                           │
    Linux / Raspberry Pi 5                         macOS 27 Golden Gate
        aarch64                                                            IPP Everywhere
              │                                                                                     │
        CUPS + PPD                                                                    CUPS
              │                                                                                     │
      br-box64-filter                                                           driver=everywhere
              │
            box64
              │
    Brother x86_64 filter
              │
       HBP / PWG-Raster
              │
              └───────────────────────► Printer

# Linux
# Printer Brother_T420W running with Linux (aarch64) + box64 + cups filter + modified ppd
# Status: working

=> uncompress opt-brother.tar.gz to /opt - final path = /opt/brother

=> copy /opt/brother/br-box64-filter to /usr/lib/cups/filter/br-box64-filter
    * make sure it is executable: chmod +x /usr/lib/cups/filter/br-box64-filter
    * this filter is a wrapper for the Brother LPD filter, which is a x86_64 binary
    * it uses box64 to run the x86_64 binary on aarch64 (rpi5 in my case)
    * if you try to use ./lpd/x86_64/brdcpt420wfilter directly, it will fail with "wrong architecture" error
    * DietPi v10.6.2 (Debian 13.6) + [BOX64] Box64 with Dynarec v0.3.4 nogit built on Apr 24 2025 09:54:47
    * the "key" thing is to keep the A4 Geometry: 2480x3508 (some wrappers are changing it to 2480x3507, which is wrong)
    
=> key files under /opt/brother:
    - /opt/brother/Printers/dcpt420w/inf/brdcpt420wrc
        -changed PageSize=Letter to PageSize=A4

    - /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        - changed from *cupsFilter: "application/vnd.cups-postscript 0 brother_lpdwrapper_dcpt420w"
            - to.      *cupsFilter: "application/pdf 0 br-box64-filter"

    - copy /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        to /etc/cups/ppd/Brother_T420W.ppd
    
    - finally add the printer:
        lpadmin -p Brother_T420W -E -v ipp://printer-IP:631/ipp/print -P /etc/cups/ppd/Brother_T420W.ppd


# V2 => Easiest path for Linux aarch64, avoid use of box64 and Brother
# x86_64 filter, use IPP (no everywhere) driverless printing instead
#
# Brother_T420W - V1
#    → Brother proprietary LPD + box64
#    → maximum Brother specific compatibility

# Brother_T420W_IPP - V2
#    → native CUPS driverless
#    → PWG Raster over IPP
#    → no x86_64 emulation

driverless \
    ipp://printer-IP:631/ipp/print \
    > /tmp/brother-ipp/dcp-t420w.ppd

sed -i 's/\*DefaultPageSize: Letter/*DefaultPageSize: A4/' \
    /tmp/brother-ipp/dcp-t420w.ppd

lpadmin \
    -p Brother_T420W_IPP \
    -E \
    -v ipp://printer-IP:631/ipp/print \
    -P /tmp/brother-ipp/dcp-t420w.ppd

cupsenable Brother_T420W_IPP
cupsaccept Brother_T420W_IPP

lpstat -v
lpstat -p Brother_T420W_IPP -l

# macOS 27 Golden Gate
# Printer Brother_T420W with CUPS + IPP Everywhere
# Kind: DCP-T420W - IPP Everywhere
# Driver version: 2.3
# Status: working

lpadmin -p Brother_T420W -E -v "ipp://printer-IP/ipp/print" -m everywhere

26 Aug 2026 3:43am GMT

By Ananya Nalavathu and Francois Gonothi Toure

Introduction

Open source communities run on contribution, and contribution runs on documentation, storytelling, and knowledge sharing. At the Fedora Project, that means the Fedora Community Blog and Fedora Magazine, two publications that give contributors a voice and give the community a way to stay informed, inspired, and connected.

This year, as part of my internship with the Fedora CommOps team at Red Hat Ireland, I got to experience that firsthand. Publishing 11 articles, running editorial campaigns, and coordinating content across sprints gave me a deep appreciation for how much thought goes into keeping Fedora's editorial standards consistent and how much easier that journey could be for new contributors with the right tool in hand.

That's exactly what my fellow intern Gonothi built during his Outreachy internship with the Fedora Project. In our final sprint together, we decided to share it with the community because tools that make contributions more accessible deserve to be heard. With that context in mind, I'll hand over to Gonothi to walk you through what he built and why.

What I built and why

My name is Gonothi, and I'm an Outreachy intern within the Fedora Project. The tool I built is called editorial-guide-ramalama, a Retrieval-Augmented Generation (RAG) assistant that reads Fedora's actual editorial guidelines and published articles, then checks your draft against them. It tells you whether your article meets the standards and exactly what to fix if it doesn't.

A regular chatbot would guess. RAG grounds every answer in the actual guidelines. When the tool flags a problem, it cites the specific guideline and gives you an actionable fix. Not "this looks off"- but "your article is missing the Read More tag, which is required per the Magazine guidelines."

RamaLama is the engine behind the whole tool, and it's a big part of why this project works the way it does. It runs open models locally as OCI containers, the same container tooling Fedora already uses, so there's no API key, no external service, and no data leaving the machine, which keeps everything private and fully reproducible. It also has RAG built in: RamaLama handles the ingestion, chunking, and retrieval itself (running Docling internally to parse and chunk the guidelines), so I don't have to wire together a separate vector pipeline. That combination of local inference, OCI-container packaging, and built-in RAG is what lets the tool ship as a single image that anyone can pull from Quay and run.

How it works

The tool supports both Fedora publications, Fedora Magazine and the Fedora Community Blog, each with its own editorial guidelines loaded as the primary source the model checks against. Switch publications in the sidebar, and the guidelines change accordingly.

The stack is built on RamaLama, Docling, Quay, and Streamlit, with small GPT-Generated Unified Format (GGUF) models benchmarked for quality versus size. The pipeline works like this:

Articles are pulled from both publications via the WordPress REST API; no static files are committed, and the corpus is always rebuilt from source and stays reproducible. RamaLama RAG runs Docling internally to parse and chunk the documents into a vector store, packaged as OCI images published to Quay at quay.io/fedora/editorial-guide-ramalama. To run a check, pull the relevant image and use either the Streamlit interface or the terminal; no build step required.

Paste a draft that meets the Magazine's standards, and the model confirms compliance, citing the relevant guideline. Paste one with known issues, a missing featured image, a missing Read More tag, and it flags each problem with an actionable fix.

One honest note: small local models have limits. editorial-guide-ramalama is great for catching common issues before submission. It is not a replacement for a human editor, and it doesn't try to be.

Why the open source community should care

What strikes me most about this project is not just what it does technically, but what it represents for contributor onboarding in open source communities. One of the biggest barriers for new Fedora contributors isn't motivation; it's knowing the unwritten rules. Editorial guidelines, packaging standards, community norms these exist, but they're scattered, and learning them through rejection is discouraging.

Tools like editorial-guide-ramalama lower that barrier. They don't replace human editors or community knowledge; instead, they give new contributors a first pass, a way to self-check before they submit, and a way to learn the guidelines through doing rather than through trial and error. That's exactly the kind of tooling that makes open source communities more accessible.

What comes next

This mini-project was the proof of concept that validated the RAG approach for Fedora editorial documentation. The same architecture is now feeding into a larger project applying RAG to RPM packaging guidelines, a higher-stakes domain where grounded, local, open-model AI can help contributors get packaging right.

The code is on the Fedora Forge at ai-ml/editorial-guide-ramalama. Pull the image from Quay and try it on your next draft before you submit.

Try it yourself

The tool is live and available now. Pull the image from Quay, paste your draft, and see what it says. If you're a new contributor, nervous about your first article, this was built for you.

Thank you to the Fedora community, our mentors Justin Wheeler, Dominik Kawka, and Carol Chen, and Outreachy for making this internship possible.

The post Meet editorial-guide-ramalama: An AI Assistant That Checks Your Fedora CommBlog and Magazine Articles Against Editorial Guidelines appeared first on Fedora Community Blog.

25 Aug 2026 12:47pm GMT

Across the Fedora project, a major unified focus is the urgent preparation for the Fedora 45 Beta Freeze on August 25, 2026. Multiple groups-including Release Engineering, Quality, and various architecture and desktop SIGs-are finalizing mass branching, managing fails-to-install (FTI) packages, and conducting Blocker Review meetings to triage critical issues, such as widespread rpm-ostree breakages caused by the recent RPM repository configuration relocation to /usr. Concurrently, significant infrastructure shifts are a central theme, highlighted by the decommissioning of pagure.io into a read-only static archive and the formulation of usage policies for the new Forgejo-based Fedora Forge. Finally, routine package and system maintenance remains a shared priority, with teams actively auditing inactive maintainers, coordinating mass rebuilds for EPEL 10.3 and RISC-V, and modernizing packaging strategies across language-specific ecosystems like Python, Perl, and Rust.

Announcements

Significant infrastructure shifts are underway as pagure.io transitions to a permanent, read-only static archive, cementing the new Forgejo-based Fedora Forge as the primary development platform. Accordingly, the Fedora Council is finalizing the Fedora Forge Usage Policy, which restricts the new forge strictly to Fedora-related projects, marking a departure from the previous general-use scope of Pagure. In brighter community news, the Fedora Badges service has been completely rebuilt from the ground up into a fast, modern single-page application and is currently heading to production.

As Fedora 45 approaches its Beta Freeze, developers are urgently reminded that all F45 system changes must be marked "Complete" by August 25. Concurrently, routine maintenance has identified over 200 inactive packagers for the F45 release cycle; affected contributors must comment on their tracking tickets to avoid being removed from the packager group. Finally, contributors and general Linux enthusiasts are invited to participate in the Fedora 45 Test Days starting August 17 to help evaluate major upcoming software changes-including GNOME 51, RPM 6.1, and OpenSSL 4.0-on both real hardware and virtual machines.

Council

This week, the Fedora Council focused on policy development and event planning. A revised draft (Version 3) of the Fedora Forge Usage Policy was published for an extended community feedback period before an impending Council vote. Additionally, the Council began brainstorming Call for Papers (CfP) themes for Flock to Fedora 2027, and initiated a discussion on clarifying the AI-Assisted Contributions Policy regarding commit message attribution.

See the detailed report for the Council team.

Learn more about the Council team.

FESCo

FESCo had a busy week managing package maintainer responsiveness, assessing feature changes for Fedora 45, and planning the requirements for Fedora's upcoming Bugzilla replacement. The committee addressed major regressions in rpm-ostree caused by the RelocateRpmRepoConfigsToUsr change, opting to grant maintainers a few more days to implement fixes before forcing a revert. In addition, FESCo handled multiple non-responsive maintainer tickets and approved several system-wide changes, including dropping the NIS profile from authselect and updating python-cloudflare for certbot.

Decisions

• FESCo approved the Change to Drop low-memory-monitor package, retiring it and starting a non-responsive maintainer process for its owner.
• The committee agreed to give developers until Friday to fix the rpm-ostree breakages caused by the RelocateRpmRepoConfigsToUsr change; otherwise, the change will be reverted for Fedora 45.
• FESCo approved the Authselect Remove NIS Profile change proposal.
• An updates policy exception for python-cloudflare was approved to facilitate a major update to certbot.
• Due to a lack of majority during the meeting, FESCo decided to return the vote for Changes Discussion Only On Devel List to the ticket.
• The following changes were officially marked as accepted for Fedora Linux 45: Anaconda WebUI Fedora Atomic, Encapsule isolated devel containers, Web Based Remote Installation Support for Atomic Desktops, and IBus 1.5.35.

See the detailed report for the FESCo team.

Learn more about the FESCo team.

Mindshare

The Mindshare group met on August 20, 2026 (meeting log) to share recent announcements and review open tickets. Key news included the production launch of Fedora Badges v3.x (Announcement, Try out) and Framework's announcement of their new Laptop 12 featuring an optional Fedora KDE pre-installation.

Due to low attendance, comprehensive ticket resolutions were largely deferred to asynchronous communication. Members reviewed event planning for Data Con LA 2026 (Issue 143) and All Things Open 2026 (Issue 128). They also discussed structural topics, including how to handle historically vacant Marketing and CommOps seats (such as CommOps Issue 145) on the committee.

Decisions

• The committee decided to alternate future weekly meetings between Matrix chat and video formats to improve attendance (see Issue #135).
• Committee discussions regarding the vacant Marketing and CommOps seats (e.g., CommOps Issue #145) will be moved to the main Mindshare channel to determine whether to bring those seats back to the broader electoral pool.
• It was decided to resolve Issue #131 asynchronously by the end of the month via a final summary comment.

Learn more about the Mindshare team.

Diversity & Inclusion

The Diversity & Inclusion group has begun early planning for the 2026 Fedora Week of Diversity. The event is tentatively scheduled around October 9th as a short, 2-to-3-hour virtual event featuring 10-to-20-minute talks. The current proposed theme is "Respect the Culture," though the group is actively open to brainstorming other options.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation Working Group focused on cleaning up default installations and third-party repositories. They discussed the removal of GNOME Boxes from the default installation, a change likely slated for version 52, while keeping GNOME Connections. Additionally, they approved the removal of PyCharm from third-party repositories due to its outdated Community Edition.

Elsewhere on the forum, users expressed concerns over the maintenance status of Ptyxis and suggested Fedora prepare a contingency plan. More details can be found in the Workstation Working Group Meeting Summary and the Ptyxis discussion.

Decisions

• Approved the removal of PyCharm from the Fedora Workstation third-party repositories, as the Community Edition no longer exists as a separate codebase. (Meeting Summary)
• Decided to remove GNOME Boxes from the default installation, effectively delaying the action until version 52, while keeping GNOME Connections in the default set. (Meeting Summary)

See the detailed report for the Workstation / GNOME team.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE group announced that KDE Gear 26.08.0 is built for Fedora 44+ and ready for community testing. Community discussions focused on user requests for changes to the Fedora repositories and spins, specifically regarding the inclusion of Kgamma2 for Wayland and a debate over offering a "Minimal Installation" option for the KDE desktop to reduce default application bloat.

In addition, the Fedora QA team notified the KDE mailing list about the upcoming Fedora 45 Blocker Review Meeting for the Beta release, encouraging early votes on proposed blocker bugs.

Decisions

• The KDE Plasma Edition SiG released the KDE Gear 26.08.0 update to Bodhi for community testing on Fedora 44 and newer.

See the detailed report for the KDE team.

Learn more about the KDE team.

Server

The Server working group held a meeting this week focusing on Fedora 45 release testing, Ansible support restructuring, and documentation improvements. A new member joined the group to help document homelab, Podman, and systematic backup strategies. Additionally, Adam Williamson announced the upcoming Fedora 45 Blocker Review Meeting, encouraging members to review and vote on proposed blockers in advance.

Decisions

• The group agreed to split the current 'post-installation' documentation article into several shorter, more specific articles (e.g., First steps, Networking, Storage, Security hardening, Automatic updates, Backups) housed in a separate subdirectory.
• The group decided that the Ansible postinstall role will be structured as a single role using boolean variables to toggle specific tasks, which will eventually be packaged as an Ansible Collection and distributed via both Ansible Galaxy and RPM.

See the detailed report for the Server team.

Learn more about the Server team.

Infrastructure

The Infrastructure team completed a major planned outage to apply updates, reboot servers, and advance the RHEL 10 migration, which now has only 33 hosts remaining. Notable infrastructure changes included moving download servers to BBR congestion control for improved syncing, preparing the pagure-ro01 VM as a read-only archive ahead of the pagure.io shutdown, and successfully migrating the Matrix moderation bot to official Fedora infrastructure. Additionally, the the-new-hotness bot was fixed to resume filing Bugzilla bugs after a token expiration.

In the community and services space, a discussion is ongoing regarding the deprecation of the retrace.fedoraproject.org server, as the maintaining ABRT team no longer exists. While QA finds the service valuable, it currently lacks active maintainers. Forgejo development continued with monitoring implementation and SSH enabled on staging, while several authentication bugs affecting FreeIPA and accounts.fedoraproject.org are under active investigation.

Decisions

• The pagure-ro01 VM is now live and will serve as the read-only static archive for the upcoming pagure.io turnoff.
• The official Matrix Moderation bot has been migrated to Fedora infrastructure (@moderation:fedoraproject.org), with a draft policy introduced for managing official Fedora Matrix rooms.
• The retrace.fedoraproject.org server is slated for retirement due to a lack of active maintainers, pending a final call for volunteer engineers.
• Download servers have been moved to BBR congestion control, resulting in significant package syncing gains.

See the detailed report for the Infrastructure team.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on the Fedora 45 release cycle, finalizing post-fixes for the mass branching process and preparing for the Beta Freeze scheduled for August 25. As part of this cycle, FTI (Fails To Install) packages in the NEW state were processed for retirement, and a Blocker Review meeting was announced for the upcoming Beta release. Furthermore, progress was made on infrastructure improvements, such as preparing the new Fedora 46 (Rawhide) openh264 builds for Cisco and enhancing documentation.

A significant operational shift highlighted this week is the full transition to self-service package unretirements. Maintainers opening unretirement tickets were directed to use the fedpkg request-unretirement command instead. To support this, the background tooling (toddlers) was updated with retry logic and fixes for Koji tag resolution on Rawhide. The team also handled routine requests to untag buggy updates (such as freeipa and bash-color-prompt) to prevent widespread test failures, and processed multiple EPEL stalled package handovers.

Decisions

• Package unretirements are now fully self-service. Maintainers should use fedpkg request-unretirement instead of opening Releng tickets, as advised in multiple unretirement requests.
• The Fedora 45 Beta Freeze will take effect on Tuesday, August 25, 2026.
• bash-color-prompt-0.96-1.fc46 was untagged due to unintended visual changes to the root terminal prompt.
• freeipa-4.13.3-1.fc46 was untagged to prevent a serious upgrade bug from gating all subsequent Rawhide updates.

See the detailed report for the Release Engineering team.

Learn more about the Release Engineering team.

Quality

Fedora 45 branching is mostly complete, though it was heavily complicated by the late-stage landing of the RPM repo config relocation to /usr. This required urgent patching across Anaconda, openQA, and Kiwi, and currently leaves ostree broken. Early manual validation testing for Fedora 45 is ongoing and has already surfaced notable bugs, including missing initial setup screens on non-graphical disk images (affecting Server and Minimal) and system freezes during shutdown.

In broader community news, a significant discussion highlighted performance and efficiency regressions caused by the default switch from power-profiles-daemon to tuned-ppd. Users and developers are actively debating whether to adjust the default TuneD profiles or revert the change entirely. Additionally, QA efforts are moving forward to formally propose replacing the unmaintained mcelog package with rasdaemon.

Decisions

• The group agreed to support an upcoming formal Change proposal to replace mcelog with rasdaemon by default, as mcelog is minimally maintained and fails on modern, unsupported CPUs. (Discussed in the Quality meeting and forum thread)

See the detailed report for the Quality team.

Learn more about the Quality team.

Design

This week, community members praised the newly revealed Fedora 45 wallpaper on the Fedora 45 Wallpaper Inspiration Poll. The team is already preparing for the next release, having recently held the Fedora 46 wallpaper mindmap call. In documentation news, the Design Docs have been revamped with newly published How We Work and Meetings pages.

On the tracking side, a contributor is asking for scoping clarification on the Community Personas project to determine whether deliverables should include a comic or just character illustrations. Additionally, older legacy repositories like designassets have been successfully migrated to the new design organization on Forge to preserve their history before Pagure is deprecated.

Decisions

• The legacy designassets repository (along with several others) was formally migrated to the new design organization on Forge to preserve historical content before Pagure is retired (Ticket #82).

Learn more about the Design team.

Docs

This week, the Docs team and community members engaged in a discussion regarding the Fedora Installer's recommendation for a separate /boot partition, exploring the technical constraints and historical reasons behind it. Additionally, a broken link reported on a Fedora test results wiki page was addressed and resolved after being properly routed to the Quality team.

Decisions

• Outdated links to the relval package documentation in the Release validation instructions wiki template were fixed by the Quality team. (Issue #61)

See the detailed report for the Docs team.

Learn more about the Docs team.

Internationalization

The Internationalization group held a meeting on August 17 to review the progress of Fedora 45 changes, bug triaging for Fedora 43, and upcoming test events. Three changes for Fedora 45 (Fontconfig 2.18, LibreOffice Dictionaries, and IBus 1.5.35) have been accepted and will be transitioned to the MODIFIED state before next week's ON_QA deadline. Contributors were also reminded of key Fedora 45 milestones approaching on August 25, including the Beta Freeze, Bodhi updates-testing activation, and the 100% Code Complete deadline.

Learn more about the Internationalization team.

Legal

Vitaly inquired on the legal mailing list about the licensing of a JavaScript port of CPython's argparse (thread). The question centered on whether the port could be licensed under PSF-2.0 alone, rather than carrying the full CPython license stack, since the original code was added in 2010. Richard Fontana followed up by addressing the question directly on the upstream pull request.

Learn more about the Legal team.

COPR

Branched Fedora 45 chroots, which are builds copied from Rawhide, are now enabled and available for use in Fedora Copr. This update was announced on the copr-devel mailing list.

Decisions

• Branched Fedora 45 chroots have been enabled in Fedora Copr (source).

Learn more about the COPR team.

EPEL

This week, the EPEL team's primary focus was preparing for the upcoming EPEL 10.3 mass branching scheduled for August 24, 2026. This process will create the EPEL 10.4 tags and involves temporarily disabling builds to the epel10-candidate target, as announced on the epel-announce and epel-devel mailing lists and discussed during the weekly meeting.

Additionally, the team discussed two package updates moving into testing: the new epel-release update for CentOS Stream 10 and a long-awaited ffmpeg compatibility package for EPEL 9. Both updates require community testing and feedback.

Decisions

• Proceed with the EPEL 10.3 mass branching on 2026-08-24, temporarily disabling builds to the epel10-candidate target during the process.

See the detailed report for the EPEL team.

Learn more about the EPEL team.

Atomic

This week, the Atomic group saw brief activity across two forum discussions. A moderator action took place on an older discussion regarding Lenovo shipping ThinkPad laptops with Fedora, splitting off newer posts into a dedicated topic for new AI-ready ThinkPad models.

Additionally, a discussion regarding the behavior of /opt and /usr/local as symlinks in Silverblue and bootc images received a response. It was clarified that existing systems heavily rely on this legacy behavior, and any proposed changes to make them regular directories would require a comprehensive migration path.

Learn more about the Atomic team.

CoreOS

The CoreOS group met on August 19, 2026 (meeting log) to review the Fedora 45 Release Schedule ahead of the beta freeze. The team evaluated several proposed Fedora 45 system-wide changes to determine their impact on Fedora CoreOS, updating their F45 tracker. Most reviewed changes, such as LLVM 23, CMake variable drops, and disabling vendor changes by default, are expected to be transparent to FCOS.

The group also discussed ongoing work and blockers. Incomplete branching for fedora-bootc images is currently holding up Rawhide and Fedora 45 progress. Ongoing investigations continue for the relocation of RPM repo configs (Issue #2172) and the impacts of an OpenSSL upgrade (Issue #2165) and RPM cryptographic policy changes (Issue #2085).

Decisions

• Determined that the DisableVendorChangeByDefault change does not require specific accommodation work for FCOS, though users performing derived container builds should be aware of potential impacts.
• Confirmed that the LLVM-23 and CMake_drop_install_vars transitions should be transparent to FCOS.
• Decided to adopt the Grub2LightForConfidentialComputing bootloader exclusively in future confidential computing efforts (e.g., sealed/UKI images), rather than utilizing it for general usage in F45.
• Assigned enablement and dependency testing for FESCO Ticket #3661 (conditional on Fedora 45+) to volunteer Angel Cervera Roldan.

Learn more about the CoreOS team.

IoT

The Fedora IoT Working Group met to discuss the status of stable and upcoming releases ahead of the Fedora 45 Beta Freeze on August 25, 2026. Fedora 44 remains stable, with testing progressing well on a new Greenboot update. However, both Fedora 45 and Fedora 46 have encountered critical installation failures that caused their OpenQA tests to be canceled. The group is actively triaging these bugs, particularly focusing on issues related to Anaconda and rpm-ostree.

Decisions

• File a bug against Anaconda regarding the recent installation failures and officially flag it as a blocker for the Fedora 45 Beta release.
• Open an official issue/bug tracker for the rpm-ostree failure impacting Fedora 45, as the primary maintainer is currently on PTO.

See the detailed report for the IoT team.

Learn more about the IoT team.

ARM

Adam Williamson announced the upcoming Fedora 45 Blocker Review meeting, scheduled for August 24, 2026, at 16:00 UTC on Matrix. The agenda includes evaluating 3 proposed blockers and 3 proposed freeze exceptions for the Beta release against the Fedora Release Criteria.

Learn more about the ARM team.

Hummingbird

The Hummingbird group held its community meeting on August 20, 2026 (summarized here). Key updates included the introduction of the Gorget project for managing source tarballs and dependencies, progress on the bootable host (which is dropping the "bootc" name for trademark reasons), and broader Fedora Atomic Initiative efforts to expand Konflux access outside of Red Hat. The group celebrated reaching 3,100 packages in the repository and over 500 users of their images on public GitHub.

A major topic of discussion centered around establishing contributor pathways and building trust within a highly automated, SLSA-compliant environment. The team acknowledged that current restrictions (such as build logs hidden behind private logins) clash with Fedora's open philosophy and act as a barrier to external contribution. To address this, they agreed to break the contributor ladder down into three distinct areas: infrastructure code, build system operations, and image content creation.

Decisions

• The bootable host project is dropping the name "bootc" due to trademark reasons (Meeting notes).
• Managed Konflux infrastructure on the Fedora instance is being made available outside of Red Hat; tenant access can now be granted to anyone with a standard Fedora account (Meeting notes).
• The Hummingbird contributor ladder will be broken down into three distinct pathways to accommodate different access levels and interests: core infrastructure code, internal factory/build system configuration, and image content creation (e.g., spec and container files) (Meeting notes).

Learn more about the Hummingbird team.

Kernel

The kernel-ark os-build branch has been rebased. This continues a standard cadence established since version 5.15, aligning with upstream releases. By rebasing near the end of a release cycle when outstanding merge requests are minimal, the team ensures that patches carried by Fedora remain no more than one release out of date. This practice maintains the project's spirit of openness and makes patches easier to apply to other trees.

Decisions

• The kernel-ark os-build branch was rebased, continuing the established cadence of rebasing for every upstream release (which will continue for 7.3, 7.4, etc.).

Learn more about the Kernel team.

RISC-V

The Fedora RISC-V group successfully concluded the mass rebuild for Fedora 45, leaving a delta of fewer than 1,000 packages. The team is preparing to analyze the remaining "fails to build from source" (FTBFS) packages and unresolved dependencies once another full delta rebuild is complete. In the weekly meeting, members also highlighted solid progress on building installer images utilizing Anaconda and image-builder.

On the hardware front, the team is actively debugging glibc mutex failures on Titan (DP1000) boards and has temporarily disabled some builder boards due to proxy issues. Additionally, members suggested starting Fedora 46 preparations earlier than usual to maintain momentum while the package delta remains manageable.

Decisions

• Temporarily disabled specific hardware boards in the build cluster due to a proxy failure (source).
• Enabled coredumps to investigate and resolve glibc mutex failures occurring on Titan (DP1000) boards (source).

Learn more about the RISC-V team.

Security

The Security group focused on privacy-enhancing initiatives and SELinux integration for systemd-run0 this week. During their August 20th meeting, the SIG debated adopting a package (ff-disable-ai-ml) that disables Firefox AI/ML features, ultimately concluding that a dedicated Privacy SIG would be a more appropriate home. Consequently, a draft proposal for a new Fedora Privacy SIG was created and is currently open for feedback.

In SELinux developments, discussions on the systemd-run0 policy issue thread yielded a path forward for making run0/systemd natively SELinux-aware. This upstream fix will dynamically calculate target user contexts, bypassing the current architectural limitations of PAM transitions via PID 1.

Decisions

• The proposal to move the ff-disable-ai-ml repository to the Security SIG was placed on hold in favor of creating a dedicated Privacy SIG. (Meeting Log)
• The group agreed to draft a proposal for a new Fedora Privacy SIG. (Meeting Log)
• It was agreed to pursue an upstream fix making systemd-run0 natively SELinux-aware, rather than relying on static policy rules to handle transitions. (Mailing List)

See the detailed report for the Security team.

Learn more about the Security team.

DotNET

This week, Amine Kheddache introduced a free AI chat platform called Ptero on the DotNet SIG mailing list. The tool requires no signup and provides access to multiple large language models. It is designed to assist C# and .NET developers with debugging, generating boilerplate code, brainstorming architecture patterns, and explaining complex concepts like LINQ and async.

Learn more about the DotNET team.

Perl

This week, the Perl group focused on routine package updates and continuous integration testing. Michal Josef Špaček opened and merged four pull requests (PRs 13 through 16) to bump the perl-Mozilla-CA package to version 20260813. In addition, Steve Traylen continued work on PR #5 for perl-SQL-Abstract to disable the Perl bootstrap, successfully triggering a Packit CI scratch build to test the configuration.

Decisions

• Merged updates to bump the perl-Mozilla-CA package to version 20260813 via PR #13, PR #14, PR #15, and PR #16.

Learn more about the Perl team.

Python

This week, the Python group clarified that redundant manual license file declarations can be safely removed from specfiles in favor of using %pyproject_save_files --assert-license unconditionally, provided the package requires flit-core 3.11 or newer (Drop second copy of LICENSE file?).

The group also agreed on a migration strategy for the backwards-incompatible flit-core v4 release. To avoid widespread build failures for packages pinning flit-core < 4, the primary package will be updated to v4 while simultaneously introducing a deprecated v3 compatibility package. This will allow time to gradually patch dependent users (Plan for flit-core v4).

Decisions

• Specfiles requiring flit-core >= 3.11 can safely drop manual %license directives and rely exclusively on %pyproject_save_files --assert-license (Source).
• The migration to flit-core v4 will be handled by updating the main package to v4 and providing a deprecated v3 compatibility package, allowing dependent packages to be patched incrementally over time (Source).

Learn more about the Python team.

Rust

This week, the Rust group discussed a proposal for a new RPM packaging strategy aimed at eliminating the large volume of empty feature subpackages by using conditional metadata dependencies instead. Contributors weighed the impact of the currently generated Rust feature packages, noting that while they constitute a significant percentage of Fedora's package count, their actual payload and size remain negligible. Additionally, a new package review request for rust-ssh2 was submitted.

See the detailed report for the Rust team.

Learn more about the Rust team.

Other Discussions

• Jakub Kadlčík provided an update on a prototype for a reimagined Fedora Package Review Process using Forgejo pull requests, custom Copr build scripts, and vendored dependency handling.
• Yann Droneaud asked if the kernel configuration and System.map files duplicated between /boot and /lib/modules could be deduplicated using symlinks, successfully testing a boot where symlinks pointed to /lib/modules.
• Orion Poplawski announced that the community.mysql ansible collection has been renamed and is seeking a new maintainer for the ansible.mysql collection.
• Following an s390x builder outage, Kevin Fenzi and Michel Lind discussed resource constraints and Koji lag metrics, noting that s390x builds are significantly delaying active maintainers.
• Petr Sklenar reported that an update to file 5.47 caused systemd .service files to be misidentified, breaking brp-mangle-shebangs; maintainers are advised to explicitly install unit files with 0644 permissions.
• Gwyn Ciesla volunteered to step in and save the matrix-synapse package after it was retired due to failing to install.
• Adam Williamson requested that developers stop hardcoding static lists of Fedora releases in their tooling, recommending automated endpoints like Bodhi's releases API.
• Henryk Paluch asked for clarification on the pagure.io decommissioning, and it was clarified that src.fedoraproject.org (dist-git) remains unaffected until a future migration to Forgejo.
• Bojan Smojver submitted a pull request to Bodhi to systematically address compose failures caused by hitting open file limits.
• Norbert Manthey proposed extending Fedora's default compiler flags (e.g., -fno-strict-overflow) to prevent overly aggressive optimizations that could introduce security vulnerabilities.
• Other discussions this week included a report of a nonresponsive maintainer for low-memory-monitor, stats from the inactive packager check for F45, a non-responsive maintainer check for ddcutil, an announcement that pagure.io is now a read-only static archive, a request to retire python-PyPDF2 and pdf-stapler, a call for package review swaps, the unretiring of bodhi-server, a reminder of the F45 Changes Complete deadline, and a notice regarding a license change in mysql-connector-java.

Orphaning packages

• Peter Hutterer announced he is orphaning evtest, evemu, and several X11 utilities as they are unmaintained upstream.
• Neal Gompa orphaned showtime because the upstream project now refuses bug reports from non-Flatpak builds; it was quickly adopted by Fabio Valentini.
• Lumír Balhar orphaned python-tiktoken, which is a leaf package.

Package updates

• Julian Anderson requested a Koji retrigger for golang 1.25.13 and 1.26.6 updates, which were then fixed by Alejandro Saez Morollon after identifying an upstream regression.
• Dan Horák issued a heads up for an update to sg3_utils-1.49 containing a soname bump, requiring a sidetag rebuild for dependent packages.
• Jerry James notified the list of a soname bump for z3 that will require reverse dependencies to be rebuilt.

New contributor introductions

• Jose Lopez introduced themselves as an embedded systems engineer interested in packaging, low-level Linux development, and eventually Linux kernel drivers.

Contribution opportunities

For contributors interested in Testing, Quality Assurance, and General Feedback, there are numerous entry-level opportunities across the project that do not require specialized team membership. Community members are highly encouraged to help with Fedora 45 early manual validation testing, test branched F45 builds, and participate in the Internationalization Test Week starting September 7. Users can quickly assist by testing the KDE Gear 26.08.0 Bodhi update, the new epel-release update, and the freshly launched Fedora Badges v3.x platform. Furthermore, anyone can help shorten release meetings by asynchronously voting on blocker bugs and freeze exceptions using the Blockerbugs app. General feedback is widely requested on several community-wide topics, including the Fedora Forge Usage Policy, Conflict of Interest Guidelines, AI-assistance attribution in commits, the Privacy SIG proposal, and the Ptero AI tool for .NET (mailing list thread).

Those with Writing, Design, and Event Organization skills are highly sought after to support project infrastructure. Documentation writers can tackle server-side "white spots" (like Podman containers, HPC, and domain controllers), review installer and partition layout guides, or update Workstation marketing materials to reflect that GNOME Boxes is no longer a pre-installed application. Artists and UX contributors are invited to help shape and illustrate the Community Personas project, review legacy assets in designassets, or propose new QA data visualizations in Ticket #923. On the events and community side, volunteers are needed to organize the 2026 Fedora Week of Diversity (FWD)-which has openings for schedule management, marketing, and video editing-or staff the Fedora table at All Things Open 2026 (Issue #128). Contributors seeking leadership roles can also look into open committee seats on CommOps (Issue #145).

Contributors proficient in Package Maintenance can step in to keep the distribution healthy by adopting orphaned packages, claiming retired packages using fedpkg request-unretirement, or co-maintaining packages currently facing the non-responsive maintainer process (Ticket #3678 / sponsors issue tracker). Language-specific packagers can provide feedback on the proposal for "features/extras" packaging without subpackages, assist with the Python flit-core v4 migration by patching dependency constraints, or review pending packages like rust-ssh2. Community members are also encouraged to participate in cross-team package review swaps to help unblock dependencies.

Finally, there are critical Systems Engineering and Debugging tasks for developers and sysadmins. The Infrastructure team welcomes newcomers to help port packages for the RHEL 10 migration and is urgently seeking 1-2 engineers to take over maintenance of the retrace (FAF) crash analytics server. System architects and engineers can jump in to investigate severe installation failures, such as IoT's Anaconda boot failure and rpm-ostree bugs, or analyze CoreOS's OpenSSL upgrade impacts and FESCO Ticket #3661 enablement. There are also specialized opportunities to investigate RISC-V mass rebuild build failures, help systemd-run0 become natively SELinux-aware upstream, or submit YAML manifests and container files to the new Hummingbird build factory using standard pull requests.

24 Aug 2026 7:52am GMT

Another week gone by, it's hard to understand that it's almost fall now.

22 Aug 2026 7:08pm GMT

Injection vulnerabilities, like cross-site scripting (XSS) or command injection, occur when we fail to properly encode untrusted output when inserting it into a trusted context. Before injecting uncontrolled or untrusted data, it's essential to encode, escape, or quote the data to prevent it from breaking out of its intended context.

Some security folks previously used to like to talk about "input sanitization." In practice, input sanitization is hopeless. Instead, nowadays we do the opposite and think about "output encoding." When you inject untrusted data into a new context, assume the data is always malicious, and encode, escape, or quote it to make it safe for use in that context. Let's look at some examples.

Pango Markup Injection

Here's a low-stakes example of Pango markup injection:

markup = g_strdup_printf ("<b>%s</b>,
                          my_user_provided_data);
gtk_label_set_markup (GTK_LABEL (label), markup);

The untrusted data is not escaped and may decide to inject its own Pango markup, or break out of any markup that you used yourself. For example, if the data is </b><span foreground="blue" size="x-large">Hello world!</span><b> then it can decide to be blue and extra large instead of the intended bold. That's not especially serious and probably not likely to be a security issue, but surely it's an unintended bug. If you're injecting an uncontrolled string into a Pango markup context, like a GtkLabel, then use g_markup_escape_text() first. (Pango markup can do other interesting things like hide characters or capitalize them. I'm not sufficiently creative to claim that's definitely a security problem, but perhaps attackers will be more clever than me.)

A real-world example: in this GNOME Shell issue report, the title of a desktop notification is able to use Pango markup to manipulate its own formatting. (At least, probably, because the issue report is unconfirmed. Looks plausible, though!)

Unix Shell Command Injection

Another good example is the Evince command injection vulnerability from a few months ago, where a malicious filesystem path is able to trick Evince/Atril/Xreader into executing arbitrary code. Evince expects the path of a file to open to be something like /home/foo/hello.pdf, but a malicious PDF instead provides the evil input --gtk-module=/home/foo/evil.so /home/foo/hello.pdf. If not quoted properly, we have a command injection vulnerability where --gtk-module is interpreted as a command line flag rather than as a path:

Incorrect: /usr/bin/evince --named-dest= --gtk-module=/home/foo/evil.so /home/foo/hello.pdf

Correct: /usr/bin/evince --named-dest=' --gtk-module=/home/foo/evil.so /home/foo/hello.pdf'

If you're constructing a Unix command line, as in the Evince example above, then use g_shell_quote(). Failure to do so is ruinous. (But beware: this isn't necessarily safe if you're using an actual Unix shell.)

XSS for Desktop App Developers

With that primer out of the way, let's consider what happens when you inject untrusted content into HTML (or CSS, or JavaScript).

I used to think XSS matters only for websites, and is surely not something that desktop app developers need to know about, right? Wrong, as I discovered five years ago when, to my surprise, Prakash (@1lastBr3ath) reported that websites could inject scripts into Epiphany's new tab page (about:overview) via malicious page titles. This on its own is not especially serious, but it's surely not supposed to be possible.

If your desktop app uses WebKitGTK or another web engine, you probably do need to think carefully about XSS. For example, before injecting untrusted data into HTML, we need to HTML-encode it, which Epiphany didn't do anywhere. In the simplest case, that looks like this:

char *
ephy_encode_for_html (const char *input)
{
  GString *str = g_string_new (input);

  g_string_replace (str, "&", "&", 0);
  g_string_replace (str, "<", "&lt;", 0);
  g_string_replace (str, ">", "&gt;", 0);
  g_string_replace (str, "\"", "&quot;", 0);
  g_string_replace (str, "'", "&#x27;", 0);
  g_string_replace (str, "/", "&#x2F;", 0);

  return g_string_free_and_steal (str);
}

Simply replace the few dangerous characters with HTML entities, and you're good to go. That doesn't work for HTML attributes, though, where the rules are slightly different. And it definitely doesn't work for CSS or JavaScript. Carefully review the OWASP Cross Site Scripting Preventing Cheat Sheet to understand what you can and cannot do.

Recent XSS Bugs in Epiphany

Anyway, back to the old about:overview bug report. Turns out, Epiphany had many similar vulnerabilities. I attempted to fix them all, but in fact, I had missed a spot. In this old commit, I recognized that a URL is untrusted data that must be encoded before I inject the URL into the error message. But I treated the error message of the GError returned by WebKit as if it's trusted and does not need to be encoded. In fact, the error message itself may contain a URL! Oops. Fernando Munoz recently noticed and reported several example URLs that could inject content into Epiphany error pages. I'm unable to share my favorite example URL here on WordPress, because WordPress is sanitizing it (yes, that is indeed ironic, considering my above recommendation to not do that). But the result of the injection looks like this:

So an evil URL can mess up the Epiphany network error page. That's not particularly serious, but Fernando found a second injection that is much worse, an XSS vulnerability in Epiphany's autofill implementation. Here, selector is formed using an untrusted DOM element ID provided by the web page itself. Notice that no output encoding is performed before the untrusted value is injected into the JavaScript command:

  page_id = webkit_web_view_get_page_id (WEBKIT_WEB_VIEW (view));
  world_name = ephy_embed_shell_get_guid (ephy_embed_shell_get_default ());
  script = g_strdup_printf ("EphyAutofill.fill(%lu, '%s', %i);",
                            page_id,
                            selector,
                            fill_choice);

  webkit_web_view_evaluate_javascript (WEBKIT_WEB_VIEW (view),
                                       script,
                                       -1,
                                       world_name,
                                       NULL,
                                       view->cancellable,
                                       autofill_cb,
                                       NULL);

Because the untrusted data here is already used as a quoted data value, one of very few cases where it is safe to inject untrusted data into JavaScript, this would actually have been safe if only Epiphany had JavaScript-encoded the value first, following the OWASP rules for JavaScript encoding: "Encode all characters using the Unicode \uXXXX encoding format, where XXXX represents the hexadecimal Unicode code point. For example, A becomes \u0041. All alphanumeric characters (letters A to Z, a to z, and digits 0 to 9) remain unencoded." But Epiphany did not do so. (I got confused by the OWASP rules and didn't realize how easy it was to make this safe, so I fixed it in a more complicated way instead, by removing the need for injecting the form ID.)

So how bad is this mistake? In Fernando's example, the ID of the evil form element is "a'); alert('XSS in private world'); var _=('", allowing the malicious website to run any script it wants. That might not seem so serious, because websites don't need to exploit any vulnerabilities to execute JavaScript… right?

Script Worlds

Websites are only supposed to be able to execute JavaScript in the default script world. Think of a script world as basically just a big namespace for all of your JavaScript: the default world is what the website itself uses, but desktop applications can create their own private script worlds in order to run their own scripts. In a private script world, you can manipulate the page's DOM as usual, but you have a separate environment for executing JavaScript code, so you don't have to worry about name clashes or scripts conflicting with each other. Also, website scripts cannot access your scripts.

In practice, web browsers inject their own scripts into every web page in order to implement various browser features. Epiphany uses a script to find the best web app icon for a web page, for example. These scripts use a private script world that websites should never themselves have access to. But in this XSS attack on Epiphany's form autofill implementation, the malicious website has managed to execute its script in the private script world. Now it can access whatever internal web browser features are available in that script world.

Unfortunately, there's one more relevant Epiphany feature implemented using scripts: the password manager. Epiphany's password manager is necessarily exposed to its private script world because Epiphany needs to execute JavaScript code in the web page in order to autofill passwords. Although there were no relevant bugs in Epiphany's password autofill code (which is totally unrelated to its vulnerable generic form autofill feature), this did not matter: if an XSS bug in any Epiphany feature can be abused to execute code in Epiphany's private script world, that code can access the password manager and exfiltrate all the user's saved Epiphany passwords for every website. (At least, probably, because I have not set up an attack website to test this. But I don't see why it wouldn't work!) So that's pretty serious.

Conclusion

I requested a CVE for the autofill vulnerability earlier today, but nowadays CVE requests usually take a couple of weeks, so I don't have one yet. It is fixed in Epiphany 50.6 and 49.9. If you don't have those versions yet, don't panic. To be exploited, you have to manually trigger form autofill by right clicking on a form and then selecting either "Autofill Personal Fields" or "Fill This Field," so that makes it much less scary. Even more fortunately, users probably won't ever do that, because selecting either option always causes Epiphany to reject all further mouse input, becoming unusable. Nobody has reported this bug before, so it seems safe to conclude zero people are using Epiphany's form autofill feature!

Update: I said it would take a couple of weeks, but a few hours later I received CVE-2026-77682. Red Hat has improved its response time!

20 Aug 2026 10:37pm GMT

20 Aug 2026 8:00pm GMT

If you've ever tried to make something work better by adding or changing a process, you may have noticed that the something got worse. Whether that worseness surprised your or not depends on if you've heard of the "J curve" concept. A J curve is any graph that looks like the letter "J": a sharp dip followed by a sharp rise.

The J curve in open source projects

The phenomenon appears in many fields - economics, medicine, and technology. Where might you see it in your project? Maybe you add automated tests to reduce the manual QA work you do pre-release. This should allow you to ship your releases faster. Except once you introduce it, you spend twice as much time fixing bugs because you find so many more. The next release ships slower. But once you've caught up, the benefits you expected appear. Bugs - particularly regressions - get caught (and therefore fixed) faster.

Similarly, you might start blocking changes that include vulnerable dependencies. This should improve security for your users. But the first time, every dependency is full of vulnerabilities. This, at least, makes the apparent security worse. And maybe the actual security as you take time to prioritize and fix vulnerabilities in dependencies that would have been "accidentally" fixed in routine updates anyway. Again, after you have a handle on the situation, the process works as intended.

Progressing through the curve

Recognizing where you are in the curve is important to navigating it. Are you still on the downslope? Have you leveled off? Are you on the way up? If what you're trying to change is measurable, then tracking those measurements will help. Of course, not everything is easily or meaningfully measurable. In those case, you can trust your intuition. Do things feel like they're still getting worse? Better?

The main thing is to make everyone aware of the J-ness before it starts. Acknowledge that things will get worse for a little bit and then you'll see the improvements. Avoiding surprise is the key to keeping people engaged, and keeping people engaged is the key to seeing the change through and not ending permanently in the "worse" state. Unfortunately, it's hard to answer the "how much longer will it take?" question; there's no magical way to know how long the curve is. Which leads us to…

Limits of the J curve

The J curve is a useful concept, but it's not an inviolable law of physics. While there are plenty of reasonable explanations for why the J curve phenomenon occurs, there's no guarantee that it will. Just because you think it will, does not mean it will. Sometimes, our ideas for making things better don't work.

As I said above, you can't predict where you'll go next - even if you've been meticulously tracking the thing you care about. This, combined with the "it might not get better" aspect, means you could be on an endless march into darkness. At some point, you have to decide it's time to bail out.

So what do you look for if you can't predict the future? Let's go to calculus class for a moment and think about the second derivative. In other words: the rate of change of the rate of change. If you're really on a J curve and not a ramp into hell, the second derivative should become positive pretty quickly. ("Pretty quickly" is relative to the scope and impact of the change.) Even if things are still getting worse, you should see them getting worse more slowly. As long as the second derivative stays positive, you're on a good track.

Finally, and what I've often seen ignored, is the fact that the upward part of the J doesn't continue forever. At some point, you've maximized the gains you can see from that change. That's fine. Contrary to investor beliefs, things do need to level off at some point. The Satir Change Model, developed by family therapist Virginia Satir, is a good representation of a realistic J curve, complete with a new equilibrium state at the end.

This post's featured photo by Zyanya BMO on Unsplash.

The post The J curve, or: it gets worse before it gets better appeared first on Duck Alignment Academy.

19 Aug 2026 12:00pm GMT

Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.

I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).

I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.

There is No Drama Here

First off, let's get this out of the way: there is zero drama between Boxes and the GNOME project.

Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren't stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.

Why Boxes Shouldn't Be "Core" (and Why Versioning with the OS is Outdated)

The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.

Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.

Furthermore, virtualization isn't an essential utility that needs to be pre-installed on every single user's machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.

Flathub-First: Moving Fast and Ending Distribution Bottlenecks

As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.

By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.

Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.

Branding and Infrastructure Changes

To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping "GNOME" from the user-facing app branding. Going forward, it will simply be named "Boxes", and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won't break, and users won't need to reinstall anything.

What's Next?

This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.

To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.

If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.

For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won't include Boxes in the core set anymore. At this point, please don't package Boxes anymore.

19 Aug 2026 10:12am GMT

After years of technical research and foundational work, the Fedora Badges application service has been rebuilt from the ground up, and it is heading to production. Whether you have been collecting badges for years or you are brand new to the Fedora Project community, here is what is waiting for you there.

Completely modernized user interface

The archaic server rendered pages are now gone. The Fedora Badges application service now runs on a modern single page application. This provides you with a much faster and more responsive experience, while functioning across various screen sizes and devices types, all without full refreshes or front-end reloads.

Navigations have been revamped as well. But do not worry at all - if you have bookmarked any old service links, they should redirect you to the right place.

Colour schemes, Dark mode

You can now customize the look of the Fedora Badges application service choosing from eight colour schemes. Your choice flows through the various elements of the front-end - from navbar to borders, from charts to accents, etc. The dark mode and light mode switch respects your system preference and can also be toggled.

Your choices are persistent across visits residing in your session storage. As long as the same session is used, the colour schemes and dark mode settings stay.

Revitalized badges collectathon experience

Not only does the profile page show your precious badges, it also shows a radar chart that maps your collection across categories. This is a rudimentary method to gauge your progress and discover the areas you have not explored yet. Giving a means to diversify the activities, this encourages more people to join in.

The refreshed history page also adds a collection time-line chart showing yours (and your friends') contribution activities over months and years at a glance.

Compare (or compete) with your friends

The renewed difference page lets you compare your badges collection with those of your friends' possessions. See which badges you both share, which ones only you have, and most importantly, which ones they have earned that you have not yet. It's a fun way to discover new badges and unearth new ways to contribute.

You can also reach out to your fellow community members for potential mentoring opportunities, based on their contribution activities and collected badges.

Explore badges by rarities

Every active badge now has a rarity tier based on how many users currently hold it:

• Fedorable - Unobtanium stuff
• Legendary - Mythical prestige
• Epic - Serious bragging
• Rare - Principled hustle
• Uncommon - Striving future
• Common - Warm greeting

You can now browse active badges by their rarity tiers, making it easy to hunt down the ones that fewer people have earned. Not only does it allow you to find new pathways for contribution, you also get a sense of the impactful work and relevant tracks that are waiting for you in your community activities.

Involved semantic collective lookup

Departing from different searches for badges and users, the search bar now helps unified lookup across both badges and users. Start typing and results start appearing immediately after - with better lookup results. These will appear when the query is general enough to return more than eight results.

To save server resources, the asynchronous search request begins only when at least four characters are entered into the search bar for the query.

Leaderboards with time navigation

Departing from the restricted rankings page, it is now possible to request custom period filtering on the leaderboards page. Filters can be based on days, weeks, months, and years. One can see who has been earning most badges in those times, and generally look back at the community's evolving progress over a time period.

The rankings are deterministic and can be shared with others, using the sharing link that inherently applies the same filters. This creates a reproducible resource.

Clearer badge activity lifecycle

Badges can now be manually marked as legacy (retired, unobtainable) after they should no longer be awarded to the users. For instance, the badges for joining the Fedora Linux Release Party 42 should no longer be available to new users in 2026. Hence, they should not be accounted for while computing rarity tiers.

And nope - we are not taking awarded badges away from users who have already earned them. These retired badges are still going to be visible in the history.

Stronger foundational supports underneath

You see, the revamp was not just about the front-end. The data layer that powers the application service got a major overhaul as well. The Database Library project, which handles all database operations, saw 105 commits across 7 contributors during the same period, pushing from version 1.4.1 to 1.5.5.

Here's what changed under the hood, and why it matters to you:

• Faster queries - Redundant database lookups were eliminated, foreign key indexes were added, and pagination now happens at the database level instead of in the application code. Pages that list badges or users load significantly faster, especially as the count of badges or users grow.
• Effective lookup - The search you use from the navbar section is powered by new search methods added to the API. This covers both badges and users. This not only makes the search noticeably faster, but the actual process is also more efficient on a synchronous database accessing layer.
• Rarity calculation - The rarity tiers you see on badge pages are computed every day by an updated algorithm in the API code. Various edge cases are now handled too. The fall-back is set to the common tier on zero available users who own the said badges at that particular time.
• Legacy support - A schema level change was made to introduce a new
  legacy
  column to the
  badges
  table to distinguish active badges from the retired ones. Filtering is built into the API code so the front-end shows them on separate pages when requested by the users.
• Categories normalization - Badge tags are now stored in their own tables instead of as raw comma separated strings. This makes category browsing reliable.
• Cascading deletions - Removing a badge when done in exigent circumstances now properly cleans up its assertions in the database purging orphaned data.
• Removing invitations - Invitations are soft deleted and not hard removed. This preserves access history while preventing accidental assertions.
• Quality assurance - Nearly every new feature ships with its test cases. Python < 3.9 support was dropped in favor of Python > 3.13.

Overall smoother authentication events

Authentication has been reworked. The old session-based login has been replaced completely with a modern token-based flow using OpenID Connect. The application service now has its own dedicated authentication client so logging in through Fedora Accounts is more consistent across other things.

If you are visiting for the first time, like it has been for years, your user account is automatically created without requiring any further steps.

Your privacy really matters

Email addresses are no longer visible across various API responses. They are hashed before being sent as an asynchronous response, for use by Libravatar. Users have the choice to opt out of the Fedora Badges application service entirely. In that case they will stop receiving badge awards for their community tasks.

RSS feeds are now limited to recent entries for performance and efficiency, so you can still stay informed about the latest incoming activities on the app.

For badge creators, maintainers, and administrators

If you are a part of the team, the new interface gives you a full set of tools.

• Advanced database management front-end
• Creating and revoking awards from your users
• Creating and expiring invitations for the badges
• Creating and revoking authorizations from your users
• Creating and updating badges
• Creating and updating users

Access control is tiered - community members see the service experience, while authorized team members get the administrative controls they need.

Progress by the numbers

This revamp (codenamed स्वातंत्र्य or Svātantrya) represents a year of active work across the two repositories. These comprised 165 commits in Tahrir and 105 commits in Tahrir API. This occurred after many years of technical research and foundational work resulting in a leaner codebase with a net reduction of 13,320 lines of code.

Thank you to our amazing contributors

I mean it when I say, this revamp would have been dead in the water without the help of the following folks (in the alphabetical order):

• Akashdeep Dhar
• Aurelien Bompard
• Awwal Adetomiwa
• Chibuezem Marvinrose
• Daniel Mungai Chege
• Emma Kidney
• Gregory Sutcliffe
• John Iweh
• Joy Aruku
• Kevin Fenzi
• Michael Scherer
• Michal Konecny
• Olamide Peter Ojo
• Payal Sumbhe
• Shounak Dey
• Vanshikha Shri
• Yash Sheorey
• Xavier Lamien

And those, of course, from Flock 2026's workshop on the Fedora Badges Revamp Project.

• Ankur Sinha
• Cornelius Emase
• Emmanuel Seyman
• Guillermo Leiro
• Jakub Jelen
• Jona Azizaj
• Jonáš Hubený
• Justin Wheeler
• Mat Holmes
• Matthew Miller
• Misia Mary
• Shawn Dunn
• Vít Smolík
• Vittorio Cioe

This revamp project was in a development hell for quite some time. It was able to come out of it thanks to those listed above and countless others who have helped maintain the project for the past fourteen years or so. It is now time for me to pass this torch on to others who can help maintain this.

The project codebase currently lives on the Fedora Infrastructure's GitHub namespace. Please consider providing feedback and contributing changes to help maintain the projects. You can also hang out with us in the Fedora Badges chat room on Fedora Project's Matrix server to learn more.

Go on - give it a try!

The production deployment should be live by the time this article is publicly available. Head over to Fedora Badges to explore the refreshed experience. As it might be a little rough around the edges in the starting days, please bear with us while we hammer down the oddities with your useful reports.

Your input influences what comes next to the Fedora Badges application service. Please consider giving it a try right now and let us know what you think!

19 Aug 2026 8:00am GMT

Hoy me topé con un artículo bien fregón publicado por Sreenath en It's FOSS: Looking Beyond Tmux and Screen: 8 Terminal Multiplexers Worth Trying. De entrada, quiero darle todo el crédito a ese gran artículo y a su autor. La neta, te invito a que vayas y le eches un ojo a su trabajo original, porque plantea un panorama excelente sobre cómo ha evolucionado la gestión de terminales en el ecosistema FOSS.

Ahora bien, como usuario y apasionado de Fedora Linux, me di a la tarea de aterrizar esa lista completa al terreno de Fedora. Porque una cosa es que una herramienta exista en GitHub, y otra muy diferente es saber cómo se instala, si está en los repositorios oficiales, si vive en Copr o si requiere bibliotecas adicionales para correr al cien en tu máquina fedoriana.

Aquí te traigo la guía completa y probada empíricamente en Fedora de cada una de estas opciones, desde los veteranos de batalla hasta la nueva generación impulsada por Rust, Go, aceleración por GPU y agentes de Inteligencia Artificial.

# como root
dnf -y install tmux

# como root
dnf -y install screen

# como root
dnf -y install tmate

# Iniciar tmate y obtener credenciales de conexión
tmate

# como root
dnf -y install kitty abduco

# Crear una sesión persistente llamada "servidor"
abduco -c servidor bash

# como root
dnf -y copr enable sramanujam/zellij
dnf -y install zellij

# Instalación directa del binario oficial de Zellij
bash <(curl -L zellij.dev/launch)

# Iniciar Zellij
zellij

# como root
dnf -y copr enable wezfurlong/wezterm-nightly
dnf -y install wezterm

# como root (si faltan utilerías de compresión)
dnf -y install curl tar gzip

# Descargar e instalar TUIOS
curl -fsSL https://raw.githubusercontent.com/Gaurav-Gosain/tuios/main/install.sh | bash

# Iniciar TUIOS
tuios

# O ejecutarlo con un tema específico
tuios --theme dracula

# Descargar e instalar Boo mediante su script oficial
curl -fsSL https://raw.githubusercontent.com/coder/boo/main/install.sh | sh

# Crear una sesión en segundo plano
boo new mi-tarea

# Reengancharse a la sesión
boo attach mi-tarea

# como root: instalar dependencias de renderizado
dnf -y install libxcb libX11 libxkbcommon-x11 vulkan-loader libglvnd-egl

# Descargar y extraer Okena
curl -fsSL https://github.com/contember/okena/releases/download/v0.28.0/okena-linux-x64.tar.gz -o /tmp/okena.tar.gz
tar -xzf /tmp/okena.tar.gz -C /usr/local/bin
chmod 700 /usr/local/bin/okena

# Lanzar interfaz de Okena
okena

# Inspeccionar comandos del cliente CLI
okena --help

# como root: instalar dependencias de entorno gráfico
dnf -y install fuse-libs libadwaita gtk4 libX11 fontconfig

# Descargar el AppImage oficial
mkdir -p ~/.local/bin
curl -fsSL https://github.com/no1msd/seance/releases/download/v0.1.4/seance-0.1.4-x86_64.AppImage -o ~/.local/bin/seance
chmod 700 ~/.local/bin/seance

# Iniciar ventana principal de Séance
~/.local/bin/seance

# Controlar sesión desde CLI
~/.local/bin/seance ctl --help

18 Aug 2026 11:25pm GMT

18 Aug 2026 7:11pm GMT