Brief items

OpenSSL 4.0.0 released

Version 4.0.0 of the OpenSSL cryptographic library has been released. This release includes support for a number of new cryptographic algorithms and has a number of incompatible changes as well; see the announcement for the details.

Full Story (comments: 4)

Security quotes of the week

I suspect that as with spam, LLMs will shift the cost balance of security. Most software contains some vulnerabilities, but finding them has traditionally required skill, time, and motivation. In the current equilibrium, big targets like operating systems and browsers get a lot of attention and are relatively hardened, while a long tail of less-popular targets goes mostly unexploited because nobody cares enough to attack them. With ML assistance, finding vulnerabilities could become faster and easier. We might see some high-profile exploits of, say, a major browser or TLS library, but I'm actually more worried about the long tail, where fewer skilled maintainers exist to find and fix vulnerabilities. That tail seems likely to broaden as LLMs extrude more software for uncritical operators. I believe pilots might call this a "target-rich environment".

This might stabilize with time: models that can find exploits can tell people they need to fix them. That still requires engineers (or models) capable of fixing those problems, and an organizational process which prioritizes security work. Even if bugs are fixed, it can take time to get new releases validated and deployed, especially for things like aircraft and power plants. I get the sense we're headed for a rough time.

General-purpose models promise to be many things. If Anthropic is to be believed, they are on the cusp of being weapons. I have the horrible sense that having come far enough to see how ML systems could be used to effect serious harm, many of us have decided that those harmful capabilities are inevitable, and the only thing to be done is to build our weapons before someone else builds theirs. We now have a venture-capital Manhattan project in which half a dozen private companies are trying to build software analogues to nuclear weapons, and in the process have made it significantly easier for everyone else to do the same. I hate everything about this, and I don't know how to fix it.

— Kyle Kingsbury

Even if you believe that the LLMs will eventually be able to fix security issues in an automated or semi-automated way, there’s still a period of time coming up when much more human bug fixing will be needed to deal with the "flood." Any codebase (open source or proprietary) comes with a short position in maintenance programmers, and all this LLM bug report news means the short squeeze is on.

— Don Marti

Comments (none posted)

Kernel release status

The 7.0 kernel is out, released on April 12. Linus said:

The last week of the release continued the same "lots of small fixes" trend, but it all really does seem pretty benign, so I've tagged the final 7.0 and pushed it out.

I suspect it's a lot of AI tool use that will keep finding corner cases for us for a while, so this may be the "new normal" at least for a while. Only time will tell.

Significant changes in this release include the removal of the "experimental" status for Rust code, a new filtering mechanism for io_uring operations, a switch to lazy preemption by default in the CPU scheduler, support for time-slice extension, the nullfs filesystem, self-healing support for the XFS filesystem, a number of improvements to the swap subsystem (described in this article and this one), general support for AccECN congestion notification, and more. See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 7.0 page for more details.

Stable updates: 6.19.12, 6.18.22, 6.12.81, 6.6.134, and 6.1.168 were released on April 11.

Comments (none posted)

Quote of the week

The tools I used to build my kernel patch didn't exist six months ago. My AI harness is just as much a dependency, and it didn't exist three months ago. My harness undergoes rapid development and increases in capabilities, even without newer, smarter models releasing every few months.

I think there's a real risk of a negative feedback loop. As implementation costs drop, people who could contribute to upstream will find it easier to build and maintain a custom stack rather than try to get changes through a multi-year review process. I think experienced developers need to lead a shift in how contributions are reviewed and organized. I think the key challenge for maintainers is figuring out how to work with a new class of contributor, and direct them so they work in a coordinated manner.

— Sean Smith

Comments (none posted)

Distributions quote of the week

The quiet milestone in the Rust for Linux 7.1 pull request is not the version bump. The minimum Rust compiler moves to 1.85. Bindgen moves to 0.71.1. Both match what stable Debian Trixie has shipped since August 2025. A vanilla Debian host can now compile a Rust-enabled kernel without backporting a toolchain. The most conservative distribution and the kernel toolchain are aligned. That is how a feature stops being a special build and becomes default infrastructure.

— Can Artuc

Comments (none posted)

Relicensing versus license compatibility (FSF Blog)

The Free Software Foundation has published a short article on relicensing versus license compatibility.

The FSF's Licensing and Compliance Lab receives many questions and license violation reports related to projects that had their license changed by a downstream distributor, or that are combined from two or more programs under different licenses. We collaborated with Yoni Rabkin, an experienced and long time FSF licensing volunteer, on an updated version of his article to provide the free software community with a general explanation on how the GNU General Public License (GNU GPL) is intended to work in such situations.

Comments (7 posted)

Servo now on crates.io

The Servo project has announced the first release of servo as a crate for use as a library.

As you can see from the version number, this release is not a 1.0 release. In fact, we still haven't finished discussing what 1.0 means for Servo. Nevertheless, the increased version number reflects our growing confidence in Servo's embedding API and its ability to meet some users' needs.

In the meantime we also decided to offer a long-term support (LTS) version of Servo, since breaking changes in the regular monthly releases are expected and some embedders might prefer doing major upgrades on a scheduled half-yearly basis while still receiving security updates and (hopefully!) some migration guides. For more details on the LTS release, see the respective section in the Servo book.

Comments (4 posted)

Zig 0.16.0 released

The Zig project has announced version 0.16.0 of the Zig programming language.

This release features 8 months of work: changes from 244 different contributors, spread among 1183 commits.

Perhaps most notably, this release debuts I/O as an Interface, but don't sleep on the Language Changes or enhancements to the Compiler, Build System, Linker, Fuzzer, and Toolchain which are also included in this release.

LWN last covered Zig in December 2025.

Comments (7 posted)

Development quote of the week

I had a really deflating open source experience just now. I started writing user stories in the django-simple-deploy docs. I opened an issue to track the work, and added the "good first issue" and "help wanted" labels.

It's a good first issue because a new contributor can skim our user stories, get a clear sense of who we're serving, ask relevant questions, and maybe help further articulate typical uses. Help wanted, because I want others' perspectives in these stories.

In less than three minutes there was a PR. It's from Claude, but it's not from someone running Claude for the purposes of helping out this project. They're just running Claude entirely automated, against any repo that adds a "help wanted" label.

There are interesting ideas in the submission. But it should be a comment in an issue, not a PR. And it should be submitted by a person, not a bot that dumps noise into as many repos as it can find.

— Eric Matthes (part 1, part 2)

Comments (none posted)

FSF clarifies its stance on AGPLv3 additional terms

OnlyOffice CEO Lev Bannov has recently claimed that the Euro-Office fork of the OnlyOffice suite violates the GNU Affero General Public License version 3 (AGPLv3). Krzysztof Siewicz of the Free Software Foundation (FSF) has published an article on the FSF's position on adding terms to the AGPLv3. In short, Siewicz concludes that OnlyOffice has added restrictions to the license that are not compatible with the AGPLv3, and those restrictions can be removed by recipients of the code.

We urge OnlyOffice to clarify the situation by making it unambiguous that OnlyOffice is licensed under the AGPLv3, and that users who already received copies of the software are allowed to remove any further restrictions. Additionally, if they intend to continue to use the AGPLv3 for future releases, they should state clearly that the program is licensed under the AGPLv3 and make sure they remove any further restrictions from their program documentation and source code. Confusing users by attaching further restrictions to any of the FSF's family of GNU General Public Licenses is not in line with free software.

Comments (9 posted)