Linux Weekly News
[$] Compiling Rust to readable C with Eurydice
A few years ago, the only way to compile Rust code was using the rustc compiler with LLVM as a backend. Since then, several projects, including Mutabah's Rust Compiler (mrustc), GCC's Rust support (gccrs), rust_codegen_gcc, and Cranelift have made enormous progress on diversifying Rust's compiler implementations. The most recent such project, Eurydice, has a more ambitious goal: converting Rust code to clean C code. This is especially useful in high-assurance software, where existing verification and compliance tools expect C. Until such tools can be updated to work with Rust, Eurydice could provide a smoother transition for these projects, as well as a stepping-stone for environments that have a C compiler but no working Rust compiler. Eurydice has been used to compile some post-quantum-cryptography routines from Rust to C, for example.
The Award for Excellence in Open Source goes to Greg Kroah-Hartman
It's impossible to overstate the importance of the work Greg has done on Linux. In software, innovation grabs headlines, but stability saves lives and livelihoods. Every Android phone, every web server, every critical system running Linux depends on Greg's meticulous work. He ensures that when hospitals, banks, governments, and individuals rely on Linux, it doesn't fail them. His work represents the highest form of service: unglamorous, relentless, and essential.
Security updates for Friday
A proposed governance structure for openSUSE
It's meant to be a way to move from governance by volume or persistence toward governance by legitimacy, transparency, and process - so that disagreements can be resolved fairly and the project can keep moving forward. Introducing structure and predictability means it easier for newcomers to the project to participate without needing to understand decades of accumulated history. It potentially could provide a clearer roadmap for developers to find a place to contribute.
The stated purpose is to start a discussion; this is openSUSE, so he is likely to succeed.
[$] Sub-schedulers for sched_ext
Security updates for Thursday
[$] LWN.net Weekly Edition for January 29, 2026
- Front: PostmarketOS; LKRG 1.0; Fedora elections; EROFS, NTFS, and XFS; Fedora and GPG 2.5; BPF kfuncs.
- Briefs: curl bounties; GPG security; Guix 1.5.0; ReactOS turns 30; glibc 2.43; Rust 1.93; Xfwl4; Quotes; ...
- Announcements: Newsletters, conferences, security updates, patches, and more.
Mourning Didier Spaier
We have received the sad news that Didier Spaier, maintainer of the blind-friendly Slackware-based Slint distribution, has recently passed away. Philippe Delavalade, who posted the announcement to the Slint mailing list, said:
Early 2015, I asked on the slackware list if brltty could be added in the installer; Didier answered promptly that he could do it on slint. Afterwards, he worked hard so that slint became as accessible as possible for visually impaired people.
You all know that all these years, he tried and succeeded to answer as quickly as possible to our issues and questions.
He will be irreplaceable.
OSI pauses 2026 board election cycle
The Open Source Initiative (OSI) has announced that it will not be holding the 2026 spring board election. Instead, it will be creating a working group to "review and improve OSI's board member selection process" and provide recommendations by September 2026:
The public election process was designed to gather community priorities and improve board member selection, while final appointments remained with the board.
Over time, that nuance has become a source of understandable confusion for community members. Many reasonably expected elections to function as elections normally do, and in fact, the board has generally adopted the electorate's recommendations. When a process feels unclear, trust suffers. When trust suffers, engagement becomes harder. This is especially problematic for an organization whose mission depends on legitimacy and credibility. [...]
OSI tried its experiment for the right reasons, but a variety of factors resulted in "elections" that are performatively democratic while being gameable and representative of only a small group, and we've learned from the results. Now we are making space to align our director selection process with our bylaws, to rebuild trust, and to develop better, more durable and truly representative participation in which the global stakeholder community can be heard.
LWN covered the previous OSI election in March 2025.
[$] Open source for phones: postmarketOS
PC Gamer on the scx_horoscope scheduler
The scheduler is full of bizarre features, like its ability to perform real planetary calculations based on accurate geocentric planetary positions, lunar phase scheduling (the full moon gives a 1.4x boost to tasking, apparently) and "zodiac-based task classification".
That latter feature is easily one of my favourite bits. Specific planetary bodies "rule" over specific system tasks, so the Sun is in charge of critical system processes, the Moon (tied to emotions, of course) rules over interactive tasks, and Jupiter is assigned to memory-heavy applications, among others.
[$] Who should vote in Fedora elections?
Creating fair governance models for open-source projects is not easy; defining criteria for participants to receive membership and voting rights is a particularly thorny problem for projects that have elections for representative bodies. The Fedora Council, the project's top-level governance body, is wrestling with that conundrum now. This was triggered by a Fedora special-interest group (SIG) granting temporary membership to at least one person for the sole purpose of allowing them to vote in the most recent Fedora Engineering Steering Council (FESCo) election. That opened a large can of worms about what it means to be a contributor and how contributors can be identified for voting purposes.
Security updates for Wednesday
A critical GnuPG security update
A crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack buffer overflow in gpg-agent during the PKDECRYPT--kem=CMS handling. This can easily be used for a DoS but, worse, the memory corruption can very likley also be used to mount a remote code execution attack. The bug was introduced while changing an internal API to the FIPS required KEM API.
Only versions 2.5.13 through 2.5.16 are affected.
The GNU C Library is moving from Sourceware
While it was clear to the GNU Toolchain leadership that requirements were coming to improve the toolchain cyber-security posture, these requirements were not clear to all project developers. As part of receiving this feedback we have worked to document and define a secure development policy for glibc and at a higher level the GNU Toolchain. While Sourceware has started making some critical technical changes, the GNU Toolchain still faces serious, systemic concerns about securing a global, highly available service and building a sustainable, diverse sponsorship model.
This has been a long-running discussion; see this 2022 article for some background.
[$] Implicit arguments for BPF kfuncs
Xfwl4: the roadmap for a Xfce Wayland compositor
The Xfce team has announced that it will be providing funding to Brian Tarricone to work on xfwl4, a Wayland compositor for Xfce:
Xfwl4 will not be based on the existing xfwm4 code. Instead, it will be written from scratch in rust, using smithay building blocks.
The first attempt at creating an Xfce Wayland compositor involved modifying the existing xfwm4 code to support both X11 and Wayland in parallel. However, this approach turned out to be the wrong path forward for several reasons:
- Xfwm4 is architected in a way that makes it very difficult to put the window management behavior behind generic interfaces that don't include X11 specifics.
- Refactoring Xfwm4 is risky, since it might introduce new bugs to X11. Having two parallel code bases will allow for rapid development and experimentation with the Wayland compositor, with zero risk to break xfwm4.
- Some X11 window management concepts just aren't available or supported by Wayland protocols at this time, and dealing with those differences can be difficult in an X11-first code base.
- Using the existing codebase would require us to use C and wlroots, even if a better alternative is available.
Work has already commenced on the project, and the project hopes to share a development release in mid-2026.
Security updates for Tuesday
[$] Fedora and GPG 2.5
The GNU Privacy Guard (GPG) project decided to break from the OpenPGP standard for email encryption in 2023, and instead adopted its own homegrown LibrePGP specification. The GPG 2.4 branch, the last one to adhere to OpenPGP, will be reaching the end of life in mid-2026. The Fedora project is currently having a discussion about how that affects the distribution, its users, and what to offer once 2.4 is no longer receiving updates.