Vue lecture
[$] LWN.net Weekly Edition for July 23, 2026
- Front: LLMs in the kernel; GNOME save and restore; Fedora changes; BPF and tracepoints; BPF and LSMs; famfs; sched_ext.
- Briefs: GNOME security; PyPI policy; Arch on aarch64; Firefox 153; Quotes; ...
- Announcements: Newsletters, conferences, security updates, patches, and more.
[$] Save and restore may be coming to GNOME
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.
PyPI now rejects new files after 14 days
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.
Security updates for Wednesday
Firefox 153 released
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.
Security updates for Tuesday
[$] Fedora grapples with change
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.
Catanzaro: Some changes to GNOME security tracking
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.
Security updates for Monday
Building an Arch Linux aarch64 port for Holo Core (Collabora blog)
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.
Security updates for Friday
Security updates for Thursday
Local DoS attack vectors in seunshare 3.10 (SUSE Security Team Blog)
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.
Security updates for Wednesday
[$] LWN.net Weekly Edition for July 9, 2026
- Front: Cryptography API; Iomap explanation; Negative dentries; Faster RCUs and lockless allocation for BPF; LLMs in memory-management code
- Briefs: Guix vulnerabilities; OpenSSH 10.4; trusted publishing; kernel archive; CalyxOS; Quotes; ...
- Announcements: Newsletters, conferences, security updates, patches, and more.
[$] Progress in modernizing kernel cryptography
At the 2026 Linux Security Summit North America, Eric Biggers spoke about some of the problems with the kernel's cryptography framework, as well as the recent progress in adding library APIs to allow developers to use cryptographic functions without using the traditional crypto API. He walked through a couple of examples to demonstrate the frailty of the original API and showed how the new library API made life easier for developers and kernel maintainers.
Woodruff: You shouldn't trust trusted publishing
William Woodruff, better known online as "yossarian", has published a blog post to make the case that users should not place their trust in trusted publishing:
Trusted Publishing is a mechanism for establishing trust between an external machine identity (like a CI/CD workflow) and one or more projects on a package index/registry. The "trust" in "Trusted Publishing" refers to that trust relationship, and not to anything else.
It is not, and cannot be, a signal for package trust or quality. You cannot use it to determine whether a package is safe or "good," and PyPI consciously stymies attempts to misuse it for that purpose by not rendering it as a "green checkmark" or anything else of the sort.
Or as another framing: Trusted Publishing is just a form of authentication. It doesn't tell you anything other than that an upload was authenticated, which all uploads to PyPI are.
LWN covered trusted publishing in June.
Security updates for Tuesday
OpenSSH 10.4 released
OpenSSH 10.4 has been released. In addition to a number of security and bug fixes, there are a few notable changes; this release adds experimental support for a composite post-quantum signature scheme combining ML-DSA 44 and Ed25519 as described in this IETF draft. With 10.4, if OpenSSH is compiled with sandbox support it will fail on Linux systems that have not enabled SECCOMP or NO_NEW_PRIVS; prior to this release, sshd would log an error but continue operation. See the release notes for a full list of changes.