Greg Kroah-Hartman has announced the release of the 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212, and 5.10.261 stable Linux kernels.
This batch of kernels includes a hefty set of updates, possibly the largest ever. 7.1.5-rc1, for example, included more than 2,000 patches, 6.18.40-rc1 included 1,611 patches, and so forth. Users are advised to upgrade.
Fedora contributor Simon de Vlieger has published a blog post with a walkthrough of how the project turns source code and packages into the final release that users install on their systems.
It follows the a package from a packager's git push to a composed release: ISOs, cloud images, container images, and OSTree deployments.
The walkthrough describes how the Fedora 'sausage' is created as of Fedora 45, things change all the time; I hope to have time to update this document every cycle or every few cycles of Fedora releases so there's both history and people can find up to date information.
The Open Home Foundation, which governs the Home Assistant home-automation project, has announced the "public preview" of its Device Database:
Providing a public, open way to browse the anonymous, aggregated device data we collect was always part of the plan, and this preview is our first step toward it.
You can already use it to search and filter devices to see aggregated community insights, starting with a deliberately focused set of specifics, such as whether a device requires an internet connection, and which protocols and integrations it works with. We've kept that initial scope narrow on purpose, giving us a solid foundation we can build on together with you, our community, as the database grows.
LWN looked at Home Assistant in May 2025.
One of the features that users often miss when moving from X11 to Wayland is the ability to save and restore the position of windows between sessions. At GUADEC 2026, held in A Coruña, Spain, Adrian Vovk provided an overview of work that has gone into providing a platform-wide save and restore framework for GNOME. After two failed attempts at landing an API, he believes that the third try will be the one to succeed—though not in time for the upcoming GNOME 51 release due in October.
Python Software Foundation security developer-in-residence Seth Larson has announced that the Python Package Index (PyPI) will now reject new files that are uploaded to releases older than 14 days. The restriction is to prevent the poisoning of old releases if publishing tokens or workflows of PyPI projects are compromised.
The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action.
Originally the discussion stalled due to some projects depending on this behavior to add support for new Python versions to already-published releases. To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases (bucketed by number of days since the release). Later, specifically
cp314wheels were queried for the top 15,000 packages, revealing that only 56 projects of 15,000 had published a 3.14-compatible wheel more than 14 days after a release was available.
LWN covered the LiteLLM compromise in March.
Version 153.0 of the Firefox web browser has been released. Notable changes in this release include a change to the default local-file-access permissions for extensions, enabling LAN restrictions by default for all users, a visual indicator when a web site has access to the user's location, the ability to merge PDFs and add images as pages within PDFs, as well as experimental support for the JPEG XL image format.
See the release notes for developers for all changes that affect web developers, and security advisories for vulnerabilities fixed in this release.
The Fedora Project is known for, among other things, having a well-defined set of processes for just about everything. It has extensive packaging guidelines that deal with the complexities of creating RPMs to install software, as well as processes for managing the legal questions that arise around shipping software. Fedora also has a well-defined change process for dealing with self-contained technical changes as well as major changes to the distribution, and other issues as they arise. At the moment, though, the project seems to be experiencing a sort of midlife crisis as it re-examines several of its change processes at once to determine if they are still effective.
Michael Catanzaro, who has been managing GNOME security issue tracking since
November 2020, has written a blog post that details some changes in how he will
be managing GNOME vulnerability reports from now on due to an increase in
AI-generated security reports. He will be switching from a 90-day deadline for
disclosures to 30 days for issues reported on August 1, or later. "The
shorter deadline would probably work better for GNOME even if not for the
increase in AI-generated issue reports.
"
He also has indicated that he will be stepping away from the task of managing security issue tracking entirely by December 1, 2026, which means that there will be a gap to fill:
Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)
This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It's easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.
Collabora has published a blog post about its work with Valve on Holo Core, which is a port of Arch Linux to aarch64 to be used as the the operating system on Valve's 64-bit Arm Steam Frame gaming system. Collabora has released the sources, binary packages, and a container image for aarch64 devices. The post describes some of the challenges in porting Arch Linux to a new architecture, and what remains to be done:
Whilst the infrastructure developed to this point is capable of building from first principles up until a point-in-time snapshot, the next step is to build this into a system which can track Arch Linux as it is developed. This work will serve as the basis of a continuously-operating CI system capable of shadowing Arch Linux itself. We will work with the upstream Arch Linux project to help Arch with their efforts to port the distribution to aarch64 architecture and work towards automated repeatable builds.
The post also includes instructions on how to create and test an aarch64 build container on an x86_64 host, for users who would like to follow along at home but lack a 64-bit Arm device.
The SUSE Security Team Blog has a post with an analysis of seunshare, which is used by SELinux to confine untrusted programs. During a review of version 3.10 of the program, the team identified two local Denial-of-Service (DoS) vectors.
Since seunshare is supposed to run on SELinux-enabled systems, it is important to understand what kind of privilege escalation can be achieved when vulnerabilities are exploited in a setuid-root binary like this. Many SELinux-enabled systems, such as Fedora and openSUSE, ship with the "targeted" SELinux policy by default. This policy is focused on confining well-known system services, but assigns an unconfined SELinux context to interactive users by default to achieve a balance between security and usability.
There is currently no domain transition from the unconfined domain to the more restricted seunshare_t defined in the SELinux policy for seunshare. This means the execution of seunshare continues in the unconfined domain. Thus in the context of attacks carried out by interactive users, the impact of the vulnerabilities below will be a root-like privilege escalation despite the system running in SELinux enforced mode.
See the post for the full write-up of the team's discoveries and timeline. The vulnerabilities have been fixed in version 3.11.
Connexion