LWN.net Weekly Edition for December 26, 2024
Welcome to the LWN.net Weekly Edition for December 26, 2024
This edition contains the following feature content:
- A 2024 retrospective: a look back at the year that was and how well our predictions fared.
- FESCo provenpackager sanction causes problems: an administrative process goes wrong in the Fedora community.
- Process creation in io_uring: a new attempt to make the fork()/exec() pattern more efficient and flexible.
- Systemd improves image features and adds varlink API: an overview of new features in systemd v257.
- Systemd takes steps toward a more secure boot process: a closer look at how systemd v257 improves secure boot.
- Tim Peters returns to the Python community: the suspension of a core Python developer ends, but questions about the process remain.
This week's edition also includes these inner pages:
- Brief items: Brief news items from throughout the community.
- Announcements: Newsletters, conferences, security updates, patches, and more.
This is the last LWN.net Weekly Edition for 2024. Following our tradition, we will take the last week of the year off so that we can be rested and ready for 2025. The Weekly Edition will return on January 9. We wish for a fine holiday season and an auspicious new year for all of our readers.
Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.
A 2024 retrospective
It is often said that the definition of insanity is repeating the same action and expecting different results. Be that as it may, LWN has repeatedly started a new year with a set of predictions, only to have to review how badly they went at the end. There was no break in that pattern this year, so there is no help for it; the time has come to review our 2024 predictions in the hope that they came out better this time around.
What was predicted
We started with a prediction that the kernel community would (slowly) begin to move away from email during this year. With a suitably broad interpretation of "slowly", this prediction was not entirely wrong. A search for "b4 relay" return addresses in the kernel's mailing-list archives shows that some people are, indeed, submitting patches without using an email client. There are also, as related in the 2024 Maintainers Summit, some beginning experiments with the use of Forgejo for kernel development, but nothing is yet available to the public. It is a slow beginning indeed; email remains central to the development process.
The next long-term-stable kernel release was 6.12, just as predicted, but we were two weeks off on the release date. In modern times, every kernel development cycle is nine or ten weeks long; our estimate included more ten-week cycles than actually happened. In fact, the only ten-week cycle was 6.7, released just after the new year. The longer cycles, it would seem, are becoming increasingly uncommon. The development cycle is becoming more predictable — and we failed to predict it.
The first user-visible Rust code (an Asix PHY driver) was indeed merged in 6.8 as predicted. While that merging was not the explicit declaration of success for the Rust experiment that had been predicted, it has become increasingly clear over the course of the year that Rust is in the kernel to stay. Whether the lack of a GCC-based Rust compiler actually became a bigger problem as predicted is debatable at best, though; much of the community would appear to be at ease with the existence of a single compiler for the language.
Was the enterprise-distribution market "shaken up" as predicted? To a great extent, that market looks just like it did at the beginning of the year, distinctly unshaken. That said, distributors like AlmaLinux and Rocky Linux are working to define their own space that isn't just a clone of Red Hat Enterprise Linux, even if they have not strayed far from that model. So not "shaken up", but possibly "slightly nudged".
The prediction that Firefox would reverse its long-term decline in market share appears to have been flat-out wrong. Firefox market share continues to shrink, despite increasingly user-unfriendly moves by Google with the Chrome browser. We may be reaching a point of no return; Firefox once saved us from a browser monopoly, but that reprieve seems to have been temporary.
Open-source generative AI did receive a lot of attention this year, though not quite in the way that was predicted. Much of that attention went toward models that, while said to be "open source", are actually proprietary. While there is some interest in, and work on, truly open-source large language models, it is still far overshadowed by the massively funded proprietary systems.
In classic tautological form, we predicted that it would be a big year for BPF, and it was. Our slightly less obvious prediction, that the rejection of the extensible scheduler class would be reconsidered, turned out to be accurate; that code was merged into 6.12.
The Python 3.13 release in October did include experimental free-threading support as predicted. Whether it is a "qualified success", as also predicted, remains to be seen.
The last prediction we made was that the maintainer crisis would intensify, and that this would result in a number of problems, including security issues. This is where your editor can proudly take a bow for having predicted the XZ backdoor attempt, which is indeed a security issue that can be traced back to maintainer overload. The truth of the matter, of course, is that we were as surprised by that event as everybody else, but the fact that something like it happened was not as surprising.
What was missed
What should we have predicted but failed to? One can start with the XZ attack, of course. Sooner or later, state-level attackers were going to try to plant their hooks into the software that runs much of the world; the only real question was when such an attack would come to light. There are surely other intrigues underway that we are not, yet, aware of.
Arguably, we should have seen that, despite their successes, the Rust-for-Linux developers would be subject to burnout like any others. Pushing a new language into an established project like the kernel is not a short-term project, and it is not a good project for developers who are not willing to be persistent in the face of seemingly arbitrary obstruction over the long term. Banging one's head against the wall turns out not to be as much fun as it seems, and sometimes the wall wins. We lost at least one key Rust-for-Linux developer for that reason this year, and others have been heard to wonder how much longer they are willing to keep up the fight — even though they are winning.
The kernel project taking on responsibility for its own CVE-number assignment came as a surprise to nearly everybody. Given the number of projects that have felt the need to become their own CVE numbering authorities, the only real surprise, in retrospect, is how long it took for the kernel to follow suit. We also, obviously, did not predict that the GNU C Library project would make the same move at almost the same time.
Like the prescient economist who has successfully predicted seven out of the last three recessions, LWN has often predicted that the last of the realtime preemption patch set would make it into the kernel. Naturally, we failed to make any such prediction in the year when it actually happened.
We obviously could have predicted the adoption of the European Cyber Resilience Act — after modifications to make it better suited to the needs of the open-source community.
We did not see the Redis license change coming, despite the fact that this sort of database system seems particularly prone to such games. In the area of foundations, we failed to predict the upheaval in the NixOS Foundation, the financial problems that have come to light in the GNOME Foundation, or the creation of the Open Home Foundation. We also didn't see the ongoing WordPress mess coming.
In hindsight, the abrupt removal of a number of Russian developers from the kernel's MAINTAINERS file might have been predictable. The free-software community likes to think of itself as operating above the mundane world of national laws and international conflict, but the world takes a different view of things. We were never going to remain untouched by a conflict of that magnitude.
The passing of members of our community is not something we would ever try to predict; such events are always an unhappy surprise. Still, the untimely loss of Daniel Bristot de Oliveira was especially shocking to everybody involved. This year, we also mourn the loss of Dave Mills, Gunnar Hjalmarsson, Jérémy Bobbio, Larry Finger, Mel Chua, Mike Karels, Peter de Schrijver, and Simon Riggs, among others. They are all sorely missed.
In closing
This was a year of change at LWN, highlighted by the addition of two new members (Daroc Alden and Joe Brockmeier) to our staff; they have quickly integrated and now it almost feels like they have always been here. Over this year, we have reported from 22 conferences (thanks are due, one more time, to the Linux Foundation for supporting our travel to these events). We published 51 weekly editions this year, containing 345 feature articles and 26 guest articles. It has, in other words, been a busy year.
Individual subscriptions are up slightly from this time last year; that is a welcome increase, but we hope that trend will continue, and even accelerate, as we try to do justice to the task of covering our large and active community. We are deeply grateful to all of you who have subscribed; you are the only reason why LWN is still here after 26 years and why we plan to be here for many years yet. We wish you all the best of the holiday season and the new year.
FESCo provenpackager sanction causes problems
The Fedora Engineering Steering Council (FESCo) has made a series of missteps in deciding to revoke a longtime Fedora contributor's provenpackager status. FESCo made the decision during a closed session, based on private complaints. It then publicly announced its decision, including the contributor's name, while only supplying a vague account of the contributor's actions. This has left the Fedora community with more questions than answers, and raised a number of complaints about the transparency of FESCo's process. In addition, the sequence of events has sparked discussions about package ownership, as well as when and how it's appropriate to push changes to packages that a developer doesn't own.
Package ownership
Sources for Fedora packages are currently hosted using Fedora's Git forge software, Pagure (though it is due to be replaced by Forgejo in 2025) at src.fedoraproject.org. The packages are managed using Distribution Git (dist-git), which is basically a Git implementation with additional data storage designed to hold content of source RPMs.
In Fedora, packages are typically owned by a maintainer who has packager status. This status is not granted automatically—users have to have a sponsor and learn the ropes to be added to the "packager" group. Once added to the group, they then have the ability to commit changes to the repository for packages they own. Then the package can be submitted to Fedora's Koji build system to be built for a release. Each package repository has a branch for each release that the package exists in, so a package might have f39, f40, f41, and rawhide branches for Fedora 39 through Fedora 41 and Rawhide, for example.
There are many scenarios where packagers may wish to modify packages they do not own. For example, when a person is packaging an update to an application they may need a newer version of a library it depends on. If the owner of the library package has not gotten around to updating it yet, it can be inconvenient to wait for its maintainer to make the update. This is a common scenario in a project where some contributors are paid to work on packaging, while others are volunteers who check in infrequently as time allows. Anyone can submit a pull request (PR) to modify a package, even if they aren't a Fedora packager at all, but only the maintainer (or co-maintainers), can commit those changes.
One exception to this is if a person has provenpackager status. The members of the "provenpackager" group have rights to commit changes to packages they do not own or maintain. To gain this status, a packager must submit a ticket to FESCo requesting the status and must receive at least three affirmative votes (and no negative votes) from provenpackager sponsors. For perspective, the list of packagers includes 2072 users, while there are only 156 members in the provenpackager group on src.fedoraproject.org.
Revocation
The episode began (at least publicly) on December 13, when FESCo
member Josh Stone sent an announcement
to fedora-devel that stated FESCo voted, after a private meeting, to revoke
Peter Robinson's provenpackager status. Robinson has worn many hats within
the project over the years, including a stint as part of Fedora's release-engineering team while employed by Red Hat. He has served on the
now-defunct Fedora Board and its replacement, the Fedora Council. He
left Red Hat in September and currently maintains more than 120 packages in
Fedora as a volunteer. Stone wrote that multiple tickets
had been opened with FESCo, privately, regarding Robinson's "packaging
behavior
":
In particular, on numerous occasions Peter has pushed uncommunicated updates to packages he has no prior relationship with, interfering with those packages' maintenance efforts. On at least a few occasions, this has resulted in other maintainers being forced to react to these changes with no coordination or notice.
The statement claimed that FESCo representatives had several
conversations with Robinson and they had issued warnings to him, but he had
continued to "use his provenpackager privileges in an unapproved manner,
frequently causing additional work for other maintainers
". As a result,
FESCo had voted that his provenpackager status would be revoked, though he would
still retain packager status. Stone said that the vote to revoke the status
was seven in favor, and two against—but did not note how the
individual members had voted.
People were quick to respond to the announcement with questions and requests for additional information. Gary Buhrmaster said that, to be transparent, FESCo should provide the specific conduct that led it to make its decision:
Facts are facts, and should not be in dispute, nor hidden from the community at large, should FESCo wish to maintain the full trust of that community.
Dominik Mierzejewski said
that FESCo should supply an "exhaustive explanation with a compelling
justification
" for revoking Robinson's status, and to supply individual
FESCo member votes before the current election closes on
December 20.
FESCo member Fabio Valentini replied
that FESCo had agreed to provide a public ticket with a summary of its
deliberations "it just hasn't happened yet
". That led others to wonder why
FESCo had announced the decision before having the public ticket at the
ready, and suggest that FESCo should hold back such announcements in the
future.
First time
Valentini eventually responded
that FESCo was still "coordinating internally
" about supplying
more information publicly. He prefaced his response by saying he was
only speaking for himself, not all of FESCo. He reacted to some of the
criticisms by saying that this was the first time that FESCo had been
asked to revoke provenpackager status, so there was no process for
doing so. As for timing, he said that the date of the announcement was
chosen to be shortly after the decision was made and before FESCo
members were offline for the holidays.
Robinson himself spoke
up to say that the public announcement provided more "openness and
transparency
" than the email he had received personally from FESCo. (He
linked to a screenshot of his reply to the email on Google Drive.) He said that none of the changes
he has made to packages were meant to be malicious, but were made to
improve the project and fix "actual problems users are
experiencing
".
He said that he had not been aware of any of the tickets that
had been opened with FESCo, and could only remember one conversation with a
FESCo representative about a change
that he had made to the dav1d package, a
cross-platform decoder for the AV1 codec, maintained by Valentini. In that
conversation he had agreed that he should not have updated the .gitignore file in the repository, but that it had been done
"without malice
". Robinson added that the other changes to the
package were made "using my architecture maintainers hat
" in an
attempt to solve numerous complaints about performance of video codecs on
aarch64 for devices that do not have hardware acceleration.
Robinson's response also alluded to a history of disagreements with
Valentini over maintenance of other packages. He questioned whether
FESCo's process was unbiased, given that Valentini had been involved in the
discussions and vote to remove him. "This feels like a kangaroo court to
me
." He said he looked forward to FESCo providing details of its
conversations, since he had not received a reply directly.
"Broken trust"
Former Fedora Project Leader (FPL) Jared K. Smith expressed
surprise "that this would happen with so little
communication with Peter, and in such a public manner
". He said he'd
known Robinson for more than ten years, and always found him helpful and
had not known him to abuse provenpackager privileges. People-related
complaints always require a certain level of privacy, but "this doesn't
pass the sniff test
".
Stephen Smoogen said
that Robinson can be difficult to deal with at times, but that his work was
in service of the parts of the project he has been given charge over. Of the
many people who had used provenpackager privileges in problematic ways,
Robinson was the person he thought least likely to be dropped from the
group. He hoped that those matters would be dealt with in a public setting
in the future, or that information would at least be published before
judgment was announced: "There have been a lot of things in the past
that tested my temper in Fedora, but this is the first thing that has truly
broken my trust.
" Simon de Vlieger also wanted
to know why FESCo chose to publicly name Robinson in its announcement,
and said it was "unnecessarily harmful
".
Vit Ondruch was one of the few who spoke up in support of FESCo. He replied to the list with Robinson's commit to the Ruby package, which Ondruch owns, in 2014. Robinson said that it was when he was one of two release-engineering people working on Fedora, and the package was likely blocking the building of release artifacts. The example was not, he said, relevant or useful since a lot of things had changed since that patch was committed.
Ondruch replied
with more detail, saying that Robinson's changes—including
renumbering patches in the RPM spec file—were more than needed for
part of the release process. He said he would "love to believe that this
is a relic of the past, but some of the recent discussions
" on the list
did not support that. He did not elaborate about which discussions, and a
quick search through recent fedora-devel discussions does not turn up any
obvious examples. Given the age of his example, it's possible that his
definition of recent extends farther into the past than one might
expect. Ondruch also complained that Robinson didn't include "something
like 'sorry'
" for the decade-old offense so that "we could move
on
".
FESCo apologizes
FESCo member David Cantrell replied
to the thread on December 16, and issued an apology on behalf of FESCo
"for how we communicated the news
". He said it was difficult to
figure out how best to communicate "and we have made mistakes
" by
failing to make the facts available quickly. In some cases, he said, FESCo
was dealing with situations where reporters wanted to remain anonymous.
He said that FESCo was "currently assembling
" its facts so they
could be shared publicly, but first wanted to discuss it with
Robinson. FESCo is also discussing revising the provenpackager policies and its
policies for handling situations related to provenpackagers. He reiterated
that it was the first time FESCo had been asked to revoke those
permissions.
Adam Williamson said that it struck him as problematic that FESCo was allowing anonymity in the process:
This is essentially a technical/process dispute, right? I see no indication that Peter has been accused of a particularly heinous crime or a CoC violation or anything like that. I'm having trouble seeing how anything that doesn't rise to that level could warrant a process involving anonymity for 'reporters' and behind-closed-doors FESCo discussions.
Valentini muddied
the waters further by saying that none of the parties requested
anonymity, but FESCo could not simply make the ticket public "because it
also references a [Code of Conduct] (CoC) issue which *is* private and
cannot be shared
". Daniel P. Berrangé said he was
surprised about the mention of a CoC issue, since that should be handled
with confidentiality and by the CoC committee rather than FESCo.
FPL steps in
Current FPL Matthew Miller stepped
in on December 17 to say: "Several things went very, very
wrong in all this.
"
If the Proven Packager guidelines are ambiguous enough that different readings of them can lead to conflict this strong, we need to clarify them and make sure we have consensus on the [conferred] powers and duties.
In any case, FESCo should not be [adjudicating] Code of Conduct or behavioral allegations, and FESCo actions must not be used as a "shadow" CoC enforcement mechanism.
Miller said that he was not sure what needed to be done to make things right, but that Fedora's Council—which is Fedora's top-level community leadership body—would be working on immediate actions before the holiday, and longer-term actions in January.
Valentini, having been the one to drop the CoC comment in the first
place, complained
that he didn't understand where the idea came from that "this was
basically a CoC issue that was raised to FESCo [...] it's just not
true
". He said that FESCo is not usurping CoC responsibilities, and the
CoC mention was "only a minor side note
" that should not have been
mentioned at all. It is, to date, still unclear where CoC complaints factor
into this situation, the nature of any complaints, and if Robinson was the
subject of those complaints.
On December 18, Miller provided an update, saying that the Fedora Council had met to discuss the topic and had asked FESCo to put its decision on hold while the council investigates. The council would compile a report of what happened and when.
This is going to take some time (and would even without the holidays), and I appreciate your patience. The specific situation connects into broad questions about what "proven packager" should be — and even bigger ones about what it means to be a package maintainer in Fedora. I hope that we can improve how we collaborate and communicate overall. Once we have a full understanding, we will make recommendations on next steps, and possibly adjust Council policies.
Proven packager problems
Setting aside the personalities involved and FESCo's communication fumbles, this episode brings to the fore a common problem for community Linux distributions like Fedora and Debian. There is an inherent tension between individual package ownership and the collective responsibility and collaboration required for the entire project to work. Debian has had a number of discussions this year that have touched on ending single-person package maintainership, though little progress has been made in that area.
In the provenpackager thread, Richard W.M. Jones noted
that there were times when a group of packages needed to be updated
together and it was not feasible "to go through a months long
asynchronous process where every package is a special flower
". Jones
said that Fedora needed "a bit less ownership and a bit more shared
responsibility with packaging
" and that packagers should just try to do
the right thing.
Berrangé agreed with
Jones that the notion of package ownership could give rise to problems. He
said that packagers should be considered custodians of packages, rather
than owners. "Fedora owns the package, maintainers are looking after it
on behalf of Fedora.
" Packagers have personal preferences, but they
should put those aside for the greater good of the project. If someone is
following Fedora procedures, he said, "that should be considered fine,
even if it doesn't align with personal preferences
".
The provenpackager guidelines, he said, are too vague and open to interpretation. It was easy to see how differences of opinion would arise from the non-specific guidance in the policy:
Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull requests, IRC, matrix, or email.
Do provenpackagers need to try all five communication methods? How many
times do they need to try? "Combine that with 'personal preferences' and
it is surprising there are not more conflicts seen.
" The policy, he
said, should have a default method that is considered sufficient to satisfy
common scenarios.
It is, to say the least, not easy to provide policies that balance the needs of the many and the few. A project must find a way to avoid demotivating or hindering volunteers who do the bulk of the work on individual packages, while still making it possible for others to step in as needed. Giving gatekeeping powers over packages to individuals is, perhaps, necessary to ensure that volunteers will take responsibility to ensure the work gets done. But the single-maintainer model that has evolved can be at odds with long-term sustainability, contribute to maintainer burnout, and leave a vacuum when a packager suddenly steps away.
Managing the disagreements and conflicts when they arise between packagers requires clear policies and skillful diplomacy. In this instance, both seem to have failed. The provenpackager policy leaves too much room for individual differences of opinion. It also lacks a clear resolution process, and FESCo's attempt to create one on the fly—behind closed doors—has gone poorly. One hopes that Miller and the council will be able to achieve a better outcome.
Process creation in io_uring
Back in 2022, Josh Triplett presented a plan to implement a "spawn new process" functionality in the io_uring subsystem. There was a fair amount of interest at the time, but developers got distracted, and the work did not progress. Now, Gabriel Krisman Bertazi has returned with a patch series updating and improving Triplett's work. While interest in this functionality remains, it may still take some time before it is ready for merging into the mainline.A new process in Linux is created with one of the variants of the clone() system call. As its name suggests, clone() creates a copy of the calling process, running the same code. Much of the time, though, the newly created process quickly calls execve() or execveat() to run a different program, perhaps after performing a bit of cleanup. There has long been interest in a system call that would combine these operations efficiently, but nothing like that has ever found its way into the Linux kernel. There is a posix_spawn() function, but that is implemented in the C library using clone() and execve().
Arguably, part of the problem is that, while the clone()-to-execve() pattern is widespread, the details of what happens between those two calls can vary quite a bit. Some files may need to be closed, signal handling changed, scheduling policies tweaked, environment adjusted, and so on; the specific pattern will be different for every case. posix_spawn() tries to provide a general mechanism to specify these actions but, as can be seen by looking at the function's argument list, it quickly becomes complex.
Io_uring, meanwhile, is primarily thought of as a way of performing operations asynchronously. User space can queue operations in a ring buffer; the kernel consumes that buffer, executes the operations asynchronously, then puts the results into another ring buffer (the "completion ring") as each operation completes. Initially, only basic I/O operations were supported, but the list of operations has grown over the years. At this point, io_uring can be thought of as a sort of alternative system-call interface for Linux that is inherently asynchronous.
An important io_uring feature, for the purposes of implementing something like posix_spawn(), is the ability to create chains of linked operations. When the kernel encounters a chain, it will only initiate the first operation; the next operation in the chain will only run after the first completes. The failure of an operation in a chain will normally cause all remaining operations to be canceled, but a "hard link" between two operations will cause execution to continue regardless of the success of the first of the two. Linking operations in this way essentially allows simple programs to be loaded into the kernel for asynchronous execution; these programs can run in parallel with any other io_uring operations that have been submitted.
The new patch set creates two new io_uring operations, each with some special semantics. The first of those is IORING_OP_CLONE, which causes the creation of a new process to execute any operations that follow in the same chain. In a difference from a full clone() call, though, much of the calling task's context is unavailable to the process created by IORING_OP_CLONE. Without that context, io_uring operations in the newly created process can no longer be asynchronous; every operation in the chain must complete immediately, or the chain will fail. In practice, that means that operations like closing files can be executed, but complicated I/O operations are no longer possible. Krisman hopes to be able to at least partially lift that constraint in the future.
Once the chain completes, the new process will be terminated, with one important exception: if it invokes the second new operation, IORING_OP_EXEC, which performs the equivalent of an execveat() call, replacing the running program with a new executable. At this point, the new process is completely detached from the original, is running its own program, and the processing of the io_uring chain is complete; the process will, rather than being terminated, go off to run the new program. Placing any other operations after IORING_OP_EXEC in the chain usually makes no sense; any operations after a successful IORING_OP_EXEC will be canceled. It also does not make sense to use IORING_OP_EXEC in any context other than a new process created with IORING_OP_CLONE, so that usage is not allowed.
There is one case where it can be useful to link operations into the chain after IORING_OP_EXEC — efficiently implementing a path search in the kernel. Often, the execution of a new program involves searching for it in a number of directories, usually specified by the PATH environment variable. One way of doing this in the io_uring context, as shown in this test program, is to enqueue a series of IORING_OP_EXEC operations, each trying a different location in the path. If hard links are used to chain these operations, execution will continue past failed operations until the one that actually finds the target program succeeds; after that, any subsequent operations will be discarded. The entire search runs in the kernel, without the need to repeatedly switch between kernel and user space.
Most of the comments on the proposal so far have come from Pavel Begunkov,
who has expressed
some concerns about it. He did not like some aspects of the
implementation, the special quirks associated with IORING_OP_CLONE
and the process it creates, and the use of links, "which already a bad
sign for a bunch of reasons
" (he did not specify what the reasons
are). He suggested that io_uring might not be the best place for this
functionality; perhaps a list of operations could be passed to a future
version of clone() instead, mirroring how the
posix_spawn() interface works.
Krisman answered that combining everything into a single system call would add complexity while making the solution less flexible. Io_uring makes it easy to put together a set of operations to be run in the kernel in an arbitrary order. The hope is to increase the set of possible operations over time, enabling the implementation of complex logic for the spawning of a new task. It is hard to see how combining all of this functionality into a single system call could work as well.
In any case, this is early-stage work; getting it to a point where it can be considered for the mainline will require smoothing a number of the rough edges and reducing the number of limitations. It will also certainly require wider review; this work is proposing a significant addition to the kernel's user-space ABI that would have to be supported indefinitely. The developers involved will surely want to get the details right before committing to that support.
Systemd improves image features and adds varlink API
The systemd v257 release brings a number of incremental enhancements to various components and utilities for working with Linux systems. This includes more support for varlink, automated downloading of disk images at boot time, and a number of improvements to the secure-boot process for unified kernel images (UKIs), which we have covered in a separate article.
Lennart Poettering announced the release The release was announced on
December 10 to the systemd-devel mailing list, and Lennart Poettering followed up
with a blog
post that linked to his Mastodon threads about new features in
v257.
varlink
One of the interesting changes in systemd v257 is the project leaning into varlink. Poettering has been championing the varlink inter-process communication (IPC) protocol as an alternative to D-Bus for some time. (LWN covered varlink in 2018, shortly after its announcement.) At the All Systems Go! (ASG) conference in September, he delivered a "Varlink Now!" presentation to explain why systemd is adopting it heavily, and to make the case for other software to adopt it as well. (A video of the talk is available, as are the slides.)
One of the primary problems with D-Bus, at least from the systemd perspective, is that it is not available until late in the boot process—too late for many things systemd needs to do. Poettering also said that it is easier to write varlink services than D-Bus services, because a varlink service can handle each connection in a separate process:
To give one example, "bootctl" is a small tool that installs the systemd-boot boot loader into the ESP for you. It's a command line tool that synchronously copies a bunch of files into the target mount. We always had the plan to turn that into a D-Bus service, but never actually did it, because doing that is pain: we'd have to turn it into an event loop driven thing, which is just nasty for something so simple that just copies some files.
In the slides from ASG he also refers to its security model as
"garbage
", and says that D-Bus cannot be used for many basic
IPC services since D-Bus itself uses them (causing a cyclic loop). On
Mastodon he provided
the example of journald providing logging to the D-Bus broker
and being unable to provide APIs via D-Bus.
He said
in November that systemd had tended to use varlink "where D-Bus was
just too bad to use, and only internally
". That has changed in
recent releases of systemd—as of v257 it now has 19
varlink interfaces or services, but only 11 D-Bus API
services. In v257 the varlink API has been added to libsystemd
as sd-varlink,
a public JSON API to help in implementing varlink clients and
services. (The API existed in systemd prior to v257, but was not
exposed as a public API.) It also brings
along a "companion API
" called sd-json, which is a C
library for JSON. There are many of those, so why another? Poettering
said:
My answer to that is that sd-json is much nicer to use than most, since it doesn't just allow you deal with JSON objects, it also helps you with building them from C data structures, and to map JSON objects back to C data structures.
Poettering noted
that one might say that documentation for sd-json and
sd-varlink is "barely existing
", but there are
examples of using them within the systemd source tree.
The systemd-machined service for registering and tracking virtual machines has also gained a set of varlink APIs, as an alternative to the D-Bus interface. The project has also beefed up the varlinkctl utility that is used to introspect and invoke varlink services.
For example, varlinkctl has gained a --timeout= option to allow the user to specify how long it should wait to invoke a service. Users can now invoke services with systemd over SSH by using ssh-exec: to specify the host to connect with. This command, adapted from the varlinkctl man page example, will get a report from the varlink service about the identity of a remote host using ssh-exec::
$ varlinkctl call ssh-exec:host.example.com:/usr/bin/systemd-creds \
org.varlink.service.GetInfo '{}'
This could be useful for administrators who want to make a quick change on a remote system without the need to log in first.
Working with system images
Image-based Linux systems are increasingly popular. In the last year or so we've looked at quite a few image-based distributions, including Aeon, Bluefin, Endless OS, and Vanilla OS. As various projects look to image-based deployment as a way to simplify building, deploying, and updating Linux systems, systemd adds a few tools especially for these types of distributions.
Systemd has been able to use system extension (sysext) images to add software to so-called immutable systems by layering on an image at runtime without making permanent changes to the base image. LWN's report from the 2024 Image-Based Linux Summit discusses recent developments with Flatcar Linux and sysext. Even though sysext is primarily aimed at image-based distributions, it can be used with traditional Linux distributions as well. For example, early testing instructions for the COSMIC Desktop recommended using a sysext to try out COSMIC without making permanent changes to a system.
A new tool, systemd-import-generator makes it possible to specify an image URL on the kernel command line, so that systemd will automatically download the various images at boot using the systemd-importd service. It is not limited to sysexts or image-based systems, however. It can also be used to download configuration extension (confex) images, container images to be run with systemd-nspawn, or virtual machine images for systemd-vmspawn.
The systemd-sysupdate tools have also been improved in v257. Poettering said that the Sovereign Tech Fund (STF) had sponsored work as part of the GNOME STF grant to improve user-controllable update functionality. The result of that work is an experimental D-Bus API for systemd-sysupdate that allows unprivileged clients to update the system using the updatectl command-line tool. For example, "updatectl list host" would show the user which updates are available, while "updatectl update host --reboot" would perform the update and then reboot after the image is staged. The --offline option will tell it to only list image versions on the local system, not those available via the network.
Administration and user improvements
One of the perpetual problems in system configuration is when two (or more) tools make changes to the same settings. For instance, if parameters for network devices are set in /etc/sysctl.d to be configured by systemd-sysctl and then later tweaked by systemd-networkd, that may result in conflicting settings with the most recent change winning.
To help avoid this, systemd-networkd now loads an eBPF program into the kernel to report any changes to sysctls on devices that it is managing. It does not prevent or revert those changes, but running "networkctl status" will display a log of any conflicts to help users and administrators troubleshoot conflicts.
The systemd-inhibit command is used to prevent the system from being shut down or going to sleep while a command is running. This can be useful, for example, to prevent a system going to sleep while running an operation to copy files to an external disk or remote server. It can be frustrating to start a long-running task, step away from the computer for the night, and return to find that it took a nap while it was supposed to be working. In v257, the utility gained a new feature to use polkit to perform interactive authentication for privileged operations like inhibiting shutdown, though that can be disabled with the --no-ask-password option.
Systemd can restart services it manages when they terminate unexpectedly if the service file has the Restart= directive configured. Usually, if a service starts terminating unexpectedly, it means that there's debugging to be done. The RestartMode= setting now has a new value, debug, to make that easier.
If RestartMode=debug is set, systemd will restart the service and raise its log level to "debug" so that it's easier to troubleshoot. Systemd will also set an environment variable, DEBUG_INVOCATION=1 for the service so that the service can be aware it was restarted in debug mode after a failure. Poettering encourages system-service developers to consider supporting the new debug variable.
/etc/os-release
Many Linux users are familiar with the /etc/os-release file that provides information about the distribution and version that their system is running. Fewer are aware that this is, in Poettering's words, a "systemd-ism". In v257, the project is adding three additional fields to os-release, RELEASE_TYPE, EXPERIMENT, and EXPERIMENT_URL.
The RELEASE_TYPE describes whether a release is stable, in development (e.g., a beta release), a long-term-support (LTS) release, or an experimental release. The experimental type is for releases without an expected stable release, such as distribution builds produced to test specific components. The EXPERIMENT field can contain a description of what makes the build experimental, with the EXPERIMENT_URL field to provide a link to more information about the build experimental.
Readers may remember that RELEASE_TYPE popped up in a recent Debian disagreement. Systemd contributor Luca Boccassi wanted to use RELEASE_TYPE=pre-release for Debian testing releases, but did not succeed in persuading the stakeholders or the Debian Technical Committee in making the change.
Removed or deprecated
The next systemd release will completely remove support for version 1 control groups (cgroups). This may sound familiar to those who have been reading the systemd release notes—systemd v256 introduced a requirement to use a kernel command-line option to re-enable cgroup v1 support. In systemd v258 support for "legacy" and "hybrid" cgroup hierarchies will be entirely removed.
The systemd project has set its recommended baseline kernel to Linux 5.4, which is an LTS release from 2019. The 5.4 kernel has a projected end-of-life date of December 2025. This doesn't mean that systemd will not work on older kernels, but users should not expect testing for releases older than that.
In bad news for users still depending on System V (SysV) service scripts, support for those scripts is deprecated and will be removed in v258. Poettering published a blog post in 2010 on how to convert SysV init scripts into service files.
systemctl summary
One thing to watch is whether systemd's emphasis on varlink in this release influences other projects to adopt it as an alternative or in addition to D-Bus. It may be that systemd's pain points are unique to its use case. Overall, this release is a solid update. It is full of minor enhancements across all of the parts of a Linux system that systemd touches—which is most of them, at this point.
The milestones tracker for v258 shows fixes and features that may be coming in the next release. At the moment, most of the issues tracked seem to be minor enhancements and bug fixes, but a few exciting features may sneak in before the next release.
Systemd takes steps toward a more secure boot process
The systemd project has been working for some time on promoting unified kernel images (UKIs), a format that bundles a kernel, initial disk image, kernel command line, and other associated data into a single file. The advantage of the format is the ability to authenticate the entire collection with secure boot, which makes it easier for end users to know that their operating system hasn't been tampered with. The downside is the lack of flexibility and increase in disk usage, since all of the things packaged in a UKI must be updated together. But the recent systemd 257 release (along with other changes to be covered in a future article) includes some major changes to the UKI format, and the rest of the boot process, that partially mitigate those downsides. The release also includes improvements for hardware-locked disk encryption, which may also help secure some computers.
Unified kernel images
Perhaps the most onerous limitation of the UKI format was that, since it includes the kernel command line, there was no good way to modify the command-line parameters during boot. This made debugging boot problems painful, but it also meant that distributions that wanted to provide multiple boot options for each kernel (such as one for a recovery shell) needed to provide multiple UKIs, needlessly duplicating the kernel. Despite the downsides, including the command line in a UKI does have security benefits — there are command-line options that disable many of the kernel's security-hardening options, or that may leave the kernel open to attack in other ways.
The recent systemd release solves this problem by using "profiles" that allow for multiple versions of a component to be packaged in the same UKI and selected at boot time. This helps reduce the number of different UKIs needed by a system, while still allowing for secure boot to validate the entire image, including command-line options. Systemd had already allowed for UEFI "add-ons" — additional files verified by secure boot and stored on the EFI partition — that could be used to add to the kernel command line, but having proper support in the UKI format itself is a welcome change. Add-ons are not going to become completely obsolete, however. Their primary use going forward is likely to be providing microcode updates, which usually have a different lifecycle than the kernel.
Another important component of UKIs are devicetrees. These are used on a few architectures to tell the kernel what hardware is present, and how to configure different drivers to support it. Devicetrees have been an optional component of UKIs for some time, but the new version now allows for multiple devicetree files to be packaged in a single image. These can be selected by profiles, but can also be automatically selected based on the IDs of available hardware.
Some devices' firmware actually provides its own devicetree information. The changes to the UKI format also allow shipping devicetrees that can be matched with the devicetrees provided by the hardware, so that one UKI is potentially usable across devices with different hardware. The devicetree in the UKI doesn't have to be identical to the one provided by the firmware, so developers could potentially use this mechanism to provide a patched devicetree if the one provided by the firmware is unsuitable.
To support these changes to the format, there have also been some changes to systemd's tooling. For example, ukify now supports adding new sections onto existing UKIs, in order to help build multi-profile UKIs. bootctl can also now report more information about how exactly the system booted, including reporting any add-ons used.
bootctl also makes it easier to use one's own secure-boot signing keys by setting up a secure-boot database to be automatically installed on first boot of an image. There are a handful of related changes to systemd's security tooling, such as the ability to use OpenSSL providers (including ones that require user interaction to unlock private keys) in more places.
Combined TPM policies
The bigger security news in this update is probably improvements to the ways that systemd can use a system's trusted platform module (TPM) for disk encryption. systemd-cryptenroll is the tool for adding hardware security tokens and devices to a LUKS2 encrypted volume. For a while now, it has supported using TPMs to lock the keys for an encrypted disk. Specifically, TPMs can use platform configuration registers (PCRs) to store secrets that are only released when the computer is running a particular, trusted piece of software. The Linux PCR registry lists what each PCR is used for. The first eight are used by the computer's firmware, with later entries used by bootloaders and the kernel. Generally keys are locked to every step in the boot process — for example, requiring the firmware to attest that it used secure boot, requiring the boot loader to report the hash of the image it loaded, etc.
Depending on how the user configured things, the TPM PCRs could be used either to lock a disk-encryption key to only be used on kernels signed by a particular OS vendor, or to lock a disk-encryption key to specific local things, such as the firmware version, available hardware, etc. Now, with systemd 257, the user can configure both these kinds of requirements at once. In his description of the feature on Mastodon, Lennart Poettering said:
It is my intention to make this good enough so that distributions eventually can default to enable this, and finally provide boot security that is closer to what outside of traditional Linux is the state of the art.
The feature is not without flaws, however. TPMs don't have a native way to combine the two different kinds of policy. So the system uses two separate keys that are each protected by different policies in the TPM, and then concatenates them to form the disk-encryption key. Theoretically, an attacker with hardware access could boot once with the correct OS (but incorrect hardware or firmware, such as adding a debugging device to dump the key once the TPM reveals it), and once with the correct hardware but a corrupted OS, and then combine the two keys to unlock the device. Still, when properly configured, this feature could make it more difficult for attackers to compromise disk encryption.
Of course, encrypting a computer's disk with a key held in the TPM is not always a reasonable choice, depending on one's threat model. Poettering imagines TPM-linked disk encryption primarily being used to secure the disk on which the operating system is installed, especially on unattended servers that may not have a good way to ask for passphrases. User data would be encrypted with a separate key instead of, or in addition to, the key held in the TPM. There are existing solutions to allow disk-encryption secrets to be provided over the network during early boot, but they may not be suitable for everyone. There are many different kinds of computers that run systemd, with quite different security needs. Having additional flexibility could allow users to tailor a setup to their needs.
In that spirit, the update also includes improvements to the use of FIDO hardware tokens. Systemd's crypttab file now has options for the use of hardware tokens, and systemd-cryptenroll has options for listing which available hardware tokens can be used with a given block device, to make the setup easier.
Overall, the systemd project has been pushing toward a vision of being able to comprehensively secure the boot process of Linux systems. This effort has not been entirely without problems — especially because there is often a tradeoff between security, simplicity, and usability — but now that the worst problems of the UKI format have been ameliorated, we may soon see more distributions making use of it.
Tim Peters returns to the Python community
In the past, suspensions of Python core developers have effectively been permanent because the recipients of the punishment chose not to return. Things have played out quite differently after Tim Peters was suspended for three months back in August; Peters has been posting to the Python discussion forum since his suspension ended in early November and, generally, getting back to work as usual. That does not mean that he—or others in the community—have accepted the way he was treated, but he has largely made his peace with it. The incident is still reverberating through the Python world, however.
Back
On November 1, Peters posted
in the thread that announced his suspension, noting that his "ban is history now
" and that he
did not plan to post further about the ban in that topic; "I'll pick
over its bones in my blog instead.
" He did link to an apology of sorts on
his blog, though in another post
said that the "mea culpa" does not "apologize for claimed violations I
also find baseless
".
The violations that he refers to show up in the announcement
of his suspension by the steering council (SC); it is a list of ten
items specifying "repeated violations of the following behaviors
expected by the Code of Conduct
". That list is controversial, at best;
so far, no real evidence for, or defense of, most or all of those claimed
violations has been offered. While Peters said that he had changed his posting style in
light of the suspension, that list still clearly sticks in his craw:
Instead I've totally changed my posting style, which I agree was taken far too often in unintended ways, which I was oblivious to for reasons explained there.So I too think the ban had some good outcomes. But they could have been achieved far more easily with far less community-damaging drama, and with no broadcasting of shrill, demonizing defamations. Those were raw assertions, with no links to supporting evidence at all. Like it or not, "just trust us" is broken now for a much larger share of the community.
During the suspension, especially right after it, there was quite a bit of discussion in the announcement thread, much of it centered around requests to clarify or explain the list of "charges". The SC as a whole has never commented on those requests or the uproar around the suspension in general, though some individual members have posted thoughts in that thread along the way, including Gregory P. Smith (twice) and Emily Morehouse, who was quoted in our earlier article. But things soon died down.
On October 1, the topic was raised again when Ethan Furman posted
a link to a blog post from
Peters that set out "to eliminate the 'information asymmetry' that
usually accompanies a ban, by disclosing my interactions with PSF [Python Software Foundation]
representatives in full
". It paints a damning picture of the actions
of various bodies, though it is
obviously one-sided. The facts it lays out are seemingly not in dispute—or
at least have not been disputed publicly—and indicate that the Code
of Conduct Work Group (CoC WG) may not have even followed its own procedures.
From what Peters says on that page, the only contact he had during the
entire process leading up to his ban was a single message from the SC,
which Morehouse also mentioned in her post; "we did discuss this
directly with the person first as an initial corrective measure where the
feedback was not received and no willingness to listen or improve was
indicated (in fact, doubling down on issues we were trying to address
occurred)
". As might be guessed, Peters has a significantly different
take on what was said, though he does admit to being dismissive of that
message, in part because the specific example given "didn't pass a
'reasonable person' test to me
". He will not release the email
exchange without SC permission, but he claims that the message was fairly
vague other than the one example:
Without specificity, the best I could make of it was "we're not objecting to what you're saying, we're objecting to who you are - become someone different, in ways you must already know we have in mind". It left both sides unmoved, but they didn't reply to my reply, so there was no "discussion". It was a one-time exchange of monologues.
Unsurprisingly, Furman's post led to more outcry, some of which was flagged by readers, thus hidden by the Discourse forum software until moderators could change that status if it is warranted. The volume of complaints caused the thread to automatically be shut down for four hours on two occasions as well. When he returned, Peters posted in the thread and encouraged others to politely do so as well; when the topic of his ban came up in other threads, he tried to head them off and suggest that the discussion stay in that one thread.
Changing CoC enforcement
One of those other threads was started on November 21 by Marc-André Lemburg to discuss moving enforcement of the CoC away from the SC. It is an idea that he raised in the thread on Furman's call for a vote of no confidence in the SC back in August. Two SC members, Pablo Galindo Salgado and Barry Warsaw, seemed favorably inclined toward the idea. The SC is only involved in enforcement for core developers; the CoC WG and PSF board do that work for other members of the Python community. As part of his note, Warsaw revealed that he had abstained from the vote on the suspension, in part because he did not feel he could be unbiased; similarly, CoC WG members Brett Cannon and Łukasz Langa abstained from the vote to recommend the suspension to the SC.
Lemburg's proposal to change PEP 13 ("Python Language
Governance") would make a few small changes to clearly move CoC enforcement
away from the SC. What it did not do, however, was to indicate who would
be in charge of CoC enforcement for core developers instead, which many saw as a fatal flaw. Lemburg acknowledged
that problem and shortly thereafter put
the proposal on hold "until we have fleshed out a better proposal to fill in the gap that is created by removing the CoC responsibility from the SC
".
As might be guessed, though, Peters's suspension came up in that thread.
Langa suggested
that the proposal was solely in reaction to the suspension of Peters,
though Mark Hammond pointed
out that he (and likely others) are responding to a few different
incidents over the past six months or so. In response to Langa's
suggestion that "if you feel this decision was incorrect, we should
definitely discuss
", Hammond's reply sums up some of the frustration
that is being felt:
Haven't people been trying to do that? People tried to discuss them but were told there was "information asymmetry", that information individuals were "personally privy" to and respecting the privacy of impacted individuals mean we can't know the full story and we should just trust the [process]. But when other parties shared their side of this asymmetry, directly contradicted the small amount of information which was released and gave their permission to have an open discussion, the response has been either silence or more stonewalling.So yes, we should continue to discuss this - but in my opinion, the onus is now on the SC to directly address some of the responses made by these individuals.
SC member Thomas Wouters, who announced the suspension back in August, said
that he did not respond because "having a he-said/he-said fight would in
no way improve the situation
"; beyond that, neither he nor the SC as a
whole were formally asked for a response. Peters wondered
how he could engage in the discussion that Langa offered; he has made lots
of overtures, but has been repeatedly met with silence.
So you can perhaps understand why I find "we should definitely discuss" disingenuous too. If "we" means PSF representatives, they certainly appear to be utterly determined to never clarify anything about my case.
Smith replied
to Hammond and to
Peters, saying that the SC replying either publicly or to Peters
directly "would be a waste of our precious volunteer time as it was
guaranteed to be taken out of context and satisfy nobody
". Thus
silence:
Silence because it was very clear that many people in the space were not up for a discussion. They had already made up their minds and were just looking for a fight. Repeating many of the same problems that led to the situation in the first place.The only winning move was not to reply.
After a request from Alex Gaynor to take the specific circumstances of the suspension to a more appropriate thread, Peters took the topic to the thread where he had been trying to concentrate the discussion of his ban. Unlike the thread about removing CoC enforcement from the duties of the SC, the suspension discussion is in the PSF category, where anyone can post to it. That can lead to more contentious threads than those where only core developers can post, so some have said they shy away from posts in that category.
Of course, the conversation continued at some length—and rancor. Eventually, the thread was put into "slow mode" by the moderators so that folks could not post more than once per day. Peters said that his goal is not to argue against his ban at this point, but that there are some larger issues that he is pushing:
The only thing I'm still on about is that list of specific claimed "CoC violations". They appear nearly wholly without merit to me, are widely (in & out of PSF members) disbelieved by many, and will follow me the rest of my life. That's wrong, in so many ways, and the processes that let it come to this are dead broken on the face of it. They need to change, not particularly for my sake, but for the future health of this fracturing community.
Langa, who chairs the CoC WG, said
that he had received a request from Peters on November 4 to redact or revise the
list of violations, but the group had not yet had time to consider it.
The next meeting was scheduled for December 6; "We will discuss it, I
doubt it will be controversial. It just takes time.
" At the time of
this writing, the list remains in place in the SC announcement; in truth,
that list has now been quoted, in full or in part, in lots of other places,
including other Python forum posts. That toothpaste is not going back into the
tube.
To work
Since his return, Peters has been busy in other ways too. He proposed
a change to Python syntax in the Ideas category; it would
allow some simplification for search loops by adding an if_break
to loop constructs to handle the "if found" case. As he noted, it is
"just a 'nice to have'
", but could be fairly easily added if someone
wanted to do so. While it does not look like the idea is going anywhere,
it did spark a lively (and polite) discussion of the feature and some
possible alternatives.
In addition, he has been coordinating an effort to standardize the tie-breaking algorithm for the recently adopted Bloc Score Then Automatic Runoff (STAR) voting mechanism that will be used for SC elections starting in 2025. (Lots more information about STAR and Bloc STAR can be found at STAR Voting, which is run by the Equal Vote Coalition). Smith had suggested considering a different voting mechanism for the SC back in August; the approval-voting method that has been used up through 2024 has a number of shortcomings because voters do not get to fully specify their preferences.
It turns out that Peters had continued participating in Python in the background during his suspension. In the voting-mechanism discussion, Guido van Rossum noted that one of the voting-system experts for Python was currently suspended, but that message was hidden by Discourse for some number of hours due to being flagged as "inappropriate". It was only restored after Langa intervened, though apparently another Discourse moderator chose not to restore it because they felt that Van Rossum was not being a good role model in the post; more details are available from Peters.
After that event, Van Rossum evidently decided to educate himself on voting systems and turned to Peters for a crash course. In addition, Smith posted an approval of Bloc STAR from Peters in the thread where the vote to switch was made. All of that took place during the suspension, so it would seem that it was only Peters's ability to post to Discourse and to commit code to the Python repositories on GitHub that were actually prevented by the ban.
Once Bloc STAR had been approved, Van Rossum wanted to find a provider offering that mechanism. He noted that Python core developer Larry Hastings has a starvote package that tabulates votes, but Hastings said that he is not the right person to run a voting service. Van Rossum also found bettervoting.com, which is run by the Equal Vote Coalition; it provides an AGPLv3-licensed star-server project and a site that hosts simple elections, which might be sufficient for an SC election.
Peters was quick to endorse bettervoting.com as the most likely site for their needs. He went on to run a few test elections and engaged with Hastings and Arend Peter Castelein, who is the production lead at Equal Vote, on a standard for breaking ties in a repeatable fashion. Ties are an unlikely, but possible, outcome of STAR voting, but it is important that voters (and observers) can recreate the results from the set of anonymized ballots.
Moving forward
So Peters is back to doing the kinds of things he has always done in the Python community, which is clearly to the good, and the suspension is largely in his rear-view mirror, but the wider Python community is still completely in the dark about a lot of things. As Peters himself pointed out, though, the prolonged, likely everlasting, silence is a common institutional response to incidents of this sort. One hopes that some lessons have been learned, however, by people on all "sides" and at all levels of the power hierarchy. What seems to be lacking, however, is what the community itself should learn from this incident about CoC enforcement, procedures, and reporting, especially as it relates to core developers. Maybe that will come in time, as well.
Brief items
Kernel development
Kernel release status
The current development kernel is 6.13-rc4, released on December 22. Linus said: "So this definitely is looking a bit smaller than most rc4s, and I expect (and hope) that rc5 will be absolutely tiny because you should all already be relaxing over the xmas holidays. But hey, if somebody is out there keeping the lights on, please do keep testing."
Stable updates: 6.12.6, 6.6.67, 6.1.121, 5.15.175, 5.10.232, and 5.4.288 were released on December 19.
The 6.12.7, 6.6.68, and 6.1.122 updates are in the review process; they are due on December 27.
Quote of the week
It turns out that RCU has no fewer than 11 ways to wait for a grace period, a fact that would have shocked my year-2000 self. But here we are.— Paul McKenney
Distributions
Fedora Linux 41 election results
The Fedora Project has announced the results of the Fedora Linux 41 election cycle. Five seats were open on the Fedora Engineering Steering Committee (FESCo), and the winners are Kevin Fenzi, Zbigniew Jędrzejewski-Szmek, David Cantrell, Tomáš Hrčka, and Fabio Alessandro Locati. One seat was open on the Mindshare Committee and that went to Luis Bazan as the only eligible candidate nominated in this period.
Grml 2024.12 released
Version 2024.12 of the Debian-based Grml live Linux system for system administrators has been released. Grml 2024.12 uses packages from the upcoming Debian 13 ("trixie") release. It drops support for 32-bit x86 PCs and gains support for 64-bit ARM CPUs. See the release notes for a full list of changes and new features.
Distributions quote of the week
Debian is not a distribution that says "whatever upstream does is always right". We have Debian Policy for a reason, and part of the point of a distribution is to ensure packages meet that policy, providing uniform behavior for sysadmins.
Development
Stenberg: Dropping hyper
Curl maintainer Daniel Stenberg announces that the curl project will be dropping hyper, its experimental HTTP backend written in Rust, due to lack of developer interest.
While the experiment itself is deemed a failure, I think we learned from it and improved curl in the process. We had to rethink and reassess several implementation details when we aligned HTTP behavior with hyper. libcurl parses and handles HTTP stricter now. Better.
Darktable 5.0.0 released
Version 5.0.0 of the darktable photography workflow application has been released. Major changes in this release include user-interface/user-experience (UI/UX) improvements, speed improvements for bulk operations, and the addition of a inter-script-communication event to allow a running script to send messages to another running script. LWN last looked at darktable in 2022.
Fish shell announces 4.0 beta release
fish is a shell with a custom language and several affordances not available out of the box in other shells, such as directory-sensitive command completion. Although the project does not normally make beta releases, the newly announced 4.0b1 release will have one in order to ensure that no problems were introduced after a major effort to switch the code base from C++ to Rust.
fish is a smart and user-friendly command line shell with clever features that just work, without needing an advanced degree in bash scriptology. Today we are announcing an open beta, inviting all users to try out the upcoming 4.0 release.
fish 4.0 is a big upgrade. It's got lots of new features to make using the command line easier and more enjoyable, such as more natural key binding and expanded history search. And under the hood, we've rebuilt the foundation in Rust to embrace modern computing.
Development quotes of the week
We, the WordPress community, need to decide if we're ok being led by a single person who controls everything, and might do things we disagree with, or if we want something else. For a project whose tagline is "Democratizing publishing", we've been very low on exactly that: democracy.— Joost de Valk
One fun anecdote is that companies or governments will often say they need months or years to prepare (CLEAN UP) code for open sourcing. Because on the inside, people allow themselves far worse code than they'd prefer to share with the outside world. Open source code often has higher standards, and it is a great mechanism of keeping you on track.— Bert HubertIf you can get away with it of course.
Page editor: Daroc Alden
Announcements
Newsletters
Distributions and system administration
Development
Meeting minutes
Calls for Presentations
CFP Deadlines: December 26, 2024 to February 24, 2025
The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.
| Deadline | Event Dates | Event | Location |
|---|---|---|---|
| December 31 | March 20 | pgDay Paris | Paris, France |
| December 31 | March 18 | Nordic PGDay 2025 | Copenhagen, Denmark |
| January 1 | May 13 May 16 |
PGConf.dev | Montreal, Canada |
| January 8 | March 22 March 23 |
Chemnitz Linux Days 2025 | Chemnitz, Germany |
| January 12 | May 13 May 17 |
RustWeek / RustNL 2025 | Utrecht, The Netherlands |
| January 13 | March 18 March 20 |
Linux Foundation Member Summit | Napa, CA, US |
| January 15 | April 29 April 30 |
stackconf 2025 | Munich, Germany |
| January 17 | March 10 March 14 |
Netdev 0x19 | Zagreb, Croatia |
| January 27 | January 28 | Linaro Forum for Arm Linux Kernel Topics | Virtual , NA |
| February 1 | April 14 April 15 |
foss-north 2025 | Gothenburg, Sweden |
| February 1 | May 8 May 9 |
PostgreSQL Conference Germany | Berlin, Germany |
| February 13 | May 14 May 16 |
Linaro Connect Lisbon 2025 | Lisbon, Portugal |
| February 17 | June 23 June 25 |
Open Source Summit North America | Denver, CO, US |
| February 22 | May 22 | NLUUG Spring Conference 2025 | Utrecht, The Netherlands |
| February 23 | June 15 June 17 |
Berlin Buzzwords | Berlin, Germany |
| February 23 | June 5 June 8 |
Flock to Fedora 2025 | Prague, Czech Republic |
If the CFP deadline for your event does not appear here, please tell us about it.
Upcoming Events
Events: December 26, 2024 to February 24, 2025
The following event listing is taken from the LWN.net Calendar.
| Date(s) | Event | Location |
|---|---|---|
| January 20 January 22 |
Everything Open 2025 | Adelaide, Australia |
| January 28 | Linaro Forum for Arm Linux Kernel Topics | Virtual , NA |
| February 1 February 2 |
FOSDEM | Brussels, Belgium |
| February 4 February 5 |
State of Open Con | London, UK |
If your event does not appear here, please tell us about it.
Security updates
Alert summary December 18, 2024 to December 24, 2024
| Dist. | ID | Release | Package | Date |
|---|---|---|---|---|
| AlmaLinux | ALSA-2024:11216 | 9 | containernetworking-plugins | 2024-12-23 |
| AlmaLinux | ALSA-2024:11185 | 8 | edk2:20220126gitbb1bba3d77 | 2024-12-18 |
| AlmaLinux | ALSA-2024:11219 | 9 | edk2:20240524 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11345 | 8 | gstreamer1-plugins-base | 2024-12-18 |
| AlmaLinux | ALSA-2024:11123 | 9 | gstreamer1-plugins-base | 2024-12-23 |
| AlmaLinux | ALSA-2024:11299 | 8 | gstreamer1-plugins-good | 2024-12-18 |
| AlmaLinux | ALSA-2024:11122 | 9 | gstreamer1-plugins-good | 2024-12-23 |
| AlmaLinux | ALSA-2024:10943 | 8 | kernel | 2024-12-18 |
| AlmaLinux | ALSA-2024:10939 | 9 | kernel | 2024-12-23 |
| AlmaLinux | ALSA-2024:10944 | 8 | kernel-rt | 2024-12-18 |
| AlmaLinux | ALSA-2024:11237 | 9 | libsndfile:1.0.31 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11193 | 8 | mpg123 | 2024-12-18 |
| AlmaLinux | ALSA-2024:11242 | 9 | mpg123:1.32.9 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11250 | 9 | pam | 2024-12-23 |
| AlmaLinux | ALSA-2024:10950 | 9 | php:8.1 | 2024-12-23 |
| AlmaLinux | ALSA-2024:10951 | 8 | php:8.2 | 2024-12-18 |
| AlmaLinux | ALSA-2024:10949 | 9 | php:8.2 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11111 | 9 | python3.11 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11189 | 8 | python3.11-urllib3 | 2024-12-18 |
| AlmaLinux | ALSA-2024:11238 | 9 | python3.11-urllib3 | 2024-12-23 |
| AlmaLinux | ALSA-2024:10978 | 9 | python3.12 | 2024-12-23 |
| AlmaLinux | ALSA-2024:10983 | 9 | python3.9:3.9.21 | 2024-12-23 |
| AlmaLinux | ALSA-2024:11217 | 9 | skopeo | 2024-12-23 |
| AlmaLinux | ALSA-2024:11161 | 8 | tuned | 2024-12-18 |
| AlmaLinux | ALSA-2024:11232 | 9 | unbound:1.16.2 | 2024-12-23 |
| Debian | DSA-5834-1 | stable | chromium | 2024-12-20 |
| Debian | DLA-3999-1 | LTS | gst-plugins-base1.0 | 2024-12-21 |
| Debian | DLA-3996-1 | LTS | gunicorn | 2024-12-20 |
| Debian | DLA-4002-1 | LTS | intel-microcode | 2024-12-23 |
| Debian | DLA-4001-1 | LTS | libxstream-java | 2024-12-21 |
| Debian | DLA-3997-1 | LTS | php-laravel-framework | 2024-12-21 |
| Debian | DLA-3998-1 | LTS | python-urllib3 | 2024-12-21 |
| Debian | DLA-4000-1 | LTS | sqlparse | 2024-12-21 |
| Fedora | FEDORA-2024-dd633679a9 | F40 | ColPack | 2024-12-19 |
| Fedora | FEDORA-2024-d6b79ab292 | F41 | ColPack | 2024-12-19 |
| Fedora | FEDORA-2024-4808dce926 | F40 | chromium | 2024-12-22 |
| Fedora | FEDORA-2024-21c7531146 | F41 | chromium | 2024-12-22 |
| Fedora | FEDORA-2024-846e191001 | F41 | glibc | 2024-12-19 |
| Fedora | FEDORA-2024-40d4ab1c94 | F41 | golang-github-chainguard-dev-git-urls | 2024-12-19 |
| Fedora | FEDORA-2024-40d4ab1c94 | F41 | golang-github-task | 2024-12-19 |
| Fedora | FEDORA-2024-7f67755963 | F40 | icecat | 2024-12-19 |
| Fedora | FEDORA-2024-ff0115e6ac | F41 | icecat | 2024-12-19 |
| Fedora | FEDORA-2024-cd98f29570 | F40 | jupyterlab | 2024-12-20 |
| Fedora | FEDORA-2024-0c952fc516 | F41 | jupyterlab | 2024-12-20 |
| Fedora | FEDORA-2024-3c18fe0d93 | F41 | libcomps | 2024-12-22 |
| Fedora | FEDORA-2024-3c18fe0d93 | F41 | libdnf | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-directxmath | 2024-12-22 |
| Fedora | FEDORA-2024-0a5722a980 | F41 | mingw-directxmath | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-gstreamer1 | 2024-12-22 |
| Fedora | FEDORA-2024-0a5722a980 | F41 | mingw-gstreamer1 | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-gstreamer1-plugins-bad-free | 2024-12-22 |
| Fedora | FEDORA-2024-0a5722a980 | F41 | mingw-gstreamer1-plugins-bad-free | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-gstreamer1-plugins-base | 2024-12-22 |
| Fedora | FEDORA-2024-0a5722a980 | F41 | mingw-gstreamer1-plugins-base | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-gstreamer1-plugins-good | 2024-12-22 |
| Fedora | FEDORA-2024-0a5722a980 | F41 | mingw-gstreamer1-plugins-good | 2024-12-22 |
| Fedora | FEDORA-2024-2284729772 | F40 | mingw-orc | 2024-12-22 |
| Fedora | FEDORA-2024-0051a464f1 | F41 | ofono | 2024-12-21 |
| Fedora | FEDORA-2024-f2a4ffc1ff | F40 | prometheus-podman-exporter | 2024-12-23 |
| Fedora | FEDORA-2024-8d1b3f4466 | F41 | prometheus-podman-exporter | 2024-12-23 |
| Fedora | FEDORA-2024-d32fd0e2d1 | F40 | python-nbdime | 2024-12-19 |
| Fedora | FEDORA-2024-01e170c1ac | F41 | python-nbdime | 2024-12-19 |
| Fedora | FEDORA-2024-82a696ca59 | F40 | python3-docs | 2024-12-24 |
| Fedora | FEDORA-2024-3c18fe0d93 | F41 | python3-docs | 2024-12-22 |
| Fedora | FEDORA-2024-82a696ca59 | F40 | python3.12 | 2024-12-24 |
| Fedora | FEDORA-2024-be6ea1ce44 | F40 | python3.13 | 2024-12-19 |
| Fedora | FEDORA-2024-3c18fe0d93 | F41 | python3.13 | 2024-12-22 |
| Fedora | FEDORA-2024-54aa5fc4b2 | F41 | python3.14 | 2024-12-19 |
| Fedora | FEDORA-2024-32bc143584 | F41 | webkitgtk | 2024-12-21 |
| Mageia | MGASA-2024-0397 | 9 | emacs | 2024-12-24 |
| Mageia | MGASA-2024-0392 | 9 | kernel, kmod-xtables-addons, kmod-virtualbox, dwarves | 2024-12-18 |
| Mageia | MGASA-2024-0393 | 9 | kernel-linus | 2024-12-18 |
| Mageia | MGASA-2024-0396 | 9 | mozjs78 | 2024-12-21 |
| Mageia | MGASA-2024-0395 | 9 | thunderbird | 2024-12-21 |
| Mageia | MGASA-2024-0394 | 9 | tomcat, tomcat packages | 2024-12-21 |
| Oracle | ELSA-2024-11154 | OL8 | bluez | 2024-12-19 |
| Oracle | ELSA-2024-11216 | OL9 | containernetworking-plugins | 2024-12-20 |
| Oracle | ELSA-2024-11185 | OL8 | edk2:20220126gitbb1bba3d77 | 2024-12-19 |
| Oracle | ELSA-2024-11219 | OL9 | edk2:20240524 | 2024-12-20 |
| Oracle | ELSA-2024-11345 | OL8 | gstreamer1-plugins-base | 2024-12-19 |
| Oracle | ELSA-2024-11299 | OL8 | gstreamer1-plugins-good | 2024-12-19 |
| Oracle | ELSA-2024-12887 | OL8 | kernel | 2024-12-19 |
| Oracle | ELSA-2024-12887 | OL9 | kernel | 2024-12-19 |
| Oracle | ELSA-2024-12887 | OL9 | kernel | 2024-12-19 |
| Oracle | ELSA-2024-11192 | OL8 | libsndfile | 2024-12-19 |
| Oracle | ELSA-2024-11237 | OL9 | libsndfile:1.0.31 | 2024-12-20 |
| Oracle | ELSA-2024-11193 | OL8 | mpg123 | 2024-12-19 |
| Oracle | ELSA-2024-11242 | OL9 | mpg123:1.32.9 | 2024-12-20 |
| Oracle | ELSA-2024-11250 | OL9 | pam | 2024-12-20 |
| Oracle | ELSA-2024-11189 | OL8 | python3.11-urllib3 | 2024-12-19 |
| Oracle | ELSA-2024-11238 | OL9 | python3.11-urllib3 | 2024-12-20 |
| Oracle | ELSA-2024-11217 | OL9 | skopeo | 2024-12-20 |
| Oracle | ELSA-2024-11161 | OL8 | tuned | 2024-12-19 |
| Oracle | ELSA-2024-11232 | OL9 | unbound:1.16.2 | 2024-12-20 |
| Red Hat | RHSA-2024:11345-01 | EL8 | gstreamer1-plugins-base | 2024-12-19 |
| Red Hat | RHSA-2024:11348-01 | EL8.8 | gstreamer1-plugins-good | 2024-12-19 |
| Red Hat | RHSA-2024:9051-01 | EL9 | podman | 2024-12-24 |
| SUSE | SUSE-SU-2024:4407-1 | SLE15 SLE-m5.5 oS15.5 oS15.6 | aalto-xml, flatten-maven-plugin, jctools, moditect, netty, netty-tcnative | 2024-12-23 |
| SUSE | SUSE-SU-2024:4386-1 | SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5 osM5.5 | avahi | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14607-1 | TW | chromedriver | 2024-12-22 |
| SUSE | SUSE-SU-2024:3927-2 | SLE12 | curl | 2024-12-19 |
| SUSE | SUSE-SU-2024:4284-2 | SLE12 | curl | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14597-1 | TW | docker | 2024-12-19 |
| SUSE | SUSE-SU-2024:4392-1 | MP4.3 SLE15 oS15.4 oS15.5 oS15.6 | emacs | 2024-12-20 |
| SUSE | openSUSE-SU-2024:14591-1 | TW | emacs | 2024-12-18 |
| SUSE | SUSE-SU-2024:4413-1 | SLE15 SES7.1 | gdb | 2024-12-23 |
| SUSE | SUSE-SU-2024:4414-1 | SLE15 oS15.4 oS15.5 oS15.6 | gdb | 2024-12-23 |
| SUSE | openSUSE-SU-2024:14592-1 | TW | git-bug | 2024-12-18 |
| SUSE | SUSE-SU-2024:4051-2 | SLE12 | glib2 | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14599-1 | TW | govulncheck-vulndb | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14603-1 | TW | govulncheck-vulndb | 2024-12-20 |
| SUSE | openSUSE-SU-2024:14608-1 | TW | govulncheck-vulndb | 2024-12-23 |
| SUSE | SUSE-SU-2024:4400-1 | MP4.3 SLE15 oS15.4 | grpc | 2024-12-20 |
| SUSE | SUSE-SU-2024:4401-1 | SLE15 oS15.6 | grpc | 2024-12-20 |
| SUSE | SUSE-SU-2024:4390-1 | SLE15 oS15.6 | haproxy | 2024-12-20 |
| SUSE | openSUSE-SU-2024:14593-1 | TW | helm | 2024-12-18 |
| SUSE | SUSE-SU-2024:4388-1 | MP4.1 SLE15 | kernel | 2024-12-19 |
| SUSE | SUSE-SU-2024:4397-1 | SLE11 | kernel | 2024-12-20 |
| SUSE | SUSE-SU-2024:4387-1 | SLE15 | kernel | 2024-12-19 |
| SUSE | SUSE-SU-2024:4376-1 | SLE15 oS15.5 | kernel | 2024-12-18 |
| SUSE | openSUSE-SU-2024:14600-1 | TW | libmozjs-128-0 | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14609-1 | TW | libparaview5_12 | 2024-12-23 |
| SUSE | SUSE-SU-2024:4411-1 | SLE15 oS15.6 | mozjs115 | 2024-12-23 |
| SUSE | SUSE-SU-2024:4412-1 | SLE15 SLE-m5.5 oS15.4 oS15.5 oS15.6 | mozjs78 | 2024-12-23 |
| SUSE | SUSE-SU-2024:4396-1 | MP4.1 MP4.2 MP4.3 SLE15 oS15.5 | python-aiohttp | 2024-12-20 |
| SUSE | SUSE-SU-2024:4393-1 | SLE15 oS15.6 | python-grpcio | 2024-12-20 |
| SUSE | openSUSE-SU-2024:0412-1 | osB15 | python-python-sql | 2024-12-21 |
| SUSE | openSUSE-SU-2024:0413-1 | osB15 | python-python-sql | 2024-12-21 |
| SUSE | openSUSE-SU-2024:14601-1 | TW | python310-xhtml2pdf | 2024-12-19 |
| SUSE | SUSE-SU-2024:4389-1 | SLE12 | sudo | 2024-12-20 |
| SUSE | openSUSE-SU-2024:14602-1 | TW | tailscale | 2024-12-19 |
| SUSE | openSUSE-SU-2024:14595-1 | TW | traefik2 | 2024-12-18 |
| SUSE | SUSE-SU-2024:4416-1 | SLE15 oS15.6 | vhostmd | 2024-12-24 |
| SUSE | SUSE-SU-2024:4409-1 | SLE12 | vim | 2024-12-23 |
| Ubuntu | USN-7178-1 | 22.04 24.04 24.10 | dpdk | 2024-12-19 |
| Ubuntu | USN-7175-1 | 20.04 22.04 24.04 24.10 | gst-plugins-base1.0 | 2024-12-18 |
| Ubuntu | USN-7176-1 | 20.04 22.04 24.04 24.10 | gst-plugins-good1.0 | 2024-12-18 |
| Ubuntu | USN-7174-1 | 20.04 22.04 24.04 24.10 | gstreamer1.0 | 2024-12-18 |
| Ubuntu | USN-7172-1 | 14.04 | libvpx | 2024-12-18 |
| Ubuntu | USN-7179-1 | 20.04 22.04 | linux, linux-gkeop, linux-ibm, linux-ibm-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle-5.15 | 2024-12-20 |
| Ubuntu | USN-7173-2 | 18.04 20.04 | linux-aws, linux-aws-5.4, linux-bluefield, linux-ibm, linux-ibm-5.4, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp | 2024-12-20 |
| Ubuntu | USN-7169-2 | 24.10 | linux-gcp | 2024-12-18 |
| Ubuntu | USN-7166-3 | 20.04 | linux-hwe-5.15 | 2024-12-20 |
| Ubuntu | USN-7159-4 | 20.04 | linux-iot | 2024-12-20 |
| Ubuntu | USN-7171-1 | 16.04 | phpunit | 2024-12-18 |
| Ubuntu | USN-7177-1 | 22.04 | yara | 2024-12-18 |
Kernel patches of interest
Kernel releases
Architecture-specific
Build system
Core kernel
Development tools
Device drivers
Device-driver infrastructure
Documentation
Filesystems and block layer
Memory management
Networking
Security-related
Virtualization and containers
Miscellaneous
Page editor: Joe Brockmeier