Linux Weekly News

KDE contributor David Edmundson has published a blog post about improving KDE Plasma's login experience by replacing SDDM with a new Plasma Login Manager.

It's worth stressing nothing is official or set in stone yet, whilst it has come up in previous Plasma online meetings and in the 2023 Akademy. I'm posting this whilst starting a more official discussion on the plasma-devel mailing list.

Oliver Beard and I have made a new mutli-process greeter, that uses the same startup mechanism as the desktop session. It doesn't have all the features that we propose at the start of the blog, but an architecture where features and services can be slowly and safely added.

That discussion is here for those who would like to follow along. The prototype is currently in two repositories: plasma-login for the frontend work, and plasma-login-manager, which is a fork of SDDM.

In a keynote on the final day of SCALE 22x, Denver Gingerich said that he wanted to talk "a little bit about a router and also the big picture around that router". Gingerich is the director of compliance at the Software Freedom Conservancy (SFC), which is the organization behind the OpenWrt One router that LWN looked at back in November. The router is, of course, based on firmware from the OpenWrt project, which got its start because of GPL-enforcement activities and is a member project at the SFC.

As of this writing, 6,653 non-merge changesets have been pulled into the mainline kernel repository for the 6.15 release. This merge window is thus well underway. A number of significant changes have been merged so far; read on for our summary of the first half of the 6.15 merge window.

Security updates have been issued by Debian (mercurial and opensaml), Fedora (augeas, mingw-libxslt, and nodejs-nodemon), Mageia (chromium-browser-stable), Red Hat (grafana, kernel, kernel-rt, opentelemetry-collector, and podman), SUSE (apache-commons-vfs2, python3, and python36), and Ubuntu (ghostscript, linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-gkeop, linux-ibm, linux-intel-iotg, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-azure, linux-gcp, linux-hwe-6.11, linux-oracle, linux-realtime, linux, linux-aws, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle, linux-oracle-6.8, linux-aws-5.15, linux-kvm, linux-azure, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oem-6.11, linux-oem-6.8, linux-realtime, smarty, and snakeyaml).

Ubuntu 23.10 and 24.04 LTS introduced a feature using AppArmor to restrict access to user namespaces. Qualys has reported three ways to bypass AppArmor's restrictions and enable local users to gain full administrative capabilities within a user namespace. Ubuntu has followed up with a post that explains the namespace-restriction feature in detail, and says these bypasses do not constitute security vulnerabilities.

While a superficial observation of the application of user namespaces may indicate privileged (root level) access, this is a fictitious state that is operating as expected, with access control still mapped to the real (root namespace) user's permissions. As such, these bypasses do not enable more access than what the default Linux kernel unprivileged user namespace feature allows in most Linux distributions. They do, however, demonstrate limitations that we are looking to address in order to strengthen existing protections against as-of-yet-unknown Linux kernel vulnerabilities.

LWN covered Ubuntu 24.04 LTS last May.

One recurring criticism of Rust has been that the language has no official specification. This is a barrier to adoption in some safety-conscious organizations, as well as to writing alternate language implementations. Now, the Rust project has announced that it will be adopting the Ferrocene Language Specification (FLS) developed by Ferrous Systems and maintaining it as part of the core project. While this may not satisfy die-hard standardization-process enthusiasts, it's a step toward removing another barrier to using Rust in safety-critical systems.

It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.

Arthur Cohen has posted a massive series of patches in four parts (part 1, part 2, part 3, part 4) upstreaming all of the recent work on the GCC Rust front end. These changes include the Polonius borrow checker, the foreign-function interface, inline assembly support, if-let statement handling, multiple built-in derive macros, for loops, and more.

The 2024 Linux Storage, Filesystem, Memory-Management, and BPF Summit included a tense session on the use of Rust code in the kernel's filesystem layer. The Rust topic returned in 2025 in a session run by Andreas Hindborg, with a scope that also covered the storage and memory-management layers. A lot of progress has been made, and the discussion was less adversarial this year, but there are still process issues that need to be worked out.

Security updates have been issued by Arch Linux (exim), Debian (exim4, ghostscript, and libcap2), Red Hat (container-tools:rhel8), SUSE (apache-commons-vfs2, argocd-cli, azure-cli-core, buildah, chromedriver, docker-stable, ed25519-java, kernel, kubernetes1.29-apiserver, kubernetes1.30-apiserver, kubernetes1.32-apiserver, libmbedcrypto7, microcode_ctl, php7, podman, proftpd, tomcat10, and webkit2gtk3), and Ubuntu (containerd, exim4, mariadb, opensaml, and org-mode).

Akamai has sent out a press release saying that it is now hosting the kernel.org repositories.

The Linux kernel is massive — approximately 28 million lines of code. Since 2005, more than 13,500 developers from more than 1,300 different companies have contributed to the Linux kernel. Additionally, there are many kernel versions, and developers update the code constantly, distributing that code to developers who are working on various distributions of Linux. Akamai now delivers the infrastructure that these developers and their users rely on, at no cost, supporting the Git environments developers use to access kernel sources quickly, regardless of where they're based.

Inside this week's LWN.net Weekly Edition:

• Front: Open source in government; OSI election; Memory-management medley; Address-space isolation; CMA; 6.14 Development stats; State of the page.
• Briefs: Asahi Linux progress; Reproducible Debian; rpi-image-gen; Neovim 0.11; OpenH264; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

Version 0.11 of the Neovim text editor has been released. Notable changes in this release include simpler Language Server Protocol (LSP) client setup, improved tree-sitter performance, better emoji support, and enhancements for Neovim's embedded terminal emulator. See the release notes for a full list of changes.

In a short note to the Reproducible Builds mailing list, Debian developer Roland Clobus announced that live images for Debian 12.10 ("bookworm") are now 100% reproducible. See the reproducible live images and Debian Live todo pages on the Debian wiki for more information on the images.

The folio transition is one of the most fundamental kernel changes ever made; it can be thought of as being similar to replacing the foundation of a building while it remains open for business. So it is not surprising that, for some years, the annual Linux Storage, Filesystem, Memory-Management, and BPF Summit has included a session on the state of this transition. The 2025 Summit was no exception, with Matthew Wilcox updating the group on what has been accomplished, what remains to be done, and where some of the significant problems are.

Security updates have been issued by Debian (nginx and ruby-rack), Fedora (expat and libxslt), Mageia (bluez, dcmtk, ffmpeg, and radare2), Red Hat (container-tools:rhel8, gvisor-tap-vsock, kernel, kernel-rt, libreoffice, and podman), SUSE (buildah, forgejo, gitleaks, google-guest-agent, google-osconfig-agent, govulncheck-vulndb, grafana, helm, libxslt, php8, python-gunicorn, and python-Jinja2), and Ubuntu (freerdp2 and varnish).

Boudhayan Bhattcharya has posted a lengthy article about the announcement that the Freedesktop project is dropping OpenH264 from the Freedesktop SDK for Flatpak applications and runtimes.

Some Flatpak applications that depend on the Freedesktop runtime version 23.08 will lose H.264 playback support starting with the release scheduled for April, unless application developers replace it with the ffmpeg-full extension. The 24.08 runtime is unaffected, and future releases will include a new codecs-extra extension to replace OpenH264 that includes FFmpeg with support for a number of patented codecs.

Considering all things, I think and hope we made the correct decision and hopefully the new org.freedesktop.Platform.codecs-extra works out. libx264, libx265 and others are built from source and there are no binaries or extra-data involved. So we should theoretically be able to patch and fix any issues that come up in the future.

Apart from all this, I'm slightly worried at the prospects of legal issues cropping up with this setup and also that the new extension contains "too much", but we will have to see where things flow.

By the time that Linus Torvalds released the 6.14 kernel, 11,003 non-merge changesets had been pulled into the mainline, making this one of the smallest releases we have seen in some time. Indeed, one must go back to the 4.0 release, which happened almost exactly ten years ago, to find a release with fewer changesets than 6.14. Even so, "small" is relative, and 6.14 contains a lot of significant changes.

Security updates have been issued by Debian (ruby-rack), Fedora (chromium, golang-github-openprinting-ipp-usb, OpenIPMI, and python-jinja2), Mageia (kernel, kernel-linus, and wpa_supplicant, hostapd), Red Hat (fence-agents, kernel, kernel-rt, libxml2, libxslt, and pcs), SUSE (cadvisor, docker, freetype2, nodejs-electron, php8, rsync, u-boot, warewulf4, webkit2gtk3, and zvbi), and Ubuntu (elfutils, python3.5, python3.8, ruby-rack, smartdns, and zvbi).

Linus has released the 6.14 kernel, a bit later than expected:

So it's early Monday morning (well - early for me, I'm not really a morning person), and I'd love to have some good excuse for why I didn't do the 6.14 release yesterday on my regular Sunday afternoon release schedule.

I'd like to say that some important last-minute thing came up and delayed things.

But no. It's just pure incompetence.

See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.14 page for details on what's new in this release.

The adoption of open-source software in governments has had its ups and downs. While open source seems like a "no-brainer", it turns out that governments can be surprisingly resistant to using FOSS for a variety of reasons. Federico González Waite spoke in the Open Government track at SCALE 22x in Pasadena, California to recount his experiences working with and for the Mexican government. He led multiple projects to switch away from proprietary, often predatory, software companies with some success—and failure.