Brief items
Security
A vulnerability in the Guix build system
The Guix project has disclosed a security vulnerability in the build daemon that the distribution uses to build and install software locally. The vulnerability allows an existing unprivileged user to get access to a setuid binary, and from there potentially interfere with any other software built or installed on the computer. The project recommends upgrading the guix daemon now, to avoid the issue.
This exploit requires the ability to start a derivation build and the ability to run arbitrary code with access to the store in the root PID namespace on the machine the build occurs on. As such, this represents an increased risk primarily to multi-user systems and systems using dedicated privilege-separation users for various daemons: without special sandboxing measures, any process of theirs can take advantage of this vulnerability.
Security quote of the week
I commented on Lobsters that /tmp is usually a bad idea, which caused some surprise. I suppose /tmp security bugs were common in the 1990s when I was learning Unix, but they are pretty rare now so I can see why less grizzled hackers might not be familiar with the problems.
I guess that's some kind of success, but sadly the fixes have left behind a lot of scar tissue because they didn't address the underlying problem: /tmp should not exist.
It's a bad idea because it's shared global mutable state that crosses security boundaries. There's a ton of complexity at all levels of unix (filesystems, kernel APIs, libc, shell, admin scripts) that only exists as a workaround for the dangers caused by making /tmp shared.
Kernel development
Kernel release status
The current development kernel is 6.12-rc4, released on October 20. Linus commented: "I'm not happy with how big this is - it's probably far from the biggest rc4 ever, but it _is_ the biggest rc4 we've had in the 6.x series at least in number of commits."
Stable updates: 6.11.4, 6.6.57, 6.1.113, 5.15.168, and 5.10.227 were released on October 17, followed by 6.11.5, 6.6.58, 6.1.114, 5.15.169, and 5.10.228 on October 22.
A new kernel testing tree
Sasha Levin has announced a new tree that is intended to perform continuous-integration tests of pull requests aimed at the mainline. The plan is for this tree to hold more finished work than sometimes ends up in linux-next; in a name that seems destined to create typographical confusion, it is called "linus-next".
The linus-next tree aims to provide a more stable and testable integration point compared to linux-next, addressing the runtime issues that make testing linux-next challenging and focusing on code that's about to be pulled by Linus.
Several Russian developers lose kernel maintainership status
Perhaps one of the more surprising changes in the 6.12-rc4 development kernel was the removal of several entries from the kernel's MAINTAINERS file. The patch performing the removal was sent (by Greg Kroah-Hartman) only to the patches@lists.linux.dev mailing list; the change was included in a char-misc drivers pull request with no particular mention.
The explanation for the removal is simply "various compliance
requirements
". Given that the developers involved all appear to be of
Russian origin, it is not too hard to imagine what sort of compliance is
involved here. There has, however, been no public posting of the policy
that required the removal of these entries.
Update: Linus Torvalds has since publicly supported this action and said that it will not be reverted.
Update 2: James Bottomley has clarified the requirements:
If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.
Quote of the week
Since reiserfs deprecation period is ending, it is time to prepare a patch to remove it from the kernel. I guess there's no point in spamming this list with huge removal patch but it's now sitting in my tree if anybody wants to have a look. Unless I hear some well founded complaints I'll send it to Linus during the next merge window in mid-November.— Jan Kara
Distributions
Introducing AlmaLinux OS Kitten (AlmaLinux Blog)
The AlmaLinux project has introduced a new edition called "Kitten",
which will serve as "the direct upstream for AlmaLinux OS and is
the primary point for the AlmaLinux community to engage and influence
the future of AlmaLinux OS
". Not intended for production use, the
first release is based on CentOS Stream 10 source, which
will eventually be the basis for Red Hat Enterprise Linux (RHEL)
10:
Because we anticipated many changes in 10, we wanted to get a head start on building AlmaLinux OS 10. Earlier this year we started setting up infrastructure and the build pipeline for AlmaLinux OS 10, and started testing using CentOS Stream 10's code. Based on this preparation work, we are excited to share that we have successfully built a preview of AlmaLinux OS 10 that we are calling AlmaLinux OS Kitten 10.
The first Kitten release previews a number of ways that AlmaLinux will diverge from RHEL 10, including re-enabling frame pointers, including Simple Protocol for Independent Computing Environments (SPICE), and adding packages for Firefox and Thunderbird, which have been dropped from CentOS Stream 10 in favor of Flatpak versions. New installation images for Kitten will be built quarterly. See the release notes for download links, installation instructions, and more information.
Kadlčík: Copr Modularity, the End of an Era
Jakub Kadlčík announced on his blog that Fedora's Copr build system will be dropping support for building modules (groups of RPM packages that are built, installed, and shipped together) soon:
The Fedora Modularity project never really took off, and building modules in Copr even less so. We've had only 14 builds in the last two years. It's not feasible to maintain the code for so few users. Modularity has also been retired since Fedora 39 and will die with RHEL 9.
Modularity features in Copr are now deprecated, and it will not be possible to submit new module builds after April 2025. LWN covered some of the problems with Fedora's modularity initiative in 2019.
Distributions quote of the week
I remember the absolute insanity when ACPI was new and we basically assumed any pre-2000 BIOS would have bad tables, and if you wanted ACPI, you needed to bring your own tables.
I do not wish to repeat this experience, and my feeling is that the way the boot specifications are written for riscv, with every side pushing responsibility away from themselves, we are going exactly that way. [...]
I wonder if it would make sense for Debian to throw a bit of weight around and communicate to vendors that they can not expect us to ship and update [device tree blobs] for their devices in a stable release, and if they want trixie to be bootable without any vendor specific tricks, they ought to provide a device tree containing mainboard resources from their first-stage bootloader so it is already accessible to OpenSBI, and whatever bootloader is called from that will only amend it with runtime information like commandline parameters and address assignments of PCIe devices, not replace it as a whole -- because that is a complete maintenance and usability nightmare.
Development
Bootc 1.1.0 released
Version 1.1.0 of the bootc utility for
performing transactional, in-place operating system updates using Open Container Initative (OCI)
images, has been released. This release "officially stabilizes all
APIs
" for bootc and includes a number of bug fixes. LWN covered bootc in June.
OpenSSL 3.4.0 released
Version 3.4.0 of the OpenSSL SSL/TLS library has been released. It adds a number of new encryption algorithms, support for "directly fetched composite signature algorithms such as RSA-SHA2-256", and more. See the release notes for details.
Rust 1.82.0 released
Version 1.82.0 of the Rust language has been released. There are a lot of new features this time, including a cargo info command, tier-1 support for 64-bit Apple Arm systems, a new native syntax (&raw) to create raw pointers, changes to unsafe extern, unsafe attributes, standardized rules around the handling of floating-point not-a-number values, and more.Tor Browser 14.0 released
Version 14.0 of the privacy-focused Tor browser has been released.
This is our first stable release based on Firefox ESR 128, incorporating a year's worth of changes shipped upstream in Firefox. As part of this process we've also completed our annual ESR transition audit, where we reviewed and addressed over 200 Bugzilla issues for changes in Firefox that may negatively affect the privacy and security of Tor Browser users. Our final reports from this audit are now available in the tor-browser-spec repository on our Gitlab instance.
Page editor: Daroc Alden
Next page:
Announcements>>