Welcome to the LWN.net Weekly Edition for December 4, 2025

This edition contains the following feature content:

• APT Rust requirement raises questions: how will Debian accommodate Rust in one of its core tools?
• Unpacking for Python comprehensions: a look at PEP 798 ("Unpacking in Comprehensions"), which was accepted in November.
• Zig's new plan for asynchronous programs: allowing Zig code to execute correctly using synchronous or asynchronous I/O.
• BPF and io_uring, two different ways: competing patch sets try to add BPF to io_uring.
• Checked-size array parameters in C: improving the safety of kernel code with an obscure C feature.
• Some 6.18 development statistics: a look at who contributed code and more to the 6.18 kernel.
• Just: a command runner: an alternative to make for running user-defined tasks.

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.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

APT Rust requirement raises questions

It is rarely newsworthy when a project or package picks up a new dependency. However, changes in a core tool like Debian's Advanced Package Tool (APT) can have far-reaching effects. For example, Julian Andres Klode's declaration that APT would require Rust in May 2026 means that a few of Debian's unofficial ports must either acquire a working Rust toolchain or depend on an old version of APT. This has raised several questions within the project, particularly about the ability of a single maintainer to make changes that have widespread impact.

On October 31, Klode sent an announcement to the debian-devel mailing list that he intended to introduce Rust dependencies and code into APT as soon as May 2026:

This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem.

In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.

If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.

Klode added this was necessary so that the project as a whole could move forward, rely on modern technologies, "and not be held back by trying to shoehorn modern software on retro computing devices". Some Debian developers have welcomed the news. Paul Tagliamonte acknowledged that it would impact unofficial Debian ports but called the push toward Rust "welcome news".

However, John Paul Adrian Glaubitz complained that Klode's wording was unpleasant and that the approach was confrontational. In another message, he explained that he was not against adoption of Rust; he had worked on enabling Rust on many of the Debian architectures and helped to fix architecture-specific bugs in the Rust toolchain as well as LLVM upstream. However, the message strongly suggested there was no room for a change in plan: Klode had ended his message with "thank you for understanding", which invited no further discussion. Glaubitz was one of a few Debian developers who expressed discomfort with Klode's communication style in the message.

Klode noted, briefly, that Rust was already a hard requirement for all Debian release architectures and ports, except for Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4), because of APT's use of the Sequoia-PGP project's sqv tool to verify OpenPGP signatures. APT falls back to using the GNU Privacy Guard signature-verification tool, gpgv, on ports that do not have a Rust compiler. By depending directly on Rust, though, APT itself would not be available on ports without a Rust compiler. LWN recently covered the state of Linux architecture support, and the status of Rust support for each one.

None of the ports listed by Klode are among those officially supported by Debian today, or targeted for support in Debian 14 ("forky"). The sh4 port has never been officially supported, and none of the other ports have been supported since Debian 6.0. The actual impact on the ports lacking Rust is also less dramatic than it sounded at first. Glaubitz assured Antoni Boucher that "the ultimatum that Julian set doesn't really exist", but phrasing it that way "gets more attention in the news". Boucher is the maintainer of rust_codegen_gcc, a GCC ahead-of-time code generator for Rust. Nothing, Glaubitz said, stops ports from using a non-Rust version of APT until Boucher and others manage to bootstrap Rust for those ports.

Security theater?

David Kalnischkies, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Klode mentioned from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates, he said, and the only "serious usage" of apt-ftparchive was by Klode's employer, Canonical, for its Launchpad software-collaboration platform. If those were taken out of the main APT code base, then it would not matter whether they were written in Rust, Python, or another language, since the tools are not directly necessary for any given port.

Kalnischkies also questioned the claim that Rust was necessary to achieve the stronger approach to unit testing that Klode mentioned:

You can certainly do unit tests in C++, we do. The main problem is that someone has to write those tests. Like docs.

Your new solver e.g. has none (apart from our preexisting integration tests). You don't seriously claim that is because of C++ ? If you don't like GoogleTest, which is what we currently have, I could suggest doctest (as I did in previous installments). Plenty other frameworks exist with similar or different styles.

Klode has not responded to those comments yet, which is a bit unfortunate given the fact that introducing hard dependencies on Rust has an impact beyond his own work on APT. It may well be that he has good answers to the questions, but it can also give the impression that Klode is simply embracing a trend toward Rust. He is involved in the Ubuntu work to migrate from GNU Coreutils to the Rust-based uutils. The reasons given for that work, again, are around modernization and better security—but security is not automatically guaranteed simply by switching to Rust, and there are a number of other considerations.

For example, Adrian Bunk pointed out that there are a number of Debian teams, as well as tooling, that will be impacted by writing some of APT in Rust. The release notes for Debian 13 ("trixie") mention that Debian's infrastructure "currently has problems with rebuilding packages of types that systematically use static linking", such as those with code written in Go and Rust. Thus, "these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably". Limited security support means that updates to Rust libraries are likely to only be released when Debian publishes a point release, which happens about every two months. The security team has specifically stated that sqv is fully supported, but there are still outstanding problems.

Due to the static-linking issue, any time one of sqv's dependencies, currently more than 40 Rust crates, have to be rebuilt due to a security issue, sqv (at least potentially) also needs to be rebuilt. There are also difficulties in tracking CVEs for all of its dependencies, and understanding when a security vulnerability in a Rust crate may require updating a Rust program that depends on it.

Fabian Grünbichler, a maintainer of Debian's Rust toolchain, listed several outstanding problems Debian has with dealing with Rust packages. One of the largest is the need for a consistent Debian policy for declaring statically linked libraries. In 2022, Guillem Jover added a control field for Debian packages called Static-Built-Using (SBU), which would list the source packages used to build a binary package. This would indicate when a binary package needs to be rebuilt due to an update in another source package. For example, sqv depends on more than 40 Rust crates that are packaged for Debian. Without declaring the SBUs, it may not be clear if sqv needs to be updated when one of its dependencies is updated. Debian has been working on a policy requirement for SBU since April 2024, but it is not yet finished or adopted.

The discussion sparked by Grünbichler makes clear that most of Debian's Rust-related problems are in the process of being solved. However, there's no evidence that Klode explored the problems before declaring that APT would depend on Rust, or even asked "is this a reasonable time frame to introduce this dependency?"

Where tradition meets tomorrow

Debian's tagline, or at least one of its taglines, is "the universal operating system", meaning that the project aims to run on a wide variety of hardware (old and new) and be usable on the desktop, server, IoT devices, and more. The "Why Debian" page lists a number of reasons users and developers should choose the distribution: multiple hardware architectures, long-term support, and its democratic governance structure are just a few of the arguments it puts forward in favor of Debian. It also notes that "Debian cannot be controlled by a single company". A single developer employed by a company to work on Debian tools pushing a change that seems beneficial to that company, without discussion or debate, that impacts multiple hardware architectures and that requires other volunteers to do unplanned work or meet an artificial deadline seems to go against many of the project's stated values.

Debian, of course, does have checks and balances that could be employed if other Debian developers feel it necessary. Someone could, for example, appeal to Debian's Technical Committee, or sponsor a general resolution to override a developer if they cannot be persuaded by discussion alone. That happened recently when the committee required systemd maintainers to provide the /var/lock directory "until a satisfactory migration of impacted software has occurred and Policy updated accordingly".

However, it also seems fair to point out that Debian can move slowly, even glacially, at times. APT added support for the DEB822 format for its source information lists in 2015. Despite APT supporting that format for years, Klode faced resistance in 2021, when he pushed for Debian to move to the new format ahead of the Debian 12 ("bookworm") release in 2021, but was unsuccessful. It is now the default for trixie with the move to APT 3.0, though APT will continue to support the old format for years to come.

The fact is, regardless of what Klode does with APT, more and more free software is being written (or rewritten) in Rust. Making it easier to support that software when it is packaged for Debian is to everyone's benefit. Perhaps the project needs some developers who will be aggressive about pushing the project to move more quickly in improving its support for Rust. However, what is really needed is more developers lending a hand to do the work that is needed to support Rust in Debian and elsewhere, such as gccrs. It does not seem in keeping with Debian's community focus for a single developer to simply declare dependencies that other volunteers will have to scramble to support.

Comments (343 posted)

Unpacking for Python comprehensions

Unpacking Python iterables of various sorts, such as dictionaries or lists, is useful in a number of contexts, including for function arguments, but there has long been a call for extending that capability to comprehensions. PEP 798 ("Unpacking in Comprehensions") was first proposed in June 2025 to fill that gap. In early November, the steering council accepted the PEP, which means that the feature will be coming to Python 3.15 in October 2026. It may be something of a niche feature, but it is an inconsistency that has been apparent for a while—to the point that some Python programmers assume that it is already present in the language.

Unpacking

One of the most common use cases for unpacking is to pass a list or dictionary to a function as a series of its elements rather than as a single object. The "*" unpacking operator (and its companion, "**", for dictionaries) can be used to expand an iterable in that fashion; a simple example might look like the following:

    def foo(a, b):
        a*b

    l = [ 2, 4 ]  # list
    t = ( 3, 5 )  # tuple
    d = { 'a' : 2, 'b' : 9 } # dict
    foo(*l)   # foo(2, 4) == 8
    foo(*t)   # foo(3, 5) == 15
    foo(**d)  # foo(a=2, b=9) == 18

In each case, the unpacking operator extracts the elements of the iterable to turn them into individual arguments to the function—keyword arguments for the dictionary.

Python comprehensions provide a mechanism to build a list or other iterable using a compact syntax, rather than a full loop. A classic example of that appears in the Python documentation linked just above:

    squares = []
    for x in range(10):
        squares.append(x**2)

    # can be replaced with

    squares = [ x**2 for x in range(10) ]

For both of those, the result is a list with the squares of the numbers zero through nine.

The unpacking operator can already be used to create iterables, such as:

    a = [ 1, 2 ]
    b = [ 3, 4 ]
    c = [ *a, *b ]  # [ 1, 2, 3, 4 ]

    # dictionaries can be merged in similar fashion

    newdict = { **d1, **d2, **d3 }

In the latter example, the order of the dictionaries matters, keys that are duplicated will take their value from the last dictionary where they were set (i.e. d3[key] takes precedence over the value for key in d1 or d2).

But what if there is a list of lists with a length that is not known except at run time? Currently, there is no easy way to use a list comprehension to build the flattened list of all of the entries of each list; it can be done using a comprehension with two loops, but that is error prone. There are other possibilities too, as described in the "Motivation" section of the PEP, but all of them suffer from semi-obscurity or complexity. Instead, Python will be allowing unpacking operators in comprehensions:

    # from the PEP
    
    [*it for it in its]  # list with the concatenation of iterables in 'its'
    {*it for it in its}  # set with the union of iterables in 'its'
    {**d for d in dicts} # dict with the combination of dicts in 'dicts'
    (*it for it in its)  # generator of the concatenation of iterables in 'its'

    # a usage example

    a = [ 1, 2 ]
    b = [ 3, 4, 5 ]
    c = [ 6 ]
    its = [ a, b, c ]
    [ *it for it in its ]   #  [ 1, 2, 3, 4, 5, 6 ]

    # current double-loop version

    [ x for it in its for x in it ]  #  [ 1, 2, 3, 4, 5, 6 ]

Discussion

The PEP authors, Adam Hartz and Erik Demaine, actually proposed the idea back in 2021 on the python-ideas mailing list. As noted in that message, though, the idea also came up in 2016 and perhaps even before that. In 2021, the proposal was generally well-received, and reached the pre-PEP stage, but was unable to attract a core developer as a sponsor. In late June, Hartz posted a lengthy pre-PEP message to the ideas category of the Python discussion forum, "hoping to find a sponsor for moving forward with the PEP process if there's still enthusiasm behind this idea".

Hartz noted that the idea had been raised in October 2023, as well, so it is a feature that is frequently brought up—generally to nodding approval. That 2023 message was posted by Alex Prengère, who was quick to reply to the pre-PEP saying that he had been working on unpacking in comprehensions as well. He, along with others, wondered about support for unpacking in asynchronous comprehensions (as described in PEP 530); it was not mentioned in the pre-PEP, but the implementation would allow them, he said. Hartz said that the intent was to support them and that he would update the text to reflect that.

There was also some discussion regarding the syntax for making function calls using a generator comprehension (e.g. f(x for x in it)); there is some ambiguity in the meaning, as Ben Hsing noted. PEP 448 ("Additional Unpacking Generalizations") added the ability to use the unpacking operators in more contexts, including function call arguments, but it explicitly did not extend that to generator comprehensions because it was not clear which meaning should be chosen. As Hsing put it:

That is, which one of these is intended?

    f(*x for x in it) == f((*x for x in it))

or:

    f(*x for x in it) == f(*(x for x in it))

In the thread, Hartz and others argued that, since the language already allows a generator comprehension (without any unpacking operators) as an argument without requiring an extra set of parentheses (e.g. f(x for x in it), the same should be true for those with the unpacking operator. In the reply linked above, Hartz noted that the error message for the syntax error points in that direction as well:

A little bit of support in this direction, perhaps, comes from the way that the syntax error for f(*x for x in it) is reported in 3.13, which suggests that this is interpreted as f(<a single malformed generator expression>) rather than as f(*<something>):

    >>> f(*x for x in its)
      File "<python-input-0>", line 1
        f(*x for x in its)
          ^^
    SyntaxError: iterable unpacking cannot be used in comprehension

The draft PEP continued to be discussed; it was updated a few days after it was first posted, on June 25, and then again on July 3. The latter posting caught the eye of core developer Jelle Zijlstra who said that it "is a nice little feature that I've missed several times in the past" and that he was willing to sponsor it. That started its path into the CPython mainline.

The now-numbered PEP 798 was posted for discussion in the PEPs category of the forum on July 19. Along the way, the PEP had picked up some extra pieces, including a section with examples of where standard library code could be simplified using the feature and an appendix on support in other languages. Most of the comments at that point were about other features that might also be considered, though Hartz and Zijlstra tried to keep things focused on the PEP itself.

One outstanding issue was the treatment of synchronous generator expressions versus the asynchronous variety. The PEP, which will be changing as we will see, currently makes a distinction between the two because "yield from" is not permitted in asynchronous generators. Another appendix goes into more detail; the difference comes down to whether the generator-protocol methods, such as send(), can be used. There are two ways that the semantics of an unpacking generator expression could be defined:

    g = (*x for x in it)

    # could be:

    def gen():
        for x in it:
            yield from x
    g = gen()

    # or:

    def gen():
        for x in it:
            for i in x:
                yield i
    g = gen()

Either of those works for synchronous generators, but:

    g = (*x async for x in ait())

    # must be:

    async def gen()
        async for x in ait():
            for i in x:
                yield i
    g = gen()

So the question is whether it makes sense to define the synchronous semantics differently so that those comprehensions could potentially use the generator-protocol methods. Hartz ran a poll in the thread, with several possibilities for the semantics, but no real consensus was reached—perhaps unsurprising given the esoteric nature of the question and that thread participants had likewise been unable to converge on the semantics.

In mid-September, after more than a month of quiet in the thread, Hartz submitted the PEP to the steering council for consideration. The council started looking at it a month later, with council member Pablo Galindo Salgado noting that the group was uncomfortable with positioning the new syntax "as offering 'much clearer' code compared to existing alternatives (such as itertools.chain.from_iterable, explicit loops, or nested comprehensions)" because readability is in the eye of the beholder. Instead, the council suggested that "the stronger, more objective argument is syntactic consistency as extending Python's existing unpacking patterns naturally into comprehensions". Hartz agreed and adjusted the PEP accordingly.

In the thread, "Nice Zombies" highlighted part of the "Rationale" section of the PEP, which nicely illustrates the argument for syntactic consistency:

This proposal was motivated in part by a written exam in a Python programming class, where several students used the proposed notation (specifically the set version) in their solutions, assuming that it already existed in Python. This suggests that the notation represents a logical, consistent extension to Python's existing syntax. By contrast, the existing double-loop version [x for it in its for x in it] is one that students often get wrong, the natural impulse for many students being to reverse the order of the for clauses.

One of the examples given in the PEP shows how an explicit loop to create a set could be changed in the shutil module of the standard library:

    # current:
    ignored_names = []
    for pattern in patterns:
        ignored_names.extend(fnmatch.filter(names, pattern))
    return set(ignored_names)

    # proposed:
    return {*fnmatch.filter(names, pattern) for pattern in patterns}

Instead of extending the list from the iterable returned by fnmatch.filter(), then converting it to a set, the new syntax allows creating the set directly. The existing code could have taken advantage of set.update() to avoid using the list, but the new syntax is in keeping with the ideas behind comprehensions—and was apparently intuitively obvious, but wrong, to Python students.

In its announcement of the PEP's acceptance, the SC also decided the question about generator comprehensions: "we require that both synchronous and asynchronous generator expressions use explicit loops rather than yield from for unpacking operations". That removes some advanced use cases "that are rarely relevant when writing comprehensions" but simplifies the mental model for the new feature. "We don't believe that developers writing comprehensions should have to think about the differences between sync and async generator semantics or about generator delegation protocols."

While it is certainly useful, the feature is not revolutionary in any sense, it simply fills a fairly longstanding hole that has been noticed and discussed several times over the years. Python is a mature language at this point, so revolutions are likely to be few and far between—if not absent entirely. The whole tale shows, however, that, with some persistence, a well-written PEP, and a well-shepherded discussion (by Hartz joined by Zijlstra, Demaine was absent this time around), changes can be made. Future Python students can rejoice starting next October.

Comments (15 posted)

Zig's new plan for asynchronous programs

The designers of the Zig programming language have been working to find a suitable design for asynchronous code for some time. Zig is a carefully minimalist language, and its initial design for asynchronous I/O did not fit well with its other features. Now, the project has announced (in a Zig SHOWTIME video) a new approach to asynchronous I/O that promises to solve the function coloring problem, and allows writing code that will execute correctly using either synchronous or asynchronous I/O.

In many languages (including Python, JavaScript, and Rust), asynchronous code uses special syntax. This can make it difficult to reuse code between synchronous and asynchronous parts of a program, introducing a number of headaches for library authors. Languages that don't make a syntactical distinction (such as Haskell) essentially solve the problem by making everything asynchronous, which typically requires the language's runtime to bake in ideas about how programs are allowed to execute.

Neither of those options was deemed suitable for Zig. Its designers wanted to find an approach that did not add too much complexity to the language, that still permitted fine control over asynchronous operations, and that still made it relatively painless to actually write high-performance event-driven I/O. The new approach solves this by hiding asynchronous operations behind a new generic interface, Io.

Any function that needs to perform an I/O operation will need to have access to an instance of the interface. Typically, that is provided by passing the instance to the function as a parameter, similar to Zig's Allocator interface for memory allocation. The standard library will include two built-in implementations of the interface: Io.Threaded and Io.Evented. The former uses synchronous operations except where explicitly asked to run things in parallel (with a special function; see below), in which case it uses threads. The latter (which is still a work-in-progress) uses an event loop and asynchronous I/O. Nothing in the design prevents a Zig programmer from implementing their own version, however, so Zig's users retain their fine control over how their programs execute.

Loris Cro, one of Zig's community organizers, wrote an explanation of the new behavior to justify the approach. Synchronous code is not much changed, other than using the standard library functions that have moved under Io, he explained. Functions like the example below, which don't involve explicit asynchronicity, will continue to work. This example creates a file, sets the file to close at the end of the function, and then writes a buffer of data to the file. It uses Zig's try keyword to handle errors, and defer to ensure the file is closed. The return type, !void, indicates that it could return an error, but doesn't return any data:

    const std = @import("std");
    const Io = std.Io;

    fn saveFile(io: Io, data: []const u8, name: []const u8) !void {
        const file = try Io.Dir.cwd().createFile(io, name, .{});
        defer file.close(io);
        try file.writeAll(io, data);
    }

If this function is given an instance of Io.Threaded, it will create the file, write data to it, and then close it using ordinary system calls. If it is given an instance of Io.Evented, it will instead use io_uring, kqueue, or some other asynchronous backend suitable to the target operating system. In doing so, it might pause the current execution and go work on a different asynchronous function. Either way, the operation is guaranteed to be complete by the time writeAll() returns. A library author writing a function that involves I/O doesn't need to care about which of these things the ultimate user of the library chooses to do.

On the other hand, suppose that a program wanted to save two files. These operations could profitably be done in parallel. If a library author wanted to enable that, they could use the Io interface's async() function to express that it does not matter which order the two files are saved in:

    fn saveData(io: Io, data: []const u8) !void {
        // Calls saveFile(io, data, "saveA.txt")
        var a_future = io.async(saveFile, .{io, data, "saveA.txt"});
        var b_future = io.async(saveFile, .{io, data, "saveB.txt"});

        const a_result = a_future.await(io);
        const b_result = b_future.await(io);

        try a_result;
        try b_result;

        const out: Io.File = .stdout();
        try out.writeAll(io, "save complete");
    }

When using an Io.Threaded instance, the async() function doesn't actually isn't actually required to do anything asynchronously [although the actual implementation may dispatch the function to a separate thread, depending on how it was configured] — it can just run the provided function right away. So, with that version of the interface, the function first saves file A and then file B. With an Io.Evented instance, the operations are actually asynchronous, and the program can save both files at once.

The real advantage of this approach is that it turns asynchronous code into a performance optimization. The first version of a program or library can write normal straight-line code. Later, if asynchronicity proves to be useful for performance, the author can come back and write it using asynchronous operations. If the ultimate user of the function has not enabled asynchronous execution, nothing changes. If they have, though, the function becomes faster transparently — nothing about the function signature or how it interacts with the rest of the code base changes.

One problem, however, is with programs where two parts are actually required to execute simultaneously for correctness. For example, suppose that a program wants to listen for connections on a port and simultaneously respond to user input. In that scenario, it wouldn't be correct to wait for a connection and only then ask for user input. For that use case, the Io interface provides a separate function, asyncConcurrent()concurrent() [this function was renamed during development; concurrent() is the most recent name] that explicitly asks for the provided function to be run in parallel. Io.Threaded uses a thread in a thread pool to accomplish this. Io.Evented treats it exactly the same as a normal call to async().

    const socket = try openServerSocket(io);
    var server = try io.concurrent(startAccepting, .{io, socket});
    defer server.cancel(io) catch {};

    try handleUserInput(io);

If the programmer uses async() where they should have used concurrent(), that is a bug. Zig's new model does not (and cannot) prevent programmers from writing incorrect code, so there are still some subtleties to keep in mind when adapting existing Zig code to use the new interface.

The style of code that results from this design is a bit more verbose than languages that give asynchronous functions special syntax, but Andrew Kelley, creator of the language, said that "it reads like standard, idiomatic Zig code." In particular, he noted that this approach lets the programmer use all of Zig's typical control-flow primitives, such as try and defer; it doesn't introduce any new language features specific to asynchronous code.

To demonstrate this, Kelley gave an example of using the new interface to implement asynchronous DNS resolution. The standard getaddrinfo() function for querying DNS information falls short because, although it makes requests to multiple servers (for IPv4 and IPv6) in parallel, it waits for all of the queries to complete before returning an answer. Kelley's example Zig code returns the first successful answer, canceling the other inflight requests.

Asynchronous I/O in Zig is far from done, however. Io.Evented is still experimental, and doesn't have implementations for all supported operating systems yet. A third kind of Io, one that is compatible with WebAssembly, is planned (although, as that issue details, implementing it depends on some other new language features). The original pull request for Io lists 24 planned follow-up items, most of which still need work.

Still, the overall design of asynchronous code in Zig appears to be set. Zig has not yet had its 1.0 release, because the community is still experimenting with the correct way to implement many features. Asynchronous I/O was one of the larger remaining priorities (along with native code generation, which was also enabled by default for debug builds on some architectures this year). Zig seems to be steadily working its way toward a finished design — which should decrease the number of times Zig programmers are asked to rewrite their I/O because the interface has changed again.

Comments (20 posted)

BPF and io_uring, two different ways

BPF allows programs uploaded from user space to be run, safely, within the kernel. The io_uring subsystem, too, can be thought of as a way of loading programs in the kernel, though the programs in question are mostly a sequence of I/O-related system calls. It has sometimes seemed inevitable that io_uring would, like many other parts of the kernel, gain BPF capabilities as a way of providing more flexibility to user space. That has not yet happened, but there are currently two patch sets under consideration that take different approaches to the problem.

An io_uring "program" is built by placing a series of entries in a submission queue managed in a ring buffer shared between the kernel and user space. Each submission-queue entry (SQE) describes a system call to be performed, and may make use of special buffers and file descriptors maintained within io_uring itself. Each SQE is normally executed asynchronously, but it is possible to link a series of SQEs so that each is only executed after the successful completion of the previous one. The result of each operation is stored in a completion-queue entry (CQE) in a second shared ring. Using io_uring, an application can keep many streams of I/O going concurrently with a minimum of system calls.

The io_uring linkage mechanism enables simple sequences of operations, such as creating a file, writing a buffer to that file, and closing the file. It does not offer much flexibility; one operation cannot pass information to the next or change how subsequent operations may execute. So it is not surprising that adding BPF support is seen as a way of filling that gap. So far, though, no attempts at adding that support have been seriously considered for merging into the mainline.

BPF operations

In early November, Ming Lei posted a patch set adding BPF support to io_uring in the form of a new operation, IORING_OP_BPF, that can be placed in the submission queue. The linkage mechanism can be used, for example, to cause a BPF program to be run between two other io_uring operations. The programs themselves can be set up as, essentially, new io_uring operations.

Specifically, the patch creates a new struct ops program type for defining BPF operations. A user-space program will fill in and register a uring_bpf_ops structure:

    struct uring_bpf_ops {
	unsigned short		id;
	uring_io_prep_t		prep_fn;
	uring_io_issue_t	issue_fn;
	uring_io_fail_t		fail_fn;
	uring_io_cleanup_t	cleanup_fn;
    };

The id is an operation ID; only the bottom eight bits are used, meaning that a program can establish up to 256 separate BPF-based operations. The rest of the fields are BPF programs that will implement the functions required by io_uring to set up, execute, and clean up after I/O operations. There are a couple of new kfuncs provided for those programs to obtain the request data from an SQE and to store a result of the operation in the proper CQE.

Once the operation has been set up, io_uring SQEs can make use of it with an IORING_OP_BPF operation specifying the appropriate ID. Two buffers can be passed to a BPF operation in each request; a new kfunc has been added to allow BPF programs to bulk-copy data between buffers. One of the use cases targeted by this work is to make it easy to copy data between user space and in-kernel buffers that are not readily accessible from user space; this feature would evidently be helpful for the increasingly capable ublk io_uring-based block driver subsystem.

The number of review comments on this work has been relatively small. Stefan Metzmacher said: "This sounds useful to me". But Pavel Begunkov was rather more negative, saying that attempts to add BPF operations to io_uring in the past did not work well. The performance of BPF programs in that context, he said, is poor due to the associated io_uring overhead. He has a different approach, he added, that seems more promising.

Hooking into the control loop

Shortly thereafter, Begunkov posted a new version of a series he has been working on sporadically to add BPF support to io_uring in a different way. Rather than add a new operation type, this series adds a new hook into the io_uring completion loop, allowing a BPF program to be run as operations finish. This implementation, he said, can improve performance by moving CQE processing from user space into the kernel. It also, he said, could eventually allow for the removal of the io_uring linkage mechanism, which he called "a large liability" due to the complexity it adds, entirely.

This series, which shows some signs of having been prepared in a hurry, also sets up a struct ops hook. It adds a single callback which, according to the changelog, should be called handle_events(), but is actually:

    int (*loop)(struct io_ring_ctx *ctx, struct iou_loop_state *ls);

The ctx field gives information about the submission and completion queues, while the iou_loop_state parameter can be used to control how often loop() is to be called, determined by the number of available CQEs and a timeout. When this program is called, it can look at the completed operations, if any, and possibly enqueue new operations in response.

There is a pair of new kfuncs to go along with this mechanism. Pointers to the various parts of the ring buffer can be had with bpf_io_uring_get_region() (though Begunkov says that this interface is likely to be replaced in a future version), and bpf_io_uring_submit_sqes() can be used to submit new operations. Using these kfuncs, a BPF program could replace links by waiting for operations of interest to complete, then submitting the next operation that should follow, perhaps using information from the operations that have already completed.

Lei, having looked at Begunkov's patches, said that they do not solve the problem as well as his operation-based approach. The key difference Lei pointed out is that, with IORING_OP_BPF, the bulk of the application logic, including the creation of SQEs, remains in user space. With Begunkov's series, instead, much of the application logic must be pushed into the kernel, necessitating a lot of communication between user space and the kernel that has the potential to hurt performance. Begunkov answered that the communication can be handled efficiently using a BPF arena, and that his approach provides a greater level of flexibility to handle more types of applications.

Neither developer appears to have convinced the other. Lei intends to continue work on IORING_OP_BPF, while Begunkov is likely to do the same with his patch. Both developers have said that there might be room in the kernel for both approaches, though one might reasonably expect resistance from the wider BPF community to adding what appears to be redundant functionality. A third possibility — that io_uring and BPF remain unintegrated as they have for years — remains a possibility as well.

Comments (none posted)

Checked-size array parameters in C

There are many possible programmer mistakes that are not caught by the minimal checks specified by the C language; among those is passing an array of the wrong size to a function. A recent attempt to add some safety around array parameters within the crypto layer involved the use of some clever tricks, but it turns out that clever tricks are unnecessary in this case. There is an obscure C feature that can cause this checking to happen, and it is already in use in a few places within the kernel.

The discussion started when Ard Biesheuvel sought to improve the safety of the poetically named function xchacha20poly1305_encrypt():

    void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
			           const u8 *ad, const size_t ad_len,
			       	   const u8 nonce[XCHACHA20POLY1305_NONCE_SIZE],
			       	   const u8 key[CHACHA20POLY1305_KEY_SIZE]);

A potential problem with this function is that it takes as parameters several pointers to arrays of type u8. As Biesheuvel pointed out, the size of the nonce and key arrays is not checked by the compiler, even though it is clearly specified in the function prototype. That makes it easy to, for example, give the parameters in the wrong order. The resulting vulnerabilities are generally not the outcome developers have in mind when they write cryptographic code.

Biesheuvel suggested that it was possible to write the prototype this way instead (differences shown in bold):

    void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
			           const u8 *ad, const size_t ad_len,
			       	   const u8 (*nonce)[XCHACHA20POLY1305_NONCE_SIZE],
			       	   const u8 (*key)[CHACHA20POLY1305_KEY_SIZE]);

The types of the last two arguments have changed; there is a new level of pointer indirection, with the argument being a pointer to an array of a given size. Callers must change their calls by adding an additional & operator to obtain the desired pointer type, but the address that is passed is the same. In this case, though, the compiler will check the sizes of the array passed, and will now catch a reordering of the arguments to the function.

Jason Donenfeld was interested by the idea, but he knew of an arguably more straightforward way to address this problem. It seems that, buried deep within the C standard, is a strange usage of the static keyword, making it possible to write the prototype as:

    void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
			           const u8 *ad, const size_t ad_len,
			       	   const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
			       	   const u8 key[static CHACHA20POLY1305_KEY_SIZE]);

This, too, will cause the compiler to check the sizes of the arrays, and it does not require changes on the caller side. Unlike the pointer trick, which requires an exact match on the array size, use of static will only generate a warning if the passed-in array is too small. So it will not catch all mistakes, though it is sufficient to prevent memory-safety and swapped-argument problems.

Eric Biggers pointed out that GCC can often generate "array too small" warnings even without static, but that the kernel currently disables those warnings; that would suppress them when static is used as well. (The warning was disabled in 6.8 due to false positives.) But he thought that adding static was worthwhile to get the warnings in Clang — if Linus Torvalds would be willing to accept use of "this relatively obscure feature of C".

Torvalds, as it turns out, has no objection to this usage; he likes the feature, if not the way it was designed:

The main issue with the whole 'static' thing is just that the syntax is such a horrible hack, where people obviously picked an existing keyword that made absolutely no sense, but was also guaranteed to have no backwards compatibility issues.

He pointed out that there are a number of places in the kernel that are already using it; for a simple example, see getconsxy() in the virtual-terminal driver. He suggested perhaps hiding it with a macro like min_array_size() just to make the usage more obvious, but didn't seem convinced that it was necessary. Donenfeld followed up with a patch to that effect a few days later, but then pivoted to an at_least marker instead.

A lot of work has gone into the kernel to make its use of C as safe as possible, but that does not mean that the low-hanging fruit has all been picked. The language has features, such as static when used to define formal array parameters, that can improve safety, but which are not generally known and not often used. In this particular case, though, it would not be surprising to see this "horrible hack" come into wider use in the near future.

Comments (25 posted)

Some 6.18 development statistics

Linus Torvalds released the 6.18 kernel as expected on November 30, closing the last full development cycle of 2025. It was another busy cycle, featuring a record number of developers. The time has come for a look at where the code came from for this kernel release, but also for the year-long long-term-support cycle which has also reached its conclusion with this release.

As a reminder: LWN subscribers can find much of the information below — and more — at any time in the LWN Kernel Source Database.

The 6.18 release

The 6.18 development cycle brought in 13,710 commits from 2,134 developers. The commit count is more-or-less average for recent releases, but the number of developers involved is the highest that has yet been seen in the kernel's development history. There were 333 first-time kernel contributors this time around, falling just barely short of the record 335 new developers who contributed to 6.12 one year ago.

The most active contributors this time around were:

Most active 6.18 developers

By changesets Takashi Iwai 205 1.5% Stefan Metzmacher 183 1.3% Krzysztof Kozlowski 150 1.1% Brian Masney 145 1.1% Laurent Pinchart 138 1.0% Sean Christopherson 126 0.9% Al Viro 121 0.9% Qianfeng Rong 109 0.8% Eric Biggers 107 0.8% Bartosz Golaszewski 100 0.7% Jakub Kicinski 97 0.7% Mauro Carvalho Chehab 97 0.7% Eric Dumazet 95 0.7% Ian Rogers 94 0.7% Jani Nikula 89 0.6% Russell King 88 0.6% Rob Herring 85 0.6% Thorsten Blum 85 0.6% Thomas Weißschuh 77 0.6% Xichao Zhao 73 0.5%

By changed lines Linus Torvalds 117581 14.9% Przemek Kitszel 16530 2.1% Ian Rogers 13869 1.8% Takashi Iwai 13147 1.7% Taniya Das 12000 1.5% Alice Ryhl 11836 1.5% Eric Biggers 10349 1.3% Abhijit Gangurde 9432 1.2% Fan Gong 7664 1.0% Jerome Brunet 7181 0.9% Jakub Kicinski 7103 0.9% Mauro Carvalho Chehab 7062 0.9% Tomeu Vizoso 6336 0.8% Laura Nao 6241 0.8% Dongsheng Yang 5472 0.7% Alex Deucher 5447 0.7% Dikshita Agarwal 5065 0.6% Beleswar Padhi 5001 0.6% Hector Martin 4870 0.6% Laurent Pinchart 4679 0.6%

Takashi Iwai, the maintainer of the sound subsystem, was the top contributor of changesets this time around; the bulk of them were bringing scope-based resource management to that subsystem. Stefan Metzmacher worked extensively in the SMB filesystem client and server implementations. Krzysztof Kozlowski, as is often the case, contributed a lot of devicetree (and related) changes. Brian Masney performed a large set of API conversions within the clock-driver subsystem, and Laurent Pinchart made a lot of updates within the media subsystem.

Linus Torvalds makes a rare appearance at the top of the "lines changed" column by virtue of having removed the bcachefs filesystem. Przemek Kitszel performed some significant refactoring of the Intel "ice" Ethernet driver. Ian Rogers worked extensively with the perf tool. Iwai's work has been noted above; Taniya Das added a number of clock drivers. Also worthy of mention is Alice Ryhl who, after years of work, contributed the Rust binder driver.

This time around, 9.0% of the commits to the mainline had Tested-by tags, while 53.6% had Reviewed-by tags — both typical numbers. The top testers and reviewers for 6.18 were:

Test and review credits in 6.18
Tested-by Dan Wheeler 134 8.9% Neil Armstrong 91 6.1% Arnaldo Carvalho de Melo 39 2.6% Bryan O'Donoghue 33 2.2% Vikash Garodia 26 1.7% Chris Packham 25 1.7% Rick Edgecombe 25 1.7% Venkat Rao Bagalkote 25 1.7% Mathias Krause 24 1.6% John Allen 24 1.6% Rinitha S 22 1.5% Hans de Goede 21 1.4% Thomas Falcon 20 1.3% Ramu R 18 1.2% Jayesh Choudhary 17 1.1%	Reviewed-by Simon Horman 227 2.3% Dmitry Baryshkov 199 2.0% Konrad Dybcio 179 1.8% Andy Shevchenko 139 1.4% Krzysztof Kozlowski 137 1.4% Geert Uytterhoeven 132 1.3% Lorenzo Stoakes 129 1.3% Frank Li 120 1.2% Linus Walleij 115 1.2% Rob Herring 111 1.1% Alice Ryhl 106 1.1% Andrew Lunn 104 1.1% David Sterba 99 1.0% Christian Brauner 97 1.0% Alex Deucher 94 1.0%

These listings change little from one release to the next; the community's most diligent testers and reviewers are seemingly in it for the long term.

The work in 6.18 was supported by 217 employers that we know of; those most active employers were:

Most active 6.18 employers

By changesets Intel 1420 10.4% (Unknown) 1307 9.5% Google 1080 7.9% Red Hat 866 6.3% AMD 682 5.0% (None) 633 4.6% Linaro 539 3.9% SUSE 534 3.9% Qualcomm 529 3.9% Meta 445 3.2% Renesas Electronics 358 2.6% Huawei Technologies 356 2.6% (Consultant) 309 2.3% NVIDIA 300 2.2% Oracle 257 1.9% vivo Mobile Communication Co 257 1.9% NXP Semiconductors 223 1.6% Arm 210 1.5% Collabora 189 1.4% SerNet 183 1.3%

By lines changed Linux Foundation 118142 15.0% Intel 74255 9.4% Google 67881 8.6% Qualcomm 56423 7.2% (Unknown) 55307 7.0% AMD 35901 4.6% (None) 33870 4.3% Red Hat 29083 3.7% SUSE 26027 3.3% Meta 24669 3.1% Huawei Technologies 23250 3.0% Linaro 19481 2.5% (Consultant) 15261 1.9% NVIDIA 14395 1.8% Collabora 13782 1.8% Texas Instruments 12434 1.6% Renesas Electronics 10756 1.4% NXP Semiconductors 9893 1.3% BayLibre 9025 1.1% Microsoft 8065 1.0%

These numbers, too, tend to be relatively consistent from one release to the next.

Finally, counting the number of Signed-off-by tags applied by developers to patches authored by others gives an insight into patch acceptance; those tags are usually applied when a patch is applied to a subsystem tree on its way toward the mainline. The top appliers of patches in 6.18 were:

Non-author Signed-off-by tags in 6.18

Individual Jakub Kicinski 1055 8.1% Alex Deucher 544 4.2% Andrew Morton 522 4.0% Hans Verkuil 432 3.3% Mark Brown 398 3.1% Greg Kroah-Hartman 363 2.8% Bjorn Andersson 333 2.6% Paolo Abeni 305 2.3% Steve French 265 2.0% Jens Axboe 197 1.5% Arnaldo Carvalho de Melo 192 1.5% Jonathan Cameron 191 1.5% Sakari Ailus 170 1.3% Borislav Petkov 164 1.3% Jonathan Corbet 159 1.2% Alexei Starovoitov 145 1.1% Shawn Guo 141 1.1% David Sterba 132 1.0% Martin K. Petersen 132 1.0% Lee Jones 116 0.9%

Employers Meta 1551 12.0% Google 1439 11.1% Intel 1231 9.5% Red Hat 1008 7.8% AMD 963 7.4% Linaro 768 5.9% Qualcomm 590 4.5% Arm 522 4.0% Linux Foundation 438 3.4% Microsoft 432 3.3% Cisco 432 3.3% SUSE 405 3.1% (Unknown) 329 2.5% NVIDIA 293 2.3% Huawei Technologies 286 2.2% Oracle 240 1.8% (None) 199 1.5% Renesas Electronics 175 1.3% LWN.net 159 1.2% Linutronix 113 0.9%

It still remains true that (just) over half of the patches landing in the mainline pass through the hands of maintainers employed by just five companies — two hyperscalers, two CPU manufacturers, and Red Hat. The Linux Foundation has moved down on this list, perhaps because the amount of activity in the staging tree has fallen considerably over the years, reducing the number of patches handled by Greg Kroah-Hartman.

The longer cycle

For some years now, the last kernel release of each calendar year is designated a long-term-support (LTS) release, which will receive support for a minimum of two years. Most Linux systems in the wild are not running arbitrary kernel releases; they are, instead, running one of these LTS releases. One can thus think of the kernel development cycle as having a one-year cadence; there are checkpoint releases every nine or ten weeks, but there is one major release at the end of the year that is widely deployed.

Last year's LTS release was 6.12; there have been six releases since then that incorporated 80,035 non-merge changesets from 5,275 developers. The most active developers over the course of the year were:

Most active 6.13-18 developers

By changesets Kent Overstreet 901 1.1% Krzysztof Kozlowski 739 0.9% Sean Christopherson 715 0.9% Jani Nikula 653 0.8% Thomas Weißschuh 650 0.8% Bartosz Golaszewski 650 0.8% Jakub Kicinski 579 0.7% Takashi Iwai 571 0.7% Ian Rogers 562 0.7% Eric Biggers 549 0.7% Dmitry Baryshkov 538 0.7% Christoph Hellwig 517 0.6% Thomas Zimmermann 487 0.6% Andy Shevchenko 483 0.6% Matthew Wilcox 478 0.6% Rob Herring 462 0.6% Alex Deucher 455 0.6% Ville Syrjälä 426 0.5% Filipe Manana 415 0.5% Al Viro 412 0.5%

By changed lines Linus Torvalds 123175 2.9% Wayne Lin 81574 1.9% Ian Rogers 80735 1.9% Philipp Hortmann 76407 1.8% Eric Biggers 49999 1.2% Dennis Dalessandro 48357 1.1% Johannes Berg 42369 1.0% Bitterblue Smith 39788 0.9% Jan Kara 36943 0.9% Takashi Iwai 35887 0.8% Dave Penkler 34047 0.8% Rob Herring 33894 0.8% Miri Korenblit 33729 0.8% Dmitry Baryshkov 31440 0.7% Kent Overstreet 29500 0.7% Taniya Das 29077 0.7% Jani Nikula 28008 0.7% Dr. David Alan Gilbert 26438 0.6% Andrew Donnellan 25845 0.6% Richard Fitzgerald 25402 0.6%

In 2024, Kent Overstreet topped the by-changesets list with nearly 4,000 commits; there were two other developers (Uwe Kleine-König and Krzysztof Kozlowski) with over 1,000 commits. This year, the curve is somewhat flatter, with nobody reaching 1,000 commits. The same is true of the lines-changed column, most resulting from a slowdown in the addition of massive, machine-generated amdgpu graphics-driver header files.

It is somewhat ironic, though, that the top of the by-changesets column reflects the addition of bcachefs, while the top of the by-lines column reflects its removal.

The top testers and reviewers over the longer cycle were:

Test and review credits in 6.13-18

Tested-by Dan Wheeler 760 8.9% Neil Armstrong 329 3.9% Arnaldo Carvalho de Melo 157 1.8% Thomas Falcon 113 1.3% Dmitry Osipenko 97 1.1% Rinitha S 92 1.1% Randy Dunlap 89 1.0% Venkat Rao Bagalkote 82 1.0% Rafal Romanowski 76 0.9% Tomi Valkeinen 69 0.8% Mark Pearson 68 0.8% Nicolin Chen 68 0.8% James Clark 64 0.8% Timur Tabi 60 0.7% Bryan O'Donoghue 58 0.7% Babu Moger 56 0.7% Alex Bennée 55 0.6% Pucha Himasekhar Reddy 54 0.6% Vikash Garodia 52 0.6% K Prateek Nayak 51 0.6%

Reviewed-by Simon Horman 1255 2.3% Dmitry Baryshkov 1033 1.9% Krzysztof Kozlowski 932 1.7% Ilpo Järvinen 762 1.4% Christoph Hellwig 736 1.3% Geert Uytterhoeven 735 1.3% Konrad Dybcio 684 1.2% Andy Shevchenko 633 1.1% Andrew Lunn 597 1.1% David Sterba 596 1.1% Rob Herring 556 1.0% Linus Walleij 467 0.8% Neil Armstrong 456 0.8% AngeloGioacchino Del Regno 447 0.8% Frank Li 431 0.8% Laurent Pinchart 427 0.8% Chao Yu 416 0.8% Darrick J. Wong 383 0.7% Christian König 373 0.7% Jeff Layton 373 0.7%

The most active employers (out of the 372 total) over the longer cycle were:

Most active 6.13-18 employers

By changesets Intel 8813 11.0% (Unknown) 6796 8.5% Google 6037 7.5% Red Hat 5181 6.5% (None) 4257 5.3% AMD 4098 5.1% Linaro 3701 4.6% SUSE 2750 3.4% Meta 2744 3.4% Qualcomm 2532 3.2% Huawei Technologies 1917 2.4% Oracle 1886 2.4% NVIDIA 1882 2.4% Renesas Electronics 1858 2.3% Arm 1547 1.9% IBM 1345 1.7% (Consultant) 1252 1.6% NXP Semiconductors 1218 1.5% Linutronix 1149 1.4% Microsoft 887 1.1%

By lines changed Intel 434943 10.2% (Unknown) 383181 9.0% Google 309767 7.2% AMD 277384 6.5% Qualcomm 235450 5.5% Red Hat 215725 5.0% (None) 176686 4.1% SUSE 133567 3.1% Linaro 129946 3.0% Linux Foundation 129058 3.0% Meta 124927 2.9% NVIDIA 107931 2.5% IBM 96906 2.3% Huawei Technologies 82132 1.9% Arm 77217 1.8% Emerson 76919 1.8% Collabora 64629 1.5% NXP Semiconductors 62549 1.5% Oracle 60553 1.4% Renesas Electronics 52732 1.2%

Now begins the 6.19 development cycle, starting this whole process over again. As of this writing, there are just over 12,500 changesets waiting in linux-next, suggesting that 6.19 will be another busy — but typical — development cycle. In other words, the kernel project will be beginning 2026 at full speed; we'll do everything we can to keep up.

Comments (2 posted)

Just: a command runner

Over time, many Linux users wind up with a collection of aliases, shell scripts, and makefiles to run simple commands (or a series of commands) that are often used, but challenging to remember and annoying to type out at length. The just command runner is a Rust-based utility that just does one thing and does it well: it reads recipes from a text file (aptly called a "justfile"), and runs the commands from an invoked recipe. Rather than accumulating a library of one-off shell scripts over time, just provides a cross-platform tool with a framework and well-documented syntax for collecting and documenting tasks that makes it useful for solo users and collaborative projects.

just what it is

Using just has a few advantages over a collection of scripts or bending make to uses it may not be intended for. It's certainly easier to get started with than make for newer Linux users who haven't had the need to learn make previously. Generally, just is more ergonomic for what it does; it isn't a complete replacement for shell scripts or scripting, but it provides a better framework, organization, and user experience.

A task is defined by a recipe. A recipe is, basically a series of commands that are to be run by just. This is a simple recipe that tells me a bit about the operating system just is running on:

    os:
        @echo "This is a {{os()}} system running on {{arch()}} with {{num_cpus()}} logical CPUs."

Running "just os" produces the following output on my system:

    This is a linux system running on x86_64 with 16 logical CPUs.

The recipes for tasks are collected in a justfile and stored in the user's home directory or in the root directory of a project. Technically, these can be broken out into multiple files and imported into the main justfile, but let's not go down that rabbit hole just now.

Say an open-source project includes a justfile in its Git repository for doing common tasks, such as updating the changelog, running tests, or publishing a release; all a new contributor needs to do is run "just -l" to discover the tasks that are available, along with their documentation. Assuming, of course, someone has written the documentation—just is useful, but it's not magic.

Another advantage is that just is expressly designed for running tasks across multiple platforms and for collaborative use. For instance, it has built-in functions for determining and acting on system information (such as os() for the operating system), environment variables, error handling, and much more. A task can be written to use sh on Linux, ksh on macOS, and PowerShell on Windows, if needed. Recipes can have shared variables and settings, so one need not redefine $TMPDIR in each shell script for a project. A recipe can also have dependencies, specified similarly to makefile dependencies, which can be reused for multiple recipes as needed.

Users can invoke multiple recipes at once, and a recipe's dependencies can be skipped by using the --no-deps option when a user just wants to execute the primary task. For example, perhaps a task has a dependency on downloading an ISO image or other large file; that can be skipped if it has been run recently and the user knows there is not a newer one.

Project history

Casey Rodarmor created just in 2016. The project is inspired by make; in fact it was originally just a shell script that called make. But just is not meant to be a replacement for make or a build system in general; it is just a command runner. It is licensed, somewhat unusually, under the Creative Commons Zero (CC0) 1.0 Universal deed: essentially, it is public-domain code. Rodarmor wrote that he chose CC0 because he had "no desire to impose any restrictions whatsoever on anyone who wants to use my code." Nearly 200 people have made small contributions to just, but the bulk of development is Rodarmor's work.

Like many maintainers of open-source projects these days, Rodarmor does not tend to do major releases with many new features. Instead, there is a frequent stream of minor releases with a few new features and miscellaneous improvements, along with point releases with bug fixes. The most recent minor release, 1.43.0, came out in September, with the 1.43.1 bug fix release on November 12. According to the Just Programmer's Manual, there will never be a 2.0 release. Any backward-incompatible changes, "will be opt-in on a per-justfile basis, so users may migrate at their leisure". Any recipes written for a version of just since 1.0 should continue to work without breakage indefinitely.

Most popular Linux distributions provide just packages, though the version in a distribution's repository may be somewhat out of date given how frequently the project is released. Users can also snag the latest version using "cargo install just", or use one of the project's pre-built binaries.

Justfiles

The just command looks for a file named justfile with recipes in the current directory or those above it. The idea is that a user might include a justfile with each project, as well as a justfile in their home directory for miscellaneous recipes. So, if the present working directory is ~/src/project, the "just foo" command will tell the utility to look in ~/src/project for a justfile. If it is not found there, then just will look in ~/src, and ~ for a justfile. Technically it will keep looking in /home and such, but one hopes users are not placing their recipe files there. One of the features added in 1.43.0 is a --ceiling option; this lets the user specify the "top" directory where just should stop looking for a justfile.

Note that the name is case-insensitive; just will accept Justfile, justfile, JUSTFILE, and .justfile if one prefers to hide configuration files. Even JuStFiLe will work, though it would be an affront to good taste. Naturally, there is a justfile in the just repository that has recipes for building project documentation, running demos, creating the just man page, updating Rust, and more.

Once just finds a justfile, it stops looking; this means that, for example, if one has a justfile in ~/ and another in ~/project/foo, running just in the ~/project/foo directory will usually not find any recipes above that directory. This can be changed by adding the set fallback directive in a recipe file. That way, if a user runs "just foo" and there is no recipe foo to be found in the first justfile, it will keep looking in the directories above it.

The syntax for just is inspired by make, but Rodarmor wanted to avoid what he calls the idiosyncrasies of make: such as the need to have .PHONY targets when there is a file with the same name as a make target (e.g., "clean") in the directory. Recipe lines must be indented at least one level from the recipe name, but users have a choice of spaces or tabs. Note that each recipe does have to be consistent: just does not allow indenting one line of a recipe with spaces, and another line with tabs.

Here is a simple recipe, called pub I use to update my Hugo-based static site:

    # update dissociatedpress.net
    [no-cd]
    pub:
        hugo
        rsync -avh --progress -e ssh /home/user/src/dissociatedpress/public/ \
        user@dissociatedpress.net:/path/to/www/html
        w3m https://dissociatedpress.net/

When I run "just pub", just steps through the recipe and runs each line in a separate shell. It runs hugo in the directory where the justfile is invoked; the default is for just to run a recipe in the directory where the justfile is stored, but [no-cd] instructs it to run the recipe in the current directory instead. It will rsync the contents to the server, and then open the site in w3m so I can verify that the site was updated.

Running "just -l" will list all of the available recipes in a justfile. If there is a comment above the recipe, it will be displayed:

    $ just -l
    pub #update dissociatedpress.net

The "just --choose" command will display an interactive menu that allows the user to choose the just recipe to run. This makes use of the fzf command-line fuzzy finder by default; it will work without it, but just prints a warning if it cannot find fzf. Most distributions should have fzf available.

Polyglot

Typically, just uses "sh -cu" to execute the commands in a recipe, unless configured otherwise. That can be changed with the "set shell" setting in a recipe, such as this:

    set shell := ["fish", "-c"]

One of just's more interesting features is its support for writing recipes in many programming languages, so users are not limited to shell interpreters; these are called shebang recipes. Basically, a user can write a recipe using JavaScript, Perl, Python, Ruby, and just about any other scripting language. A shebang recipe is saved to a temporary file by just and then run using the interpreter specified:

    python:
        #!/usr/bin/env python3
        print('GNU Terry Pratchett')

Running "just python" saves the Python script to /tmp to be executed by python3. The temporary directory can be specified in several ways if one wants to avoid placing scripts in a world-readable directory. Users can, of course, substitute their favorite languages; a justfile can contain shebang recipes in multiple languages with no problem.

Recipes can use conditional expressions, take variables from the command line, and much more. The programmer's manual does a fine job of laying out all of just's features and how to use them. There is also a cheatsheet for just syntax and grammar; it is a useful thing to have bookmarked if one starts to use just.

Simple and useful

The project has a Discord channel for discussion and support. There is a GitHub issue that Rodarmor uses to solicit user feedback when he is considering major new features, such as new recipe types. He suggests that users subscribe to that issue if they would like to provide input on features in the future. Sadly, GitHub does not offer RSS feeds for issues, so the only way to keep up with that is to have a GitHub account and use its subscribe feature.

I had heard of just but had not bothered to try it out until I started testing the Project Bluefin distribution in 2023. The project uses just, aliased to ujust, to use the system-wide justfiles for a number of administrative tasks or to toggle user features on and off. For example, Bluefin has "ujust benchmark" to run a one-minute benchmark test with the stress-ng utility, and "ujust setup-luks-tpm-unlock" to enable automatic disk unlocking. The justfiles for the distribution can be found on GitHub and the project also maintains a justfile with recipes for building the distribution images. Those files provide some interesting examples of just's capabilities.

Since then, I've been using just rather than shell scripts and such for automating little things (or medium-sized things...), and converting old scripts to recipes. It's one of the first tools I install on a new system, and it makes everything just a bit easier.

Comments (36 posted)

Landlock-ing Linux (prizrak.me)

The prizrak.me blog is carrying an introduction to the Landlock security module.

Landlock shines when an application has a predictable set of files or directories it needs. For example, a web server could restrict itself to accessing only /var/www/html and /tmp.

Unlike SELinux or AppArmor, Landlock policies don't require administrator involvement or system-wide configuration. Developers can embed policies directly in application code, making sandboxing a natural part of the development process.

Comments (31 posted)

Let's Encrypt to reduce certificate lifetimes

Let's Encrypt has announced that it will be reducing the validity period of its certificates from 90 days to 45 days by 2028:

Most users of Let's Encrypt who automatically issue certificates will not have to make any changes. However, you should verify that your automation is compatible with certificates that have shorter validity periods.

To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI). ARI is a feature we've introduced to help clients know when they need to renew their certificates. Consult your ACME client's documentation on how to enable ARI, as it differs from client to client. If you are a client developer, check out this integration guide.

If your client doesn't support ARI yet, ensure it runs on a schedule that is compatible with 45-day certificates. For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate's lifetime.

Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes.

Comments (none posted)

Improving GCC Buffer Overflow Detection for C Flexible Array Members (Oracle)

The Oracle blog has a lengthy article on enhancements to GCC to help detect overflows of flexible array members (FAMs) in C programs.

We describe here two new GNU extensions which specify size information for FAMs. These are a new attribute, "counted_by" and a new builtin function, "__builtin_counted_by_ref". Both extensions can be used in GNU C applications to specify size information for FAMs, improving the buffer overflow detection for FAMs in general.

This work has been covered on LWN as well.

Comments (none posted)

Kernel release status

The 6.18 kernel was released on November 30; in the announcement Linus said:

So I'll have to admit that I'd have been happier with slightly less bugfixing noise in this last week of the release, but while there's a few more fixes than I would hope for, there was nothing that made me feel like this needs more time to cook. So 6.18 is tagged and pushed out.

Headline changes in this release include the ability to manage namespaces with file handles, support for the AccECN congestion-control protocol, initial support for signing of BPF programs, improved memory management with sheaves, the Rust binder driver, better control over transparent huge pages, and a lot more. This release also saw the removal of the bcachefs filesystem.

See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.18 page for more information.

Stable updates: 6.17.9, 6.12.59, and 6.6.117 were released on November 24, followed by 6.17.10, 6.12.60, and 6.6.118 on December 1.

On December 3, 5.4.302 was released as the final update in the 5.4.x series:

This is the LAST 5.4.y release. It is now end-of-life and should not be used by anyone, anymore. As of this point in time, there are 1539 documented unfixed CVEs for this kernel branch, and that number will only increase over time as more CVEs get assigned for kernel bugs.

For the curious, Kroah-Hartman has also provided a list of the unfixed CVEs for 5.4.302.

The 6.17.11, 6.12.61, 6.6.119, 6.1.159, 5.15.197, and 5.10.247 updates are in the review process; they are due on December 5.

Comments (none posted)

The 2025 Linux Foundation Technical Advisory Board election

The call for candidates for the 2025 election for the Linux Foundation Technical Advisory Board has been posted.

The TAB exists to provide advice from the kernel community to the Linux Foundation and holds a seat on the LF's board of directors; it also serves to facilitate interactions both within the community and with outside entities. Over the last year, the TAB has overseen the organization of the Linux Plumbers Conference, advised on the setup of the kernel CVE numbering authority, worked behind the scenes to help resolve a number of contentious community discussions, worked with the Linux Foundation on community conference planning, and more.

Nominations close on December 13.

Comments (none posted)

Racing karts on a Rust GPU kernel driver (Collabora blog)

In July, Collabora announced the Rust-based Tyr GPU driver for Arm Mali GPUs. Daniel Almeida has posted an update on progress with a prototype of the driver running on a Rock 5B board with the Rockchip RK3588 system-on-chip:

The Tyr prototype has progressed from basic GPU job execution to running GNOME, Weston, and full-screen 3D games like SuperTuxKart, demonstrating a functional, high-performance Rust driver that matches C-driver performance and paves the way for eventual upstream integration! [...]

Tyr is not ready to be used as a daily-driver, and it will still take time to replicate this upstream, although it is now clear that we will surely get there. And as a mere prototype, it has a lot of shortcuts that we would not have in an upstream version, even though it can run on top of an unmodified (i.e., upstream) version of Mesa.

That said, this prototype can serve as an experimental driver and as a testbed for all the Rust abstraction work taking place upstream. It will let us experiment with different design decisions and gather data on what truly contributes to the project's objective.

There is also a video on YouTube of the prototype in action.

Comments (21 posted)

Quote of the week

It has now been 0 days since a AI-hallucinated "security report" was sent to the kernel security team.

Right now we seem to be averaging about 1 per week, not bad overall probably compared to other projects.

— Greg Kroah-Hartman

Comments (none posted)

AlmaLinux 10.1 released

AlmaLinux 10.1 has been released. In addition to providing binary compatibility with Red Hat Enterprise Linux (RHEL) 10.1, the most notable feature in AlmaLinux 10.1 is the addition of support for Btrfs, which is not available in RHEL:

Btrfs support encompasses both kernel and userspace enablement, and it is now possible to install AlmaLinux OS on a Btrfs filesystem from the very beginning. Initial enablement was scoped to the installer and storage management stack, and broader support within the AlmaLinux software collection for Btrfs features is forthcoming.

In addition to Btrfs support, AlmaLinux OS 10.1 includes numerous other improvements to serve our community. We have continued to extend hardware support both by adding drivers and by adding a secondary version of AlmaLinux OS and EPEL to extend support of x86_64_v2 processors.

See the release notes for a full list of changes.

Comments (1 posted)

FreeBSD 15.0 released

FreeBSD 15.0 has been released. Notable changes in this release include a new method for installing the base system using the pkg package manager, an update to OpenZFS 2.4.0-rc4, native support for the inotify(2) interface, and the addition of Open Container Initiative (OCI) images to FreeBSD's release artifacts. See the release notes for a full list of changes, hardware notes for supported hardware, and check the errata before installing or upgrading.

Comments (2 posted)

NixOS 25.11 released

Version 25.11 of the NixOS distribution has been released. "The 25.11 release was made possible due to the efforts of 2742 contributors, who authored 59430 commits since the previous release". Changes include 7,002 new packages, GNOME 49, LLVM 21, a new COSMIC desktop environment beta, firewalld support, and more; see the release notes for details.

Comments (none posted)

Distributions quote of the week

I've run for FESCO 4 times and lost 2 (technically 3, but I was still given a spot once because someone resigned their term early). I am in favor of having more newcomers in FESCO, and I understand that it's not fun to run and lose and it can be hard to put yourself out there and risk embarrassment.

However, I don't think we should change the voting rules. To me it defeats the purpose of having an election if we are going to change the rules to get the outcome that we want rather than the outcome that the voters want. In this case, you might as well just have FESCO itself choose the new members and drop the voting altogether.

For me, the best way to get more newcomers is to speak directly to the voters. Either by advocating for specific newcomers on the list or by providing more detailed information about the current makeup of FESCO and how long each person has served.

Ultimately, if the voters continue voting the same people into FESCO, they must be happy with the results, so why try to subvert the will of the voters in this case?

— Tom Stellard

Comments (none posted)

Django 6.0 released

The Django Python web framework project has announced the release of Django 6.0 including many new features, as can be seen in the release notes. Some highlights include template partials for modularizing templates, a flexible task framework for running background tasks, a modernized email API, and a Content Security Policy (CSP) feature that provides the ability to "easily configure and enforce browser-level security policies to protect against content injection".

Comments (none posted)

Home Assistant 2025.12 released

Version 2025.12 of the Home Assistant home-automation system has been released.

This month, we're unveiling Home Assistant Labs, a brand-new space where you can preview features before they go mainstream. And what better way to kick it off than with Winter mode? ❄️ Enable it and watch snowflakes drift across your dashboard. It's completely unnecessary, utterly delightful, and exactly the kind of thing we love to build. ❄️

But that's just the beginning. We've been working on making automations more intuitive over the past releases, and this release finally delivers purpose-specific triggers and conditions. Instead of thinking in (numeric) states, you can now simply say "When a light turns on" or "If the climate is heating". It's automation building the way our mind works, as it should be.

Comments (5 posted)

KDE Plasma 6.8 will be Wayland-only

KDE's Plasma team has announced that KDE Plasma will drop X11 session support with Plasma 6.8:

The Plasma X11 session will be supported by KDE into early 2027.

We cannot provide a specific date, as we're exploring the possibility of shipping some extra bug-fix releases for Plasma 6.7. The exact timing of the last one will only be known when we get closer to its actual release, which we expect will be sometime in early 2027.

What if I still really need X11?

This is a perfect use case for long term support (LTS) distributions shipping older versions of Plasma. For example, AlmaLinux 9 includes the Plasma X11 session and will be supported until sometime in 2032.

See the blog post for information on running X11 applications (still supported), accessibility, gaming, and more.

Comments (61 posted)

PHP 8.5.0 released

Version 8.5.0 of the PHP language has been released. Changes include a new "|>" operator that, for some reason, makes these two lines equivalent:

    $result = strlen("Hello world");
    $result = "Hello world" |> strlen(...);

Other changes include a new function attribute, "#[\NoDiscard]" to indicate that the return value should be used, attributes on constants, and more; see the migration guide for details.

Comments (10 posted)

Racket 9.0 released

The Racket programming language project has released Racket version 9.0. Racket is a descendant of Scheme, so it is part of the Lisp family of languages. The headline feature in the release is parallel threads, which adds to the concurrency tools in the language: "While Racket has had green threads for some time, and supports parallelism via futures and places, we feel parallel threads is a major addition." Other new features include the black-box wrapper to prevent the compiler from optimizing calculations away, the decompile-linklet function to map linklets back to an s-expression, the addition of Weibull distributions to the math library, and more.

Comments (none posted)

CFP Deadlines: December 4, 2025 to February 2, 2026

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
December 15	March 9 March 10	FOSSASIA Summit	Bangkok, Thailand
December 15	February 24 February 25	Linux Foundation Member Summit	Napa, CA, US
December 16	January 29 January 30	CentOS Connect	Brussels, Belgium
December 18	December 1 December 3	Critical Decentralisation Cluster at 39C3	Hamburg, Germany
December 19	May 15 May 17	PyCon US	Long Beach, California, US
December 21	February 2	OpenEmbedded Workshop 2026	Brussels, Belgium
December 31	April 28 April 29	stackconf 2026	Munich, Germany
January 12	March 28 March 29	Chemnitz Linux Days	Chemnitz, Germany
January 12	March 28	Central Pennsylvania Open Source Conference	Lancaster, Pennsylvania, US
January 31	April 10 April 11	Grazer Linuxtage	Graz, Austria

If the CFP deadline for your event does not appear here, please tell us about it.

Events: December 4, 2025 to February 2, 2026

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
December 2 December 4	Yocto Project Virtual Summit 2025.12	Online
December 6	OLF Conference	Columbus, OH, US
December 6 December 7	EmacsConf	online
December 8 December 10	Open Source Summit Japan	Tokyo, Japan
December 8 December 10	Automotive Linux Summit	Tokyo, Japan
December 10 December 11	Open Source Experience 2025	Paris, France
December 11 December 12	Open Compliance Summit	Tokyo, Japan
December 11 December 13	Linux Plumbers Conference	Tokyo, Japan
December 13 December 14	LibreOffice Asia Conference 2025	Tokyo, Japan
December 13 December 15	GNOME Asia Summit 2025	Tokyo, Japan
January 21 January 23	Everything Open	Canberra, Australia
January 29 January 30	CentOS Connect	Brussels, Belgium
January 31 February 1	Free and Open source Software Developers' European Meeting	Brussels, Belgium

If your event does not appear here, please tell us about it.

Alert summary November 27, 2025 to December 3, 2025

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:21034	10	bind	2025-11-25
AlmaLinux	ALSA-2025:21110	9	bind	2025-11-19
AlmaLinux	ALSA-2025:19950	9	bind9.18	2025-11-19
AlmaLinux	ALSA-2025:21111	9	bind9.18	2025-12-01
AlmaLinux	ALSA-2025:20155	10	binutils	2025-11-25
AlmaLinux	ALSA-2025:22011	9	buildah	2025-11-25
AlmaLinux	ALSA-2025:21232	8	container-tools:rhel8	2025-11-20
AlmaLinux	ALSA-2025:22063	8	cups	2025-12-01
AlmaLinux	ALSA-2025:21816	10	delve and golang	2025-11-25
AlmaLinux	ALSA-2025:21815	9	delve and golang	2025-11-20
AlmaLinux	ALSA-2025:21030	10	expat	2025-11-25
AlmaLinux	ALSA-2025:21776	8	expat	2025-11-20
AlmaLinux	ALSA-2025:21281	10	firefox	2025-11-25
AlmaLinux	ALSA-2025:21280	9	firefox	2025-11-25
AlmaLinux	ALSA-2025:21968	9	gimp	2025-12-01
AlmaLinux	ALSA-2025:22005	9	go-rpm-macros	2025-11-25
AlmaLinux	ALSA-2025:20532	9	grub2	2025-11-19
AlmaLinux	ALSA-2025:21691	10	haproxy	2025-11-25
AlmaLinux	ALSA-2025:21693	9	haproxy	2025-11-19
AlmaLinux	ALSA-2025:21140	8	idm:DL1	2025-11-20
AlmaLinux	ALSA-2025:20928	9	ipa	2025-12-01
AlmaLinux	ALSA-2025:20095	10	kernel	2025-11-25
AlmaLinux	ALSA-2025:19931	8	kernel	2025-11-19
AlmaLinux	ALSA-2025:21398	8	kernel	2025-11-20
AlmaLinux	ALSA-2025:21917	8	kernel	2025-11-25
AlmaLinux	ALSA-2025:20518	9	kernel	2025-11-19
AlmaLinux	ALSA-2025:21926	9	kernel	2025-12-01
AlmaLinux	ALSA-2025:21397	8	kernel-rt	2025-11-20
AlmaLinux	ALSA-2025:21920	8	kernel-rt	2025-11-25
AlmaLinux	ALSA-2025:21628	8	lasso	2025-11-19
AlmaLinux	ALSA-2025:21462	9	lasso	2025-11-19
AlmaLinux	ALSA-2025:20959	9	libsoup	2025-11-19
AlmaLinux	ALSA-2025:21032	10	libsoup3	2025-11-25
AlmaLinux	ALSA-2025:21013	10	libssh	2025-11-25
AlmaLinux	ALSA-2025:21977	8	libssh	2025-12-01
AlmaLinux	ALSA-2025:20943	9	libssh	2025-11-19
AlmaLinux	ALSA-2025:20998	10	libtiff	2025-11-25
AlmaLinux	ALSA-2025:20956	9	libtiff	2025-11-19
AlmaLinux	ALSA-2025:21974	8	mingw-expat	2025-12-01
AlmaLinux	ALSA-2025:20126	10	openssh	2025-11-25
AlmaLinux	ALSA-2025:21248	10	openssl	2025-11-25
AlmaLinux	ALSA-2025:21255	9	openssl	2025-12-01
AlmaLinux	ALSA-2025:20181	10	pam	2025-11-25
AlmaLinux	ALSA-2025:19719	8	pcs	2025-11-20
AlmaLinux	ALSA-2025:20962	9	pcs	2025-12-01
AlmaLinux	ALSA-2025:21220	10	podman	2025-11-25
AlmaLinux	ALSA-2025:20983	10	podman	2025-11-25
AlmaLinux	ALSA-2025:21702	9	podman	2025-11-19
AlmaLinux	ALSA-2025:20909	9	podman	2025-11-25
AlmaLinux	ALSA-2025:21142	10	python-kdcproxy	2025-11-25
AlmaLinux	ALSA-2025:21139	9	python-kdcproxy	2025-11-19
AlmaLinux	ALSA-2025:20963	9	qt5-qt3d	2025-11-19
AlmaLinux	ALSA-2025:20926	9	redis	2025-11-19
AlmaLinux	ALSA-2025:20955	9	redis:7	2025-11-19
AlmaLinux	ALSA-2025:20957	9	runc	2025-11-19
AlmaLinux	ALSA-2025:20145	10	shadow-utils	2025-11-25
AlmaLinux	ALSA-2025:20559	9	shadow-utils	2025-11-19
AlmaLinux	ALSA-2025:20936	9	sqlite	2025-11-19
AlmaLinux	ALSA-2025:21002	10	squid	2025-11-25
AlmaLinux	ALSA-2025:20935	9	squid	2025-11-19
AlmaLinux	ALSA-2025:20954	9	sssd	2025-12-01
AlmaLinux	ALSA-2025:21843	10	thunderbird	2025-11-25
AlmaLinux	ALSA-2025:21881	8	thunderbird	2025-11-25
AlmaLinux	ALSA-2025:20958	9	tigervnc	2025-12-01
AlmaLinux	ALSA-2025:21916	9	valkey	2025-12-01
AlmaLinux	ALSA-2025:21015	10	vim	2025-11-25
AlmaLinux	ALSA-2025:20945	9	vim	2025-11-19
AlmaLinux	ALSA-2025:20922	9	webkit2gtk3	2025-11-19
AlmaLinux	ALSA-2025:20961	9	xorg-x11-server	2025-11-19
AlmaLinux	ALSA-2025:21035	10	xorg-x11-server-Xwayland	2025-11-25
AlmaLinux	ALSA-2025:20960	9	xorg-x11-server-Xwayland	2025-11-19
AlmaLinux	ALSA-2025:20478	10	zziplib	2025-11-25
AlmaLinux	ALSA-2025:20838	9	zziplib	2025-11-19
Debian	DSA-6060-1	stable	chromium	2025-11-19
Debian	DSA-6067-1	stable	containerd	2025-12-02
Debian	DLA-4380-1	LTS	cups-filters	2025-11-25
Debian	DLA-4376-1	LTS	erlang	2025-11-24
Debian	DSA-6066-1	stable	gnome-shell-extension-gsconnect	2025-11-30
Debian	DSA-6063-1	stable	kdeconnect	2025-11-26
Debian	DSA-6065-1	stable	krita	2025-11-27
Debian	DLA-4382-1	LTS	libsdl2	2025-11-25
Debian	DLA-4385-1	LTS	libssh	2025-11-27
Debian	DLA-4379-1	LTS	linux-6.1	2025-11-25
Debian	DLA-4393-1	LTS	mako	2025-12-03
Debian	DLA-4392-1	LTS	mistral-dashboard	2025-12-01
Debian	DLA-4381-1	LTS	net-snmp	2025-11-25
Debian	DLA-4390-1	LTS	pagure	2025-12-01
Debian	DSA-6062-1	stable	pdfminer	2025-11-25
Debian	DLA-4377-1	LTS	python-gevent	2025-11-24
Debian	DLA-4391-1	LTS	python-mistralclient	2025-12-01
Debian	DLA-4389-1	LTS	pytorch	2025-12-01
Debian	DLA-4387-1	LTS	qtbase-opensource-src	2025-11-29
Debian	DLA-4378-1	LTS	r-cran-gh	2025-11-25
Debian	DLA-4383-1	LTS	rails	2025-11-25
Debian	DLA-4384-1	LTS	samba	2025-11-26
Debian	DLA-4386-1	LTS	sogo	2025-11-28
Debian	DSA-6061-1	stable	tryton-sao	2025-11-25
Debian	DLA-4387-1	LTS	tryton-server	2025-11-28
Debian	DSA-6064-1	stable	tryton-server	2025-11-27
Debian	DLA-4365-2	LTS	unbound	2025-12-01
Debian	DLA-4375-1	LTS	webkit2gtk	2025-11-20
Debian	DSA-6068-1	stable	xen	2025-12-02
Fedora	FEDORA-2025-b6422d64f9	F43	7zip	2025-11-27
Fedora	FEDORA-2025-8a248ee4f4	F42	buildah	2025-11-25
Fedora	FEDORA-2025-355be35bb1	F43	calibre	2025-11-24
Fedora	FEDORA-2025-58193e3850	F42	cef	2025-11-29
Fedora	FEDORA-2025-604e02ca72	F43	cef	2025-11-29
Fedora	FEDORA-2025-ee528a170d	F41	chromium	2025-11-26
Fedora	FEDORA-2025-54b43715b6	F42	chromium	2025-11-25
Fedora	FEDORA-2025-d41f5f4a2a	F43	chromium	2025-11-24
Fedora	FEDORA-2025-8c88aa0c74	F41	cri-o1.32	2025-11-22
Fedora	FEDORA-2025-91677b56d4	F42	cri-o1.32	2025-11-22
Fedora	FEDORA-2025-a246780676	F43	cri-o1.32	2025-11-22
Fedora	FEDORA-2025-b339c2eaad	F43	cri-o1.33	2025-11-22
Fedora	FEDORA-2025-8bd0d993db	F41	cri-o1.34	2025-11-22
Fedora	FEDORA-2025-1e7710541e	F42	cri-o1.34	2025-11-22
Fedora	FEDORA-2025-723e0fd8bd	F43	cri-o1.34	2025-11-22
Fedora	FEDORA-2025-1ccd7dbf40	F41	docker-buildkit	2025-11-27
Fedora	FEDORA-2025-308cf4259b	F42	docker-buildkit	2025-11-27
Fedora	FEDORA-2025-264853458b	F43	docker-buildkit	2025-11-26
Fedora	FEDORA-2025-6e24679a4d	F41	docker-buildx	2025-11-27
Fedora	FEDORA-2025-04cf139ee2	F42	docker-buildx	2025-11-26
Fedora	FEDORA-2025-b1d7d7f8db	F43	docker-buildx	2025-11-26
Fedora	FEDORA-2025-969f0c8c1e	F41	dotnet10.0	2025-11-22
Fedora	FEDORA-2025-aaa5764dc9	F42	dotnet10.0	2025-11-22
Fedora	FEDORA-2025-41518fc0fd	F43	dotnet10.0	2025-11-22
Fedora	FEDORA-2025-e491c93405	F43	dovecot	2025-11-22
Fedora	FEDORA-2025-d645721ca4	F41	drupal7	2025-11-29
Fedora	FEDORA-2025-f8a08bb335	F42	drupal7	2025-11-29
Fedora	FEDORA-2025-355d5aac01	F43	drupal7	2025-11-29
Fedora	FEDORA-2025-35fe65f08c	F43	forgejo	2025-12-03
Fedora	FEDORA-2025-bab973d0b9	F43	glib2	2025-12-01
Fedora	FEDORA-2025-b346087f6b	F42	gnutls	2025-12-02
Fedora	FEDORA-2025-45b1844342	F43	gnutls	2025-11-23
Fedora	FEDORA-2025-817b0dc707	F43	gopass	2025-11-22
Fedora	FEDORA-2025-b3bd444d1f	F41	gopass-hibp	2025-11-22
Fedora	FEDORA-2025-d4a04dda81	F43	gopass-jsonapi	2025-11-22
Fedora	FEDORA-2025-fd56e115c0	F42	k9s	2025-11-25
Fedora	FEDORA-2025-30806907c2	F43	k9s	2025-11-25
Fedora	FEDORA-2025-d9389fc692	F41	kubernetes1.31	2025-11-22
Fedora	FEDORA-2025-4a1370ea1b	F42	kubernetes1.31	2025-11-22
Fedora	FEDORA-2025-5a4555eabc	F43	kubernetes1.31	2025-11-22
Fedora	FEDORA-2025-547f14aef4	F41	kubernetes1.32	2025-11-23
Fedora	FEDORA-2025-0131063534	F42	kubernetes1.32	2025-11-22
Fedora	FEDORA-2025-00368e9022	F43	kubernetes1.32	2025-11-22
Fedora	FEDORA-2025-e282b00383	F41	kubernetes1.33	2025-11-25
Fedora	FEDORA-2025-362709ff5e	F42	kubernetes1.33	2025-11-25
Fedora	FEDORA-2025-298add9246	F43	kubernetes1.33	2025-11-24
Fedora	FEDORA-2025-ebce31df24	F41	kubernetes1.34	2025-11-25
Fedora	FEDORA-2025-4c576d1bd9	F42	kubernetes1.34	2025-11-25
Fedora	FEDORA-2025-f32b1debd8	F43	kubernetes1.34	2025-11-24
Fedora	FEDORA-2025-6af3ed0ae3	F43	libpng	2025-12-02
Fedora	FEDORA-2025-ecd9a3485b	F42	linux-firmware	2025-11-22
Fedora	FEDORA-2025-a45a370014	F42	linux-firmware	2025-11-29
Fedora	FEDORA-2025-0ef7552461	F43	linux-firmware	2025-11-22
Fedora	FEDORA-2025-698dc1bbfa	F43	linux-firmware	2025-11-29
Fedora	FEDORA-2025-57302ba8ea	F42	migrate	2025-11-29
Fedora	FEDORA-2025-427af3b610	F43	migrate	2025-11-29
Fedora	FEDORA-2025-be2f64c384	F42	mingw-python3	2025-12-02
Fedora	FEDORA-2025-5058925e1c	F43	mingw-python3	2025-12-02
Fedora	FEDORA-2025-bb6c04e3ee	F41	nextcloud	2025-12-03
Fedora	FEDORA-2025-f62aee4fe6	F42	nextcloud	2025-12-03
Fedora	FEDORA-2025-84af4b9872	F43	nextcloud	2025-12-03
Fedora	FEDORA-2025-45a7dd8f10	F41	openbao	2025-12-03
Fedora	FEDORA-2025-6b2336ec55	F42	openbao	2025-12-03
Fedora	FEDORA-2025-c7f4367479	F43	openbao	2025-12-03
Fedora	FEDORA-2025-387540db1f	F42	pack	2025-11-29
Fedora	FEDORA-2025-20f7fd3e95	F43	pack	2025-11-29
Fedora	FEDORA-2025-f7d8e75d34	F42	pgadmin4	2025-12-01
Fedora	FEDORA-2025-8a81153971	F43	pgadmin4	2025-12-01
Fedora	FEDORA-2025-8a248ee4f4	F42	podman	2025-11-25
Fedora	FEDORA-2025-cb26113de5	F42	python-mkdocs-include-markdown-plugin	2025-11-25
Fedora	FEDORA-2025-1b1bb708af	F43	python-mkdocs-include-markdown-plugin	2025-11-25
Fedora	FEDORA-2025-be2a1b5e6a	F41	python-spotipy	2025-12-02
Fedora	FEDORA-2025-9501cd4d8c	F42	python-spotipy	2025-12-02
Fedora	FEDORA-2025-20ca419536	F43	python-spotipy	2025-12-02
Fedora	FEDORA-2025-5f73919942	F42	rclone	2025-12-03
Fedora	FEDORA-2025-5e299f890a	F43	rclone	2025-12-03
Fedora	FEDORA-2025-f618726d01	F41	restic	2025-12-03
Fedora	FEDORA-2025-65fc438cba	F42	restic	2025-12-03
Fedora	FEDORA-2025-416c3b48b3	F43	restic	2025-12-03
Fedora	FEDORA-2025-bc8b81c28d	F41	rnp	2025-11-29
Fedora	FEDORA-2025-7bef956026	F42	rnp	2025-11-29
Fedora	FEDORA-2025-a96ccc98ca	F43	rnp	2025-11-29
Fedora	FEDORA-2025-96f340d7a0	F42	source-to-image	2025-12-02
Fedora	FEDORA-2025-dc3c993169	F43	source-to-image	2025-12-02
Fedora	FEDORA-2025-ada7909175	F41	sudo-rs	2025-11-26
Fedora	FEDORA-2025-4388808bbf	F42	sudo-rs	2025-11-26
Fedora	FEDORA-2025-a9d9780cbb	F43	sudo-rs	2025-11-26
Fedora	FEDORA-2025-f59b250c31	F42	tigervnc	2025-12-03
Fedora	FEDORA-2025-e0c935675d	F43	tigervnc	2025-12-03
Fedora	FEDORA-2025-38b1c0f3b5	F42	unbound	2025-12-02
Fedora	FEDORA-2025-90281e4554	F43	unbound	2025-11-29
Fedora	FEDORA-2025-4fc934f283	F42	webkitgtk	2025-12-02
Fedora	FEDORA-2025-6f3e9e3af6	F43	webkitgtk	2025-11-25
Gentoo	202511-04		Chromium, Google Chrome, Microsoft Edge. Opera	2025-11-24
Gentoo	202511-01		UDisks	2025-11-24
Gentoo	202511-02		WebKitGTK+	2025-11-24
Gentoo	202511-07		librnp	2025-11-26
Gentoo	202511-03		qtsvg	2025-11-24
Gentoo	202511-05		redict, redis	2025-11-24
Mageia	MGASA-2025-0312	9	cups-filters	2025-11-24
Mageia	MGASA-2025-0306	9	ffmpeg	2025-11-21
Mageia	MGASA-2025-0309	9	kernel, kmod-xtables-addons & kmod-virtualbox	2025-11-22
Mageia	MGASA-2025-0310	9	kernel-linus	2025-11-22
Mageia	MGASA-2025-0308	9	konsole	2025-11-21
Mageia	MGASA-2025-0314	9	libpng	2025-12-01
Mageia	MGASA-2025-0307	9	redis	2025-11-21
Mageia	MGASA-2025-0311	9	ruby-rack	2025-11-24
Mageia	MGASA-2025-0313	9	webkit2	2025-11-25
Oracle	ELSA-2025-21110	OL9	bind	2025-11-26
Oracle	ELSA-2025-21111	OL9	bind9.18	2025-11-27
Oracle	ELSA-2025-22011	OL9	buildah	2025-11-26
Oracle	ELSA-2025-22063	OL8	cups	2025-11-26
Oracle	ELSA-2025-21815	OL9	delve and golang	2025-11-26
Oracle	ELSA-2025-21776	OL8	expat	2025-11-21
Oracle	ELSA-2025-22175	OL9	expat	2025-11-26
Oracle	ELSA-2025-22363	OL8	firefox	2025-12-03
Oracle	ELSA-2025-21280	OL9	firefox	2025-11-26
Oracle	ELSA-2025-21968	OL9	gimp	2025-11-26
Oracle	ELSA-2025-22005	OL9	go-rpm-macros	2025-11-26
Oracle	ELSA-2025-21693	OL9	haproxy	2025-11-26
Oracle	ELSA-2025-20928	OL9	ipa	2025-11-27
Oracle	ELSA-2025-28026	OL7	kernel	2025-12-03
Oracle	ELSA-2025-21917	OL8	kernel	2025-11-25
Oracle	ELSA-2025-22388	OL8	kernel	2025-12-03
Oracle	ELSA-2025-28024	OL8	kernel	2025-12-03
Oracle	ELSA-2025-28026	OL8	kernel	2025-12-03
Oracle	ELSA-2025-28026	OL8	kernel	2025-12-03
Oracle	ELSA-2025-21926	OL9	kernel	2025-11-26
Oracle	ELSA-2025-21112	OL9	kernel	2025-11-27
Oracle	ELSA-2025-21469	OL9	kernel	2025-11-27
Oracle	ELSA-2025-28024	OL9	kernel	2025-12-03
Oracle	ELSA-2025-28025	OL9	kernel	2025-12-03
Oracle	ELSA-2025-22405	OL9	kernel	2025-12-03
Oracle	ELSA-2025-28024	OL9	kernel	2025-12-03
Oracle	ELSA-2025-28025	OL9, OL10	kernel	2025-12-03
Oracle	ELSA-2025-21628	OL8	lasso	2025-11-20
Oracle	ELSA-2025-21462	OL9	lasso	2025-11-26
Oracle	ELSA-2025-20959	OL9	libsoup	2025-11-26
Oracle	ELSA-2025-21977	OL8	libssh	2025-11-25
Oracle	ELSA-2025-20943	OL9	libssh	2025-11-27
Oracle	ELSA-2025-21407	OL7	libtiff	2025-12-03
Oracle	ELSA-2025-20956	OL9	libtiff	2025-11-26
Oracle	ELSA-2025-22376	OL9	libxml2	2025-12-03
Oracle	ELSA-2025-21974	OL8	mingw-expat	2025-11-26
Oracle	ELSA-2025-21255	OL9	openssl	2025-11-26
Oracle	ELSA-2025-20909	OL9	podman	2025-11-26
Oracle	ELSA-2025-21702	OL9	podman	2025-11-26
Oracle	ELSA-2025-16099	OL7	postgresql	2025-11-20
Oracle	ELSA-2025-28019	OL8	postgresql	2025-12-03
Oracle	ELSA-2025-21139	OL9	python-kdcproxy	2025-11-26
Oracle	ELSA-2025-20963	OL9	qt5-qt3d	2025-11-26
Oracle	ELSA-2025-20926	OL9	redis	2025-11-27
Oracle	ELSA-2025-20955	OL9	redis:7	2025-11-27
Oracle	ELSA-2025-20957	OL9	runc	2025-11-26
Oracle	ELSA-2025-20936	OL9	sqlite	2025-11-27
Oracle	ELSA-2025-20935	OL9	squid	2025-11-26
Oracle	ELSA-2025-20954	OL9	sssd	2025-11-27
Oracle	ELSA-2025-21881	OL8	thunderbird	2025-11-21
Oracle	ELSA-2025-21842	OL9	thunderbird	2025-11-26
Oracle	ELSA-2025-20958	OL9	tigervnc	2025-11-26
Oracle	ELSA-2025-21916	OL9	valkey	2025-11-26
Oracle	ELSA-2025-20945	OL9	vim	2025-11-27
Oracle	ELSA-2025-20922	OL9	webkit2gtk3	2025-11-26
Oracle	ELSA-2025-20961	OL9	xorg-x11-server	2025-11-26
Oracle	ELSA-2025-20960	OL9	xorg-x11-server-Xwayland	2025-11-26
Red Hat	RHSA-2025:0532-01	EL9.4	.NET 8.0	2025-11-25
Red Hat	RHSA-2025:0039-01	EL6	bind and bind-dyndb-ldap	2025-11-24
Red Hat	RHSA-2025:20095-01	EL10	kernel	2025-11-21
Red Hat	RHSA-2025:20518-01	EL9	kernel	2025-11-21
Red Hat	RHSA-2025:21926-01	EL9	kernel	2025-11-24
Red Hat	RHSA-2025:22077-01	EL8.2	tigervnc	2025-11-25
Red Hat	RHSA-2025:22041-01	EL8.6	tigervnc	2025-11-25
Red Hat	RHSA-2025:20958-01	EL9	tigervnc	2025-11-25
Red Hat	RHSA-2025:22056-01	EL9.0	tigervnc	2025-11-25
Red Hat	RHSA-2025:22055-01	EL9.2	tigervnc	2025-11-25
Red Hat	RHSA-2025:22051-01	EL9.4	tigervnc	2025-11-25
Red Hat	RHSA-2025:22040-01	EL7	xorg-x11-server	2025-11-25
Red Hat	RHSA-2025:20961-01	EL9	xorg-x11-server	2025-11-25
Red Hat	RHSA-2025:21035-01	EL10	xorg-x11-server-Xwayland	2025-11-25
Red Hat	RHSA-2025:20960-01	EL9	xorg-x11-server-Xwayland	2025-11-25
Slackware	SSA:2025-331-01		cups	2025-11-27
Slackware	SSA:2025-332-01		libxslt	2025-11-28
Slackware	SSA:2025-323-01		openvpn	2025-11-19
SUSE	openSUSE-SU-2025:15752-1	TW	act	2025-11-22
SUSE	openSUSE-SU-2025:0437-1	osB15	act	2025-11-24
SUSE	openSUSE-SU-2025-20073-1	oS16.0	alloy	2025-11-21
SUSE	SUSE-SU-2025:4191-1	MP4.2 MP4.3 SLE15 oS15.6	amazon-ssm-agent	2025-11-24
SUSE	SUSE-SU-2025:4244-1	SLE12	amazon-ssm-agent	2025-11-26
SUSE	openSUSE-SU-2025:15753-1	TW	ansible-12	2025-11-22
SUSE	openSUSE-SU-2025:15754-1	TW	ansible-core	2025-11-22
SUSE	openSUSE-SU-2025-20130-1	oS16.0	bash-git-prompt	2025-12-01
SUSE	SUSE-SU-2025:4222-1	SLE-m5.0 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	bind	2025-11-25
SUSE	openSUSE-SU-2025:15756-1	TW	blender	2025-11-22
SUSE	openSUSE-SU-2025:15755-1	TW	blender	2025-11-22
SUSE	SUSE-SU-2025:4229-1	SLE15 SES7.1 oS15.3	buildah	2025-11-25
SUSE	SUSE-SU-2025:4274-1	SLE15 oS15.4	buildah	2025-11-27
SUSE	SUSE-SU-2025:4245-1	SLE15 oS15.5 oS15.6	buildah	2025-11-26
SUSE	openSUSE-SU-2025-20076-1	oS16.0	chromium	2025-11-21
SUSE	openSUSE-SU-2025:0434-1	osB15	chromium	2025-11-20
SUSE	openSUSE-SU-2025:0433-1	osB15	chromium	2025-11-20
SUSE	openSUSE-SU-2025:15763-1	TW	cloudflared	2025-11-26
SUSE	SUSE-SU-2025:21042-1	SLE-m6.0	containerd	2025-11-27
SUSE	SUSE-SU-2025:21057-1	SLE-m6.1	containerd	2025-11-27
SUSE	SUSE-SU-2025:4288-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.6	containerd	2025-11-28
SUSE	openSUSE-SU-2025:0446-1	osB15	cpp-httplib	2025-11-29
SUSE	SUSE-SU-2025:4289-1	SLE12	cups	2025-11-28
SUSE	SUSE-SU-2025:4290-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	cups	2025-11-28
SUSE	SUSE-SU-2025:4198-1	SLE12	cups-filters	2025-11-24
SUSE	SUSE-SU-2025:4158-1	SLE15 oS15.6	cups-filters	2025-11-21
SUSE	SUSE-SU-2025:4180-1	SLE-m5.2	curl	2025-11-24
SUSE	SUSE-SU-2025:4309-1	SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	curl	2025-11-28
SUSE	SUSE-SU-2025:21077-1	SLE-m6.2	curl	2025-11-28
SUSE	SUSE-SU-2025:4300-1	SLE15	curl	2025-11-28
SUSE	SUSE-SU-2025:4236-1	SLE15 oS15.6	curl	2025-11-25
SUSE	openSUSE-SU-2025:15757-1	TW	curl	2025-11-22
SUSE	openSUSE-SU-2025-20113-1	oS16.0	dovecot24	2025-11-28
SUSE	SUSE-SU-2025:4254-1	SLE15 oS15.6	dpdk	2025-11-26
SUSE	SUSE-SU-2025:4092-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.6	elfutils	2025-11-24
SUSE	openSUSE-SU-2025:15740-1	TW	erlang27	2025-11-19
SUSE	SUSE-SU-2025:21028-1	SLE-m6.2	expat	2025-11-27
SUSE	SUSE-SU-2025:21006-1	SLE16	expat	2025-11-26
SUSE	openSUSE-SU-2025-20055-1	oS16.0	expat	2025-11-21
SUSE	SUSE-SU-2025:4174-1	SLE12	firefox	2025-11-24
SUSE	SUSE-SU-2025:4173-1	SLE15 SES7.1 oS15.6	firefox	2025-11-24
SUSE	SUSE-SU-2025:21021-1	SLE16	firefox	2025-11-26
SUSE	openSUSE-SU-2025-20065-1	oS16.0	firefox	2025-11-21
SUSE	openSUSE-SU-2025:15758-1	TW	fontforge-20251009	2025-11-25
SUSE	SUSE-SU-2025:4148-1	SLE15 oS15.6	ghostscript	2025-11-20
SUSE	openSUSE-SU-2025:15771-1	TW	git-bug	2025-11-27
SUSE	openSUSE-SU-2025:0443-1	osB15	gitea-tea	2025-11-27
SUSE	openSUSE-SU-2025:0454-1	osB15	gitea-tea	2025-12-01
SUSE	openSUSE-SU-2025:0453-1	osB15	gitea-tea	2025-12-01
SUSE	SUSE-SU-2025:4186-1	SLE-m5.2	glib2	2025-11-24
SUSE	SUSE-SU-2025:21063-1	SLE-m6.1	glib2	2025-11-27
SUSE	SUSE-SU-2025:4278-1	SLE12	glib2	2025-11-27
SUSE	SUSE-SU-2025:4308-1	SLE15 oS15.6	glib2	2025-11-28
SUSE	SUSE-SU-2025:4272-1	SLE-m5.2	gnutls	2025-11-27
SUSE	SUSE-SU-2025:4271-1	SLE-m5.3	gnutls	2025-11-27
SUSE	openSUSE-SU-2025:15765-1	TW	gnutls	2025-11-26
SUSE	SUSE-SU-2025:4220-1	SLE15 oS15.6	govulncheck-vulndb	2025-11-25
SUSE	SUSE-SU-2025:4143-1	SLE-m5.2 oS15.3	grub2	2025-11-20
SUSE	SUSE-SU-2025:4224-1	SLE-m5.3 SLE-m5.4 oS15.4	grub2	2025-11-25
SUSE	SUSE-SU-2025:4152-1	SLE-m5.5 oS15.5	grub2	2025-11-21
SUSE	SUSE-SU-2025:21062-1	SLE-m6.1	grub2	2025-11-27
SUSE	SUSE-SU-2025:4197-1	SLE12	grub2	2025-11-24
SUSE	SUSE-SU-2025:4305-1	SLE15	grub2	2025-11-28
SUSE	SUSE-SU-2025:4196-1	SLE15 oS15.6	grub2	2025-11-24
SUSE	openSUSE-SU-2025:15749-1	TW	grub2	2025-11-22
SUSE	SUSE-SU-2025:21043-1	SLE-m6.0	helm	2025-11-27
SUSE	SUSE-SU-2025:4190-1	SLE15 SLE-m5.5 SES7.1 oS15.6	helm	2025-11-24
SUSE	openSUSE-SU-2025-20114-1	oS16.0	himmelblau	2025-11-28
SUSE	openSUSE-SU-2025-20125-1	oS16.0	java-17-openjdk	2025-12-01
SUSE	openSUSE-SU-2025-20123-1	oS16.0	java-21-openjdk	2025-12-01
SUSE	SUSE-SU-2025:4287-1	SLE15	java-25-openjdk	2025-11-28
SUSE	SUSE-SU-2025:4188-1	MP4.2 SLE15 SLE-m5.1 SLE-m5.2 SES7.1 oS15.3	kernel	2025-11-24
SUSE	SUSE-SU-2025:21040-1	SLE-m6.0	kernel	2025-11-27
SUSE	SUSE-SU-2025:21052-1	SLE-m6.0	kernel	2025-11-27
SUSE	SUSE-SU-2025:21064-1	SLE-m6.0 SLE-m6.1	kernel	2025-11-27
SUSE	SUSE-SU-2025:21056-1	SLE-m6.0 SLE-m6.1	kernel	2025-11-27
SUSE	SUSE-SU-2025:4315-1	SLE11	kernel	2025-12-01
SUSE	SUSE-SU-2025:4189-1	SLE12	kernel	2025-11-24
SUSE	SUSE-SU-2025:4141-1	SLE15	kernel	2025-11-19
SUSE	SUSE-SU-2025:4139-1	SLE15 SLE-m5.3 SLE-m5.4	kernel	2025-11-19
SUSE	SUSE-SU-2025:4149-1	SLE15 SLE-m5.5 oS15.5	kernel	2025-11-20
SUSE	SUSE-SU-2025:4140-1	SLE15 oS15.6	kernel	2025-11-19
SUSE	SUSE-SU-2025:4301-1	SLE15 oS15.6	kernel	2025-11-28
SUSE	SUSE-SU-2025:21080-1	SLE16 SLE-m6.2	kernel	2025-11-28
SUSE	openSUSE-SU-2025-20081-1	SLE16 SLE-m6.2 oS16.0	kernel	2025-11-26
SUSE	SUSE-SU-2025:21074-1	SLE16 SLE-m6.2 oS16.0	kernel	2025-11-28
SUSE	openSUSE-SU-2025-20091-1	SLE16 oS16.0	kernel	2025-11-27
SUSE	openSUSE-SU-2025:15741-1	TW	libIex-3_4-33	2025-11-19
SUSE	openSUSE-SU-2025:15759-1	TW	libIex-3_4-33	2025-11-25
SUSE	openSUSE-SU-2025:15780-1	TW	libcoap-devel	2025-11-29
SUSE	SUSE-SU-2025:4310-1	SLE15 oS15.4 oS15.6	libcryptopp	2025-11-28
SUSE	openSUSE-SU-2025:0438-1	osB15	libebml	2025-11-24
SUSE	openSUSE-SU-2025:15789-1	TW	libecpg6	2025-12-02
SUSE	openSUSE-SU-2025:15751-1	TW	libipa_hbac-devel	2025-11-22
SUSE	SUSE-SU-2025:4291-1	SLE15 oS15.6	libmicrohttpd	2025-11-28
SUSE	openSUSE-SU-2025:15762-1	TW	librnp0	2025-11-25
SUSE	SUSE-SU-2025:21082-1	SLE-m6.2	libvirt	2025-11-28
SUSE	openSUSE-SU-2025:15778-1	TW	libwireshark19	2025-11-28
SUSE	SUSE-SU-2025:21031-1	SLE-m6.2	libxslt	2025-11-27
SUSE	SUSE-SU-2025:21008-1	SLE16	libxslt	2025-11-26
SUSE	openSUSE-SU-2025-20050-1	oS16.0	libxslt	2025-11-21
SUSE	openSUSE-SU-2025:15788-1	TW	lightdm-kde-greeter	2025-12-02
SUSE	openSUSE-SU-2025-20089-1	oS16.0	mysql-connector-java	2025-11-27
SUSE	SUSE-SU-2025:4187-1	SLE15 SES7.1 oS15.6	nvidia-container-toolkit	2025-11-24
SUSE	SUSE-SU-2025:21016-1	SLE16	ongres-scram	2025-11-26
SUSE	openSUSE-SU-2025-20059-1	oS16.0	ongres-scram	2025-11-21
SUSE	openSUSE-SU-2025:15767-1	TW	openbao	2025-11-26
SUSE	SUSE-SU-2025:21014-1	SLE16	openexr	2025-11-26
SUSE	openSUSE-SU-2025-20056-1	oS16.0	openexr	2025-11-21
SUSE	SUSE-SU-2025:21044-1	SLE-m6.0	openssh	2025-11-27
SUSE	openSUSE-SU-2025-20122-1	oS16.0	openssh	2025-12-01
SUSE	openSUSE-SU-2025-20115-1	oS16.0	pnpm	2025-11-28
SUSE	SUSE-SU-2025:21038-1	SLE-m6.0	podman	2025-11-27
SUSE	SUSE-SU-2025:4156-1	SLE15 SLE-m5.2 SES7.1 oS15.3	podman	2025-11-21
SUSE	SUSE-SU-2025:4157-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	podman	2025-11-21
SUSE	SUSE-SU-2025:4185-1	SLE15 SLE-m5.5 oS15.5 oS15.6	podman	2025-11-24
SUSE	openSUSE-SU-2025-20068-1	oS16.0	poppler	2025-11-21
SUSE	openSUSE-SU-2025:15784-1	TW	postgresql15	2025-11-29
SUSE	openSUSE-SU-2025:15786-1	TW	postgresql17	2025-11-29
SUSE	SUSE-SU-2025:21067-1	SLE-m6.1	powerpc-utils	2025-11-27
SUSE	SUSE-SU-2025:4313-1	SLE15 oS15.6	python	2025-12-01
SUSE	openSUSE-SU-2025-20133-1	oS16.0	python-cbor2	2025-12-03
SUSE	openSUSE-SU-2025:15790-1	TW	python-mistralclient-doc	2025-12-02
SUSE	SUSE-SU-2025:4257-1	MP4.3 SLE15 oS15.4	python311	2025-11-26
SUSE	SUSE-SU-2025:4297-1	SLE15 oS15.6	python311	2025-11-28
SUSE	openSUSE-SU-2025:15760-1	TW	python311	2025-11-25
SUSE	SUSE-SU-2025:4258-1	SLE15 oS15.6	python312	2025-11-26
SUSE	openSUSE-SU-2025:15742-1	TW	python312	2025-11-19
SUSE	SUSE-SU-2025:4277-1	SLE15	python313	2025-11-27
SUSE	openSUSE-SU-2025:15791-1	TW	python315	2025-12-02
SUSE	openSUSE-SU-2025:15792-1	TW	python39	2025-12-02
SUSE	SUSE-SU-2025:4221-1	oS15.3 oS15.6	python39	2025-11-25
SUSE	openSUSE-SU-2025:15761-1	TW	rclone	2025-11-25
SUSE	openSUSE-SU-2025-20121-1	oS16.0	redis	2025-11-28
SUSE	openSUSE-SU-2025-20116-1	oS16.0	rnp	2025-11-28
SUSE	SUSE-SU-2025:4264-1	SLE15	ruby2.5	2025-11-26
SUSE	SUSE-SU-2025:4273-1	MP4.2 MP4.3 SLE15 oS15.6	rubygem-rack	2025-11-27
SUSE	SUSE-SU-2025:21036-1	SLE-m6.0	runc	2025-11-27
SUSE	SUSE-SU-2025:21054-1	SLE-m6.1	runc	2025-11-27
SUSE	SUSE-SU-2025:21072-1	SLE-m6.2	runc	2025-11-28
SUSE	SUSE-SU-2025:4073-2	SLE15	runc	2025-11-24
SUSE	openSUSE-SU-2025-20072-1	oS16.0	runc	2025-11-21
SUSE	SUSE-SU-2025:21026-1	SLE-m6.2	samba	2025-11-27
SUSE	SUSE-SU-2025:21005-1	SLE16	samba	2025-11-26
SUSE	openSUSE-SU-2025-20048-1	oS16.0	samba	2025-11-21
SUSE	openSUSE-SU-2025:15743-1	TW	sbctl	2025-11-19
SUSE	openSUSE-SU-2025-20128-1	oS16.0	shadowsocks-v2ray-plugin, v2ray-core	2025-12-01
SUSE	SUSE-SU-2025:4181-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	sssd	2025-11-24
SUSE	SUSE-SU-2025:21053-1	SLE-m6.0	sssd	2025-11-27
SUSE	SUSE-SU-2025:21066-1	SLE-m6.1	sssd	2025-11-27
SUSE	SUSE-SU-2025:4232-1	SLE12	sssd	2025-11-25
SUSE	SUSE-SU-2025:4183-1	SLE15	sssd	2025-11-24
SUSE	SUSE-SU-2025:4231-1	SLE15 SLE-m5.2 SES7.1 oS15.3	sssd	2025-11-25
SUSE	SUSE-SU-2025:4182-1	SLE15 SLE-m5.5 oS15.5	sssd	2025-11-24
SUSE	SUSE-SU-2025:4247-1	SLE15 oS15.6	sssd	2025-11-26
SUSE	openSUSE-SU-2025:0439-1	osB15	tcpreplay	2025-11-25
SUSE	SUSE-SU-2025:4195-1	SLE15 oS15.6	thunderbird	2025-11-24
SUSE	SUSE-SU-2025:21037-1	SLE-m6.0	tiff	2025-11-27
SUSE	SUSE-SU-2025:21032-1	SLE-m6.2	tiff	2025-11-27
SUSE	SUSE-SU-2025:21009-1	SLE16	tiff	2025-11-26
SUSE	SUSE-SU-2025:4184-1	SLE12	tomcat	2025-11-24
SUSE	SUSE-SU-2025:4159-1	SLE15 SES7.1 oS15.6	tomcat	2025-11-21
SUSE	openSUSE-SU-2025-20106-1	oS16.0	tomcat11	2025-11-28
SUSE	SUSE-SU-2025:21050-1	SLE-m6.0	unbound	2025-11-27
SUSE	SUSE-SU-2025:21065-1	SLE-m6.1	unbound	2025-11-27
SUSE	openSUSE-SU-2025-20099-1	oS16.0	xwayland	2025-11-28
SUSE	SUSE-SU-2025:2169-1	SLE12	yelp	2025-11-26
Ubuntu	USN-7899-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04 25.10	binutils	2025-12-01
Ubuntu	USN-7897-1	16.04 18.04 20.04 22.04 24.04 25.04 25.10	cups	2025-11-27
Ubuntu	USN-7878-1	16.04 18.04 20.04 22.04 24.04 25.10	cups-filters	2025-11-20
Ubuntu	USN-7878-2	25.04	cups-filters	2025-11-24
Ubuntu	USN-7894-2	22.04 24.04	edk2	2025-11-28
Ubuntu	USN-7894-1	22.04 24.04 25.04	edk2	2025-11-26
Ubuntu	USN-7890-1	16.04	ffmpeg	2025-11-27
Ubuntu	USN-7892-1	20.04 22.04	h2o	2025-11-26
Ubuntu	USN-7876-1	14.04 16.04 18.04 20.04 22.04 24.04	imagemagick	2025-11-20
Ubuntu	USN-7905-1	25.10	kdeconnect	2025-12-03
Ubuntu	USN-7877-1	24.04 25.04 25.10	libcupsfilters	2025-11-20
Ubuntu	USN-7896-1	14.04	libxml2	2025-11-27
Ubuntu	USN-7852-2	16.04 18.04 20.04	libxml2	2025-11-27
Ubuntu	USN-7874-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp	2025-11-19
Ubuntu	USN-7889-1	22.04 24.04	linux, linux-aws, linux-aws-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle	2025-11-25
Ubuntu	USN-7879-1	24.04 25.04	linux, linux-aws, linux-gcp, linux-hwe-6.14, linux-oracle, linux-realtime	2025-11-21
Ubuntu	USN-7906-1	25.10	linux, linux-aws, linux-realtime	2025-12-03
Ubuntu	USN-7879-3	24.04	linux-aws-6.14, linux-oracle-6.14	2025-11-26
Ubuntu	USN-7861-4	22.04	linux-aws-6.8	2025-11-19
Ubuntu	USN-7889-2	24.04	linux-aws-fips, linux-fips, linux-gcp-fips	2025-11-26
Ubuntu	USN-7874-2	20.04	linux-fips, linux-aws-fips, linux-gcp-fips	2025-11-19
Ubuntu	USN-7880-1	24.04	linux-oem-6.14	2025-11-21
Ubuntu	USN-7875-1	16.04	linux-oracle	2025-11-19
Ubuntu	USN-7887-2	24.04	linux-raspi	2025-11-25
Ubuntu	USN-7887-1	24.04	linux-raspi-realtime	2025-11-24
Ubuntu	USN-7889-3	22.04 24.04	linux-realtime, linux-realtime-6.8	2025-11-26
Ubuntu	USN-7879-2	24.04	linux-realtime-6.14	2025-11-21
Ubuntu	USN-7888-1	18.04 20.04 22.04 24.04 25.04	mupdf	2025-11-26
Ubuntu	USN-7873-1	22.04 24.04 25.04 25.10	mysql-8.0, mysql-8.4	2025-11-19
Ubuntu	USN-7883-1	18.04 20.04 22.04 24.04 25.04 25.10	openjdk-17	2025-11-25
Ubuntu	USN-7900-1	25.04 25.10	openjdk-17-crac	2025-12-02
Ubuntu	USN-7885-1	20.04 22.04 24.04 25.04 25.10	openjdk-21	2025-11-25
Ubuntu	USN-7901-1	25.04 25.10	openjdk-21-crac	2025-12-02
Ubuntu	USN-7884-1	22.04 24.04 25.04 25.10	openjdk-25	2025-11-25
Ubuntu	USN-7902-1	25.10	openjdk-25-crac	2025-12-02
Ubuntu	USN-7881-1	16.04 18.04 20.04 22.04 24.04 25.04 25.10	openjdk-8	2025-11-25
Ubuntu	USN-7882-1	18.04 20.04 22.04 24.04 25.04 25.10	openjdk-lts	2025-11-25
Ubuntu	USN-7898-1	24.04 25.04 25.10	openvpn	2025-11-27
Ubuntu	USN-7903-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04 25.10	python-django	2025-12-02
Ubuntu	USN-7886-1	14.04 16.04 18.04 20.04 22.04 24.04	python3.12, python3.11, python3.10, python3.9, python3.8, python3.7, python3.6, python3.5, python3.4	2025-11-24
Ubuntu	USN-7886-2	25.04 25.10	python3.13	2025-11-26
Ubuntu	USN-7851-2	22.04 24.04 25.04 25.10	runc-app, runc-stable	2025-11-24
Ubuntu	USN-7891-1	20.04 22.04 24.04	rust-openssl	2025-11-26
Ubuntu	USN-7855-2	22.04 24.04 25.04 25.10	unbound	2025-12-02
Ubuntu	USN-7893-1	24.04 25.04 25.10	valkey	2025-11-26
Ubuntu	USN-7895-1	22.04 24.04 25.04 25.10	webkit2gtk	2025-11-27

Full Story (comments: none)