Brief items

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.

Comments (none posted)

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 cp314 wheels 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.

Comments (13 posted)

"Half a Second" — a book on the XZ backdoor

Adrian Mastronardi has released a book called Half a Second; it is a detailed look into the XZ backdoor attempt of 2024. The book is freely available under a (non-free) noncommercial, no-derivatives CC license.

Half a Second tells that story as one continuous narrative: the burned-out volunteer who maintained the code alone and was patiently, expertly manipulated into giving it up; the engineer whose half-second of curiosity caught the attack through a chain of luck and hard-won instinct; and the operator who built it, who has never been identified and, this book argues, may never be.

Comments (18 posted)

Security quotes of the week

You don't see people from the frontier models brag about how many vulnerabilities they FIXED, only how many they FOUND.

— Daniel Stenberg

When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure. This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.

This experience points to a gap worth planning for. We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment. This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned.

— A Hugging Face press release after being attacked by an OpenAI model

HuggingFace seem to have vibed their own software all the way down. They feed this heap of vibes some arbitrary input from the hostile Internet. A chatbot then sends what it makes of this to a service account that could run any Kubernetes command with full control.

When this all goes wrong, they "analyse" it with more AI. Then they patch it with more AI.

— David Gerard

Comments (none posted)

Kernel release status

The current development kernel is 7.2-rc4, released on July 19. Linus said: "This whole week I had the feeling that people were starting to go on summer vacation, but running the numbers shows that I must have been wrong - it all looks pretty normal."

This release has seen 14,716 non-merge changesets from 2,343 developers, 481 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.2-rc1	2026-06-28	14395	14395
v7.2-rc2	2026-07-05	433	433
v7.2-rc3	2026-07-12	475	475
v7.2-rc4	2026-07-19	557	557

See the LWN KSDB v7.2 page for a lot more details.

Stable updates: the large 7.1.4, 6.18.39, and 6.12.96 updates were released on July 18.

The truly massive 7.1.5 (2,077 commits), 6.18.40 (1,611), 6.12.97 (1,276), 6.6.145 (1,266), 6.1.178 (1,067), 5.15.212 (843), and 5.10.261 (699) are in the review process; they are due on July 23.

Comments (none posted)

Quotes of the week

Well. We've always taken the point of view that /proc/vmstat is a developer dumping ground so things can be added, removed and altered. Failing to Document/ the file is our cryptic way of telling users this ;)

— Andrew Morton

Meta-comment about the 400+ CVEs on Sunday. I finally carved some time out of my weekend to catch up on the pending review queue that I was _way_ behind in, and got closer to finishing it up. All of the kernel CVEs are reviewed in public, in our git repo, for everyone to watch and comment on. These were all pending for weeks, they shouldn't have come as a suprise to anyone, except for the only issue being that it has taken us this long to get them out (which was due to a perfect storm of 6 week straight of conferences and vacations).

— Greg Kroah-Hartman

Comments (none posted)

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 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.

Comments (6 posted)

Distributions quote of the week

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it's released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn't as critical.

Don't want to be a rolling release? That's fine. Then you need to work closely with your upstreams.

— Nate Graham

Comments (18 posted)

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.

Comments (25 posted)

Development quotes of the week

Maintainer burnout is already a thing, and maintainer death will increase in frequency since FOSS looks more and more like it was a generational thing, like bell-bottom jeans and flower power.

Attempting to lure in apprentice maintainers to replace my generation of do-gooders is already a losing proposition, and it is not going to happen at all if the role of maintainer is pro bono, while the paint-on-the-sign-is-still-wet "FOSS stewards" and "FOSS manufacturers" rake in the dough from that very same software.

The era of "Benevolent Dictator for Life" FOSS maintainers like myself is coming to an end. In the future, all consequential FOSS projects will be maintained by committees appointed by a FOSS steward or by a FOSS company.

— Poul-Henning Kamp

There is no Commons. You're just DoS-ing someone else's infrastructure.

— Stefano Zacchiroli

Comments (none posted)