Brief items
Security
IBM's "Project Lightwell"
IBM has sent out a press release touting a claimed $5 billion investment into an operation called Project Lightwell:
Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.
Toward the bottom, it does also mention sharing vulnerability information with upstream projects.
Nesbitt: Protestware for coding agents
Andrew Nesbitt has written a blog post detailing a recent incident with the jqwik library for property-based testing in Java. On May 25, the 1.10.0 release of jqwik included a change that attempts to instruct coding agents to disregard previous instructions and delete jqwik tests and code.
I think this is a new class of supply-chain input worth keeping an eye on, mostly because of how little of the existing tooling has any opinion about it. A System.out.print of sixty-eight bytes of plain ASCII isn't the kind of thing scanners are looking for, since those watch for install hooks, network calls, filesystem writes, obfuscated strings and the like. The jar makes the same syscalls it made in 1.9, and because the change was committed and released by the legitimate maintainer through the normal build, it's clean from a SLSA point of view too: the provenance is what it should be. Anyone who reads the diff can see what it does, but a patch bump of a test-scoped dependency is not where most projects spend their review time.
Multiple redhat-cloud-services npm packages compromised (StepSecurity Blog)
StepSecurity is reporting that a number of npm packages in the @redhat-cloud-services scope include malware that runs automatically on every npm install:
The payload is a multi-stage credential harvester that sweeps GitHub Actions secrets along with AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm, and CircleCI tokens, and it is purpose-built to evade detection, including an explicit attempt to bypass StepSecurity Harden-Runner.
StepSecurity analyzed @redhat-cloud-services/host-inventory-client@5.0.3 in full. Its index.js, executed at install time, is 4.2 MB, a file that should weigh a few kilobytes, with the real payload buried under three separate layers of obfuscation. The malware is also a self-propagating worm: using stolen npm tokens and npm's bypass_2fa parameter, it republishes backdoored versions of other packages on its own, even against accounts protected by two-factor authentication, so every infected machine can seed the next wave with no attacker involvement. All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised. Analysis of the remaining packages is ongoing.
A blog post from SafeDep has additional analysis about the incident. We did not find an advisory from Red Hat on this yet.
Kernel development
Kernel release status
The current development kernel is 7.1-rc6, released on June 1. Linus said: "Well, I wouldn't call this 'small', but it is certainly smaller than rc5 was. And I don't think there's anything particularly scary here, so maybe we're still on track for a normal release cycle. Let's see."
This release has seen 15,352 non-merge changesets from 2,388 developers, 495 of whom were first-time kernel contributors. The release history looks like:
RC Date Commits v7.1-rc1 2026-04-26 13963 13963 v7.1-rc2 2026-05-03 475 475 v7.1-rc3 2026-05-10 584 584 v7.1-rc4 2026-05-17 428 428 v7.1-rc5 2026-05-24 748 748 v7.1-rc6 2026-05-31 473 473
See the LWN KSDB v7.1 page for a lot more details.
Stable updates: 7.0.11, 6.18.34, 6.12.92, 6.6.142, 6.1.175, 5.15.209, and 5.10.258 were released on June 1.
Distributions
DistroWatch turns 25
The DistroWatch site is celebrating its 25th anniversary. "All in all, it has been an incredible ride. Many of you who read these pages regularly know that downloading and testing distributions is a highly addictive pastime. I have been an avid distro-hopper for the last 25 years and I don't see myself abandoning this activity for many more years to come." Congratulations to Ladislav Bodnar and all the others who have kept that resource going for so long.
Fedora F44 election interviews published
The Fedora Project has published interviews with candidates running for the open seats on the Fedora Council, Fedora Engineering Steering Committee, Fedora Mindshare Committee, and EPEL Steering Committee. Voting is open through Friday, June 12 at 23:59 UTC.
Górny: why Gentoo?
Gentoo developer Michał Górny has written a lengthy article explaining the philosophy and purpose of the Gentoo Linux distribution, in response to a thread on Mastodon:
Gentoo is a source-first distribution, which means the primary method of installing software is to build it from source. Of course, that doesn't mean manually building stuff, following some kind of how-to: finding all the dependencies, installing them manually, going through a series of magical incantations, and eventually ending up no better than if we were installing a binary package. The package manager takes care of all the necessary steps and more, making package installs easy; well, at least unless something fails. But I'm digressing...
[...] We try to build a friendly and welcoming community around Gentoo, and we truly want using Gentoo be an enjoyable experience. We want it to be a system that doesn't betray you.
Development
Rust 1.96.0 released
Version 1.96.0 of the Rust programming language has been released. Changes include a new set of Copy-implementing Range types, assertions with pattern matching, a number of stabilized APIs, and two Cargo vulnerability fixes.Ombredanne: An AI agent ported our codebase from Python to Rust
Over on the AboutCode blog, lead maintainer Philippe Ombredanne writes about an agentic LLM system porting the ScanCode Toolkit to Rust. In the process, the LLM (or the people behind it) infringed the ScanCode trademark, stripped copyright and license notices, "and started an outreach campaign, without ever engaging the AboutCode community". Ironically, the toolkit is used to scan source code and binaries in order to figure out licensing and copyright information; it also reports on package dependencies, vulnerabilities, and more.
This is worth repeating: A comprehensive test suite, decent documentation, and curated datasets is what makes automated porting possible. It is also what makes a codebase easier to replicate without understanding it.The agent's initial approach, using an existing Rust license-detection library, failed to match ScanCode's output quality. The agent then did what any translator would do when a loose paraphrase fails: it copied the original more closely. The final port reproduces ScanCode's core algorithms, code organization, and data-driven architecture in Rust, not because the agent understood them, but because it had enough training data and test feedback to converge on equivalent code.
Vim Classic 8.3 released
Version 8.3 of Vim Classic has been released. This is the first release of the Vim fork since the project was announced in March.
This release is based on Vim 8.2.0148, with a number of bug fixes and patches conservatively backported from future versions of Vim upstream. We elected to clean up this version of Vim, prepare it for a release, and imagine an alternate history where Vim 8.3 was released without Vim9 script. The result is Vim Classic 8.3. We chose to take this approach in order to reduce the long-term maintenance burden of Vim Classic, acknowledging that our fork lacks the resources and institutional knowledge available to Vim upstream. However, a consequence is that there are some Vim plugins which are not compatible with Vim Classic.
We have made a special effort to assess patches from Vim upstream which mitigate some of the many CVEs affecting Vim which were discovered and fixed between versions 8.2 and modern-day Vim, but we can't be sure we've got all of the security patches which are applicable to Vim Classic (and practically exploitable). This version of Vim Classic is therefore recommended for early adopters who are comfortable adopting a security posture which accounts for the fact that we may have overlooked some bugs.
LWN covered Vim Classic and another Vim fork, EVi, in April.
Tridgell: rsync and outrage
Andrew Tridgell has written a blog post responding to complaints that he has begun using LLM tools in his work maintaining rsync:
Like many developers of open source packages I've been hit by a flood of security reports lately in my role as the rsync maintainer. Many of those reports are AI generated (not all though, there are some notable ones with very careful and high quality manual analysis).
As this flood started to get more intense I realised I needed to raise the defences on rsync a lot — we needed much more thorough test suites, code coverage analysis, CI testing on a lot more platforms, deliberate and thorough scanning for possible security issues (so I find at least some of them before other people!) and the addition of a whole lot of defence-in-depth hardening techniques.
[...] Now to the future, because we're not done yet by a long shot. The security reports keep rolling in. I'm working on a bunch of CVEs right now. Luckily I've been joined by some other very good developers with great systems development skills and security knowledge. Some of these people came to my attention partly because of all the rage happening at the moment, so I get some rage storm clouds have silver linings. Watch out for some credits for some great new rsync developers in the next release.
Development quotes of the week
— "kaithar" (Worth reading in full)Please, drive-by commenters... please, read the commit log yourself, audit the commits yourself, investigate what changes are being made and why, and only complain reply to this topic further if you actually understand the work since the beginning of March. Don't fall into the trap of "Every mention of AI is vibe-slop" because social media told you it must be so.
Are you truly arguing that rsync shouldn't receive fixes for a large number of bugs and identified security flaws? Are you arguing against defence-in-depth hardening aimed at reducing the viable attack surface for bugs not found yet? Are you petitioning to keep a test and release engineering setup that apparently wasn't fit for purpose if these bugs have evaded notice for so long and regressions have slipped through, as mentioned?
— Tim BrayLast month, on the "xml-dev" mailing list, Elliotte Rusty Harold remarked, on the subject of XML generally: "Count me as one of the people who thinks it's mostly obsolete and ultimately a failed experiment. People don't want or need markup that's designed to make documents easier for computers to read but harder for humans to write."
I replied and here's an expanded version of what I wrote:
Irrespective of the current uptake, and seen as an experiment, XML has been a success. It proved that:
- You can have a data interchange format that is radically independent of your computer architecture, operating system, programming language, and application.
- The only sane text standard for modern computing is Unicode, which in practice is affordable and reasonably straightforward to use.
Prior to 1996, neither of these things were widely believed. The only "interoperable" data format was ASN.1, which is horrible and lacked quality software support. The resistance to Unicode was significant and widespread, and adoption was disappointing. Today, #1 and #2 above are the (low) bar to entry for any data packaging technology.
Page editor: Daroc Alden
Next page:
Announcements>>