|
|
Log in / Subscribe / Register

Brief items

Security

Stenberg: The end of the curl bug-bounty program

Curl creator Daniel Stenberg has written a blog post explaining why the project is ending its bug-bounty program, which started in April 2019:

The never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live.

I have also started to get the feeling that a lot of the security reporters submit reports with a bad faith attitude. These "helpers" try too hard to twist whatever they find into something horribly bad and a critical vulnerability, but they rarely actively contribute to actually improve curl. They can go to extreme efforts to argue and insist on their specific current finding, but not to write a fix or work with the team on improving curl long-term etc. I don't think we need more of that.

There are these three bad trends combined that makes us take this step: the mind-numbing AI slop, humans doing worse than ever and the apparent will to poke holes rather than to help.

Stenberg writes that he still expects "the best and our most valued security reporters" to continue informing the project when security vulnerabilities are discovered. The program will officially end on January 31, 2026.

Comments (32 posted)

A critical GnuPG security update

There is a new GnuPG update for a "critical security bug" in recent GnuPG releases.

A crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack buffer overflow in gpg-agent during the PKDECRYPT--kem=CMS handling. This can easily be used for a DoS but, worse, the memory corruption can very likley also be used to mount a remote code execution attack. The bug was introduced while changing an internal API to the FIPS required KEM API.

Only versions 2.5.13 through 2.5.16 are affected.

Full Story (comments: 22)

Security quotes of the week

Let's workshop a scenario a little. Bad things happen. People are afraid. People buy one of the small number of phones that is almost entirely free software, and organise resistance that way. The resistance are now disproportionately using devices that have IMEIs [International Mobile Equipment Identities] from specific ranges, and which can be geolocated through tower records. What do you think happens next?

[...] If you're in the US and you want to reduce the risk the vendor will fuck you over on behalf of the government without looking suspicious? Much as it pains me to say it, Apple's track record in refusing to assist the FBI in the San Bernardino case is a strong signal there.

Matthew Garrett

First, it's important to recognize that today's AI is fundamentally untrustworthy, for the same reasons that search engines and social media platforms are.

The problem is not the technology itself; fast ways to find information and communicate with friends and family can be wonderful capabilities. The problem is the priorities of the corporations who own these platforms and for whose benefit they are operated. Recognize that you don't have control over what data is fed to the AI, who it is shared with and how it is used. It's important to keep that in mind when you connect devices and services to AI platforms, ask them questions, or consider buying or doing the things they suggest.

Bruce Schneier and Nathan E. Sanders

All internet voting systems are insecure. The insecurity is worse than a well-run conventional paper ballot system, because a very small number of people may have the power to change any (or all) votes that go through the system, without detection. This insecurity has been known for years; every internet voting system yet proposed suffers from it, for basic reasons that cannot be fixed with existing technology.
— a letter signed by 21 computer scientists expert in election security

Comments (none posted)

Kernel development

Kernel release status

The current development kernel is 6.19-rc7, released on January 25. Linus remarked:

So normally this would be the last rc of the release, but as I've mentioned every rc (because I really want people to be aware and be able to plan for things) this release we'll have an rc8 due to the holiday season.

And while some of the early rc's were smaller than usual and it didn't seem necessary, right now I'm quite happy I made that call. Not because there's anything particularly scary here - the release seems to be going fairly smoothly - but because this rc7 really is larger than things normally are and should be at this point.

Along with the usual fixes, this -rc also includes a new document describing the process to replace the kernel project leadership should that become necessary in the absence of an arranged transition. The plan largely follows what was decided at the Maintainers Summit in December.

Stable updates: 6.18.7 and 6.12.67 were released on January 23.

The 6.18.8, 6.12.68, and 6.6.122 stable updates are in the review process; they are due on January 30.

Comments (none posted)

PC Gamer on the scx_horoscope scheduler

PC Gamer has run an amusing review of the scx_horoscope scheduler for Linux, which uses astrology to optimize scheduling decisions.

The scheduler is full of bizarre features, like its ability to perform real planetary calculations based on accurate geocentric planetary positions, lunar phase scheduling (the full moon gives a 1.4x boost to tasking, apparently) and "zodiac-based task classification".

That latter feature is easily one of my favourite bits. Specific planetary bodies "rule" over specific system tasks, so the Sun is in charge of critical system processes, the Moon (tied to emotions, of course) rules over interactive tasks, and Jupiter is assigned to memory-heavy applications, among others.

Comments (22 posted)

Distributions

GNU Guix 1.5.0 released

Version 1.5.0 of the GNU Guix package manager and the Guix System have been released. Notable improvements include the ability to run the Guix daemon without root privileges, support for 64-bit RISC-V, and experimental support for the GNU Hurd kernel.

The release comes with ISO-9660 installation images, virtual machine images, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries—check out the download page. Guix users can update by running guix pull.

It's been 3 years since the previous release. That's a lot of time, reflecting both the fact that, as a rolling release, users continuously get new features and update by running guix pull; but it also shows a lack of processes, something that we had to address before another release could be made.

During that time, Guix received about 71,338 commits by 744 people, which include many new features.

LWN last looked at Guix in February 2024.

Comments (1 posted)

30 years of ReactOS

ReactOS, an open-source project to develop an operating system that is compatible with Microsoft Windows NT applications and drivers, is celebrating 30 years since the first commit to its source tree. In that time there have been more than 88,000 commits from 301 contributors, for a total of 14,929,578 lines of code. There is, of course, much left to do.

It's been such a long journey that many of our contributors today, including myself, were not alive during this event. Yet our mission to deliver "your favorite Windows apps and drivers in an open-source environment you can trust" continues to bring people together. [...]

We're continuing to move ReactOS forward. Behind the scenes there are several out-of-tree projects in development. Some of these exciting projects include a new build environment for developers (RosBE), a new NTFS driver, a new ATA driver, multi-processor (SMP) support, support for class 3 UEFI systems, kernel and usermode address space layout randomization (ASLR), and support for modern GPU drivers built on WDDM.

Comments (16 posted)

Distributions quote of the week

I'm not going to get into the value proposition of Fedora Flatpaks here. There is value there, but as long as we are constructing it in a way that is in direct conflict with upstream outputs it will be be difficult to articulate. Because right now what is blazingly obvious is that the conflict with upstream is damaging to project health, and its not clear to me that the conflict is necessary. So the opt-in filter is a compromise that we can implement right now, while we figure out the full technical solution and restructure our flatpak offerings so that they are not in direct conflict with upstream efforts.

We've put ourselves in a bind here because its clear we didn't really think through how a federated flatpak environment should work to minimize conflict, before we spun up our own collection of alternative application builds. We missed something vital about what the flatpak federated landscape should be and we need to address it with some structural changes.

Jef Spaleta

Comments (none posted)

Development

The GNU C Library is moving from Sourceware

GNU C Library maintainer Carlos O'Donell has announced that the project will be moving its core services away from Sourceware in favor of services hosted at the Linux Foundation.

While it was clear to the GNU Toolchain leadership that requirements were coming to improve the toolchain cyber-security posture, these requirements were not clear to all project developers. As part of receiving this feedback we have worked to document and define a secure development policy for glibc and at a higher level the GNU Toolchain. While Sourceware has started making some critical technical changes, the GNU Toolchain still faces serious, systemic concerns about securing a global, highly available service and building a sustainable, diverse sponsorship model.

This has been a long-running discussion; see this 2022 article for some background.

Comments (none posted)

GNU C Library 2.43 released

Version 2.43 of the GNU C Library has been released. Changes include support for the mseal() and openat2() system calls, experimental support for building with the Clang compiler, Unicode 17.0.0 support, a number of security fixes, and much more.

Comments (50 posted)

Rust 1.93.0 released

Version 1.93.0 of the Rust programming language has been released. Notable changes include in updated version of the bundled musl library, thread-local storage for the global allocator, some asm! improvements, and a number of newly stabilized APIs.

Comments (none posted)

Xfwl4: the roadmap for a Xfce Wayland compositor

The Xfce team has announced that it will be providing funding to Brian Tarricone to work on xfwl4, a Wayland compositor for Xfce:

Xfwl4 will not be based on the existing xfwm4 code. Instead, it will be written from scratch in rust, using smithay building blocks.

The first attempt at creating an Xfce Wayland compositor involved modifying the existing xfwm4 code to support both X11 and Wayland in parallel. However, this approach turned out to be the wrong path forward for several reasons:

  • Xfwm4 is architected in a way that makes it very difficult to put the window management behavior behind generic interfaces that don't include X11 specifics.
  • Refactoring Xfwm4 is risky, since it might introduce new bugs to X11. Having two parallel code bases will allow for rapid development and experimentation with the Wayland compositor, with zero risk to break xfwm4.
  • Some X11 window management concepts just aren't available or supported by Wayland protocols at this time, and dealing with those differences can be difficult in an X11-first code base.
  • Using the existing codebase would require us to use C and wlroots, even if a better alternative is available.

Work has already commenced on the project, and the project hopes to share a development release in mid-2026.

Comments (54 posted)

Development quote of the week

Some people like driving too fast on mountain roads. Some people parachute. Some people juggle running chainsaws on fire. We commit to main. We are all the same.
Lars Wirzenius

Comments (none posted)

Miscellaneous

OSI pauses 2026 board election cycle

The Open Source Initiative (OSI) has announced that it will not be holding the 2026 spring board election. Instead, it will be creating a working group to "review and improve OSI's board member selection process" and provide recommendations by September 2026:

The public election process was designed to gather community priorities and improve board member selection, while final appointments remained with the board.

Over time, that nuance has become a source of understandable confusion for community members. Many reasonably expected elections to function as elections normally do, and in fact, the board has generally adopted the electorate's recommendations. When a process feels unclear, trust suffers. When trust suffers, engagement becomes harder. This is especially problematic for an organization whose mission depends on legitimacy and credibility. [...]

OSI tried its experiment for the right reasons, but a variety of factors resulted in "elections" that are performatively democratic while being gameable and representative of only a small group, and we've learned from the results. Now we are making space to align our director selection process with our bylaws, to rebuild trust, and to develop better, more durable and truly representative participation in which the global stakeholder community can be heard.

LWN covered the previous OSI election in March 2025.

Comments (12 posted)

Mourning Didier Spaier

We have received the sad news that Didier Spaier, maintainer of the blind-friendly Slackware-based Slint distribution, has recently passed away. Philippe Delavalade, who posted the announcement to the Slint mailing list, said:

Early 2015, I asked on the slackware list if brltty could be added in the installer; Didier answered promptly that he could do it on slint. Afterwards, he worked hard so that slint became as accessible as possible for visually impaired people.

You all know that all these years, he tried and succeeded to answer as quickly as possible to our issues and questions.

He will be irreplaceable.

Comments (3 posted)

Page editor: Daroc Alden
Next page: Announcements>>


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds