Welcome to the LWN.net Weekly Edition for September 17, 2026

This edition contains the following feature content:

• Ways to encrypt data on servers: a FOSSY talk on the why and how of encrypting data on servers.
• PostgreSQL 19's "scary patch contest": the PostgreSQL 19 release is delayed due to some patches that have not really stabilized yet.
• Accelerating the kernel's build process: some LLM-assisted changes that result in a significant speedup for kernel builds.
• Adding BPF to blk-iocost: a way to allow BPF programs to decide on the cost of I/O operations for the blk-iocost control-group controller.
• Lessons learned as the Debian Project Leader: Andreas Tille was the Debian Project Leader for two years and related what he learned at MiniDebConf Winterthur.

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)

Ways to encrypt data on servers

At the 2026 edition of FOSSY, Romeo Solano gave a fast-paced, humorous presentation on what could have been a rather boring topic: server encryption. There are a number of threats that we face in today's world, from criminals, government overreach, espionage, and more, that can be thwarted with encryption. But encrypting data on a system that may live elsewhere, without any access to its keyboard at boot time, is rather more difficult than encrypting the disk of a laptop. Solano described the problems and gave a tour of some of the solutions in the talk.

The goal of the talk was to show attendees how to encrypt the data on their servers and to describe why they should do so. Encrypting the data at rest requires that the data be decrypted when the server is running, so he would be talking about how to do that at boot time, no matter whether the server was in the same room, another room in the house, or elsewhere on the globe. "You'll be able to accomplish this whether or not you can trust your hosting provider to lend you a helping hand."

The password prompt used when logging into a computer does "about as good a job at preventing access to your files" as a speed limit sign does to prevent speeding, Solano said. On the other hand, the disk-encryption-password prompt, "which looks incredibly similar but is slightly different", does actually prevent file access unless the decryption key is provided.

Encryption

Cryptography uses advanced math "beyond the understanding of most mortal humans, including myself". But that does not matter, users can still take advantage of cryptography without knowing or understanding the math underlying it. Because of that, it has become "standard operating procedure" for people to encrypt their computers and phones, especially for technical people like those in attendance at the talk (and the conference). "Why wouldn't my disks be encrypted at rest?"

It is more than just the risk of loss or theft, but to "protect against an increasingly snoopy and wants-to-know-everything-your're-doing international violence monopoly". It is a matter of course for many to power down their laptops and phones, thus encrypting their data, when going through a border checkpoint, for example. But much of the data users want to protect does not live on those devices, it is on a server somewhere.

When the server loses and regains power or needs to be rebooted for an urgent security update, though, the administrator may not be nearby to enter a password into the disk-encryption prompt. Maybe they are away on vacation; "I'm sorry honey, we have no Jellyfin for the next two weeks" is kind of a hard sell, he said. This is one of the reasons that people often leave their servers unencrypted.

The other main reason to not encrypt server data is because of a "real, tangible, potential performance impact" on reads and writes of data on encrypted disks. He showed numbers of 656MB per second versus 147MBps for the encrypted disk, which came from a 2020 Cloudflare blog post. The technical lead for the company, Ignat Korchagin, was looking into this performance degradation and found that a write to an encrypted filesystem ends up waiting in four separate queues before it reaches the disk. He patched the kernel to avoid that queueing and was able to get close to the same speed for unencrypted (696MBps) and encrypted (640MBps), though.

Those patches are part of the upstream kernel, so they can be enabled by anyone, Solano said. Those improvements only come for small I/O sizes, however, and performance can be even worse for large I/O. Each person needs to decide if the increased data security is worth the reduced performance; for him it is, but others may differ.

Threat model

It is unlikely that most users are facing movie-style heists in the data center, with people rappelling from the ceiling to grab servers or disks; "there's no laser beams or guard dogs". The real threat model that disk encryption is meant to thwart is someone taking a disk or server from the data center or a home lab. That means they now have the data—unless it is encrypted.

That threat may sound far-fetched, Solano said, but it happens frequently to small, community-run servers that are open to the public when a single person who uses it is accused of a crime. The police or other law-enforcement agencies confiscate the server for lengthy terms with little or no information about alleged crimes. It has also happened to regular people with their own servers that only they use; "they've had their homes ransacked and their equipment stolen", which lasts for years without any kind of charge being made. "This happens to the kind of people at FOSSY; this could happen to you."

There are other kinds of attacks, including cold boot attacks to recover encryption keys from the memory of a shut-down system. There are also evil maid attacks that swap out some hardware or software in the system, which allows the attacker to capture the decryption key. Those are real attacks, but they are "incredibly rare", targeted efforts that are outside of the scope of his threat model for the talk.

He reiterated that each administrator needs to decide for themselves whether encryption on the server makes sense for them and their users; he feels like he has a responsibility to protect his users' data, so the tradeoffs are worth it.

Key handling

There are ways to avoid the "inconvenience factor" of needing to provide the decryption key when the system restarts, so the trip to the data center—or even just down the hall to the server—can be eliminated. The first is "the worst possible method", which is a service called "remote hands" that most hosting providers offer; essentially it allows the use of the hands of an on-site technician, who can perform various tasks, including typing in a password. The dangers of that "should be immediately obvious". For one, the technician (and hosting company) have much less interest in keeping that key secure against bribery, theft, legal threats, and more; for another, many people have their server in a lab at home where there is no friendly technician available at all times.

A more desirable mechanism would be a way to remotely attach to the server system and type the password in. Server-class hardware generally has an extra network port, often labeled "IPMI" (for Intelligent Platform Management Interface). Connecting that to the local network, and creating a VPN connection to it, will allow accessing the system remotely, including its console, via a web browser. It is not a new technology, Solano said, but one that may not be all that well-known, especially among those with home labs.

The IPMI web server is running on a separate chip inside the system, not on the main CPU. That code only gets security updates infrequently, so it is important to have the VPN tunnel rather than exposing it on the internet. Hosting providers may not be willing or able to set that tunnel up—or they may promise that they can and then not actually do it for more than a year. "I don't know anything about that", he said with a sigh.

It would be even better to be able to use SSH to reach the server, but there is a chicken-and-egg problem in the way. The SSH daemon is normally on the root filesystem, which is encrypted and awaiting the decryption key from the console prompt. One solution to that is to use Dropbear SSH and to run it from the initial RAM disk (initramfs), which is the same place that the decryption-key console prompt is running from.

Depending on whether you believe the project's README file or its web site, Dropbear is "either 'smallish' or 'relatively small'". It lacks many of the features of the standard OpenSSH server, but "it is a lot smaller, and it's statically linked, it has no dependencies" so it can be easily placed in the initramfs. On Ubuntu systems (which is what he was using for his examples), it simply requires adding two packages (dropbear-initramfs and busybox-initramfs), modifying two configuration files, and doing a little more setup. The result is a system that allows SSH-key-based logins resulting in a BusyBox shell where the cryptroot-unlock command can be used to provide the disk-decryption key. Solano's talk notes have more information on setting up Dropbear in this fashion.

He uses both the IPMI virtual console and Dropbear solutions and likes them both—at least when he can get the VPN tunnel needed. Those mechanisms have something in common, though: they require that the administrator is available to type in the password. They cannot be asleep, hospitalized, or simply being inattentive to their systems because the system will not boot until the password is entered.

Unattended

It would be nice if there were an unattended solution where the server would only decrypt its disk if it is in a known safe state, but it would stay encrypted in the "cold, offline attack scenario that we are trying to protect against". As might be guessed, that is possible, by using two tools called Clevis and Tang, which are named after a two-piece fastener used in towing and farming, he said.

In the cryptography world, Tang is the server side that runs on some other internet host, while Clevis is the client side that runs from the initramfs as with Dropbear. Using Tang might sound like handing the key off to a remote technician, as mentioned earlier, but it is not. Tang does not know the key, nor does Clevis. He put up a slide (from his ODP slides) with a complicated-looking formula; "the way that it works is incredibly simple for some people, I am not some people", he said with a chuckle.

In order to explain, he used his cat and himself as metaphors for Tang and Clevis, respectively. When the two of them come together, because his cat jumps in his lap, say, they create a globally unique "shape" that corresponds to the decryption key. A different human or a different cat creates an entirely different key. Beyond that, Tang does not store anything about the encryption key (e.g. fingerprint) or retain any state about the Clevis on your system. "It's completely stateless, completely anonymous, no logs, no records, nothing, at least by default."

A single Clevis can use multiple Tangs, either individually or in groups. So a Clevis could require N Tangs in order to provide the disk-decryption key, for example. Installing Tang just requires a single package; it will run a server that listens on port 80, which is all that is needed. Clevis requires three packages and a command to bind a disk encrypted using Linux Unified Key Setup (LUKS) to the Tang server. Periodically, the Tang keys should be rotated, which can be done with a single command on the Tang server and another on the Clevis client. Once again, his notes provide more details.

Clevis and Tang can be used for more than just LUKS keys; they provide a general mechanism to derive secrets without storing the secret, which makes it different from what key escrow, or friendly technicians, require). In addition, Clevis can be bound to the Trusted Platform Module (TPM) chip. He personally does not trust the security of the TPM and is concerned that placing the disk-encryption key into a device on the system could result in key disclosure if there is some TPM exploit someday. But, "if you want to trust your TPM, Clevis has you covered."

Encrypted directories

The solutions he presented so far were all based on fully encrypted disks, where the root partition and everything else was protected. That is the way that all of his systems are set up, but it may not be realistic for every scenario. For example, the system may need to stay up, so it cannot afford the downtime required to encrypt it or it could be storing a huge amount of data that, due to storage costs, is too expensive to duplicate in order to encrypt it. In addition, virtual private server (VPS) systems from hosting providers may not provide a mechanism to encrypt the disks. For situations like those, other encryption options may make sense.

For example, Ubuntu has provided an installation option to encrypt a user's home directory for over 12 years. The regular user password is also the decryption key for the directory. It uses eCryptfs, which is unmaintained and will probably be deprecated soon, Solano said. It has been replaced with fscrypt, "which does the same exact thing, except that it doesn't have a cool logo or a mascot". It does, however, have a maintainer, which is probably more important.

Fscrypt is easy to set up as well. On ext4, the tune2fs command can be used to turn on encryption for the filesystem. Once that is done, the fscrypt command allows encrypting specific directories on the filesystem. There are other fscrypt subcommands to lock and unlock the encrypted directory; that can be scripted to run at login time, for example. "You can even have it reach out to Clevis and Tang to derive a decryption key" and handle it all automatically. Fscrypt is only available on a few filesystem types, but there are equivalent features on other filesystems, such as XFS and ZFS, he said.

Another option is using systemd-homed to create block devices that are "space-limited, encrypted, portable, even, across filesystems and servers". Each directory that systemd-homed creates is associated with a new user account that can handle the encryption needs for the system. At that point, Solano was running out of time, so he referred attendees to his talk notes.

After a summary conclusion of the talk, it turned out he had a bit of time for questions. One was: If the "men in black" take a server running Clevis, can't they just have it contact the Tang server to construct the decryption key? The answer is that they can do so as long as the Tang server(s) are still running and are willing to reply to the Clevis client running in a new location. Various levels of protection can be applied such that Tang servers only reply to certain IP addresses, or over certain networks, which could thwart Clevis operations from the captured systems.

In just a little bit over half an hour, Solano took a bit of whirlwind tour through the encryption options available to server administrators. Interested readers can view the video (minus the short Q&A).

[I would like to thank the Linux Foundation, LWN's travel sponsor, for its assistance with my trip to Vancouver for FOSSY.]

Comments (38 posted)

PostgreSQL 19's "scary patch contest"

PostgreSQL 19 was expected to be released in September, in keeping with the database project's longstanding tradition of a major release every year. However, some late-breaking concerns about several of the features slated for inclusion has some developers worried about the quality of the release. On August 25, PostgreSQL contributor Robert Haas sent an email with the subject "scary patch contest" about several patches that have required an unusually large number of bug fixes leading up to the release, which has raised questions about their readiness for a stable release. One of the patches has been reverted, but several are still under heavy revision, and an extra beta release has been slotted in to allow for additional testing.

Scary patches

Development on a major PostgreSQL version begins more than a year before its expected release date; the first CommitFest to review patches for PostgreSQL 19 was held during July 2025, and the first for version 20, which is expected in 2027, was held in July 2026. A release enters feature freeze several months before the final release is scheduled to allow time for the project to publish pre-releases for testing and to fix any bugs found. Typically there are three beta releases released by August, and then a release candidate in late August or early September, with the stable ("GA") release in late September. PostgreSQL 19 entered feature freeze on April 8—the project has been working since to stabilize the final release.

That stabilization phase seems to have involved more bug fixing than usual. In his scary patch email Haas said that he "asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed post-freeze", and then shared the results "with a few particularly cutting remarks from the LLM edited out". There were several patches that had seen heavy revision after the feature freeze that Haas felt might be in bad enough shape to merit reverting before PostgreSQL 19 shipped, though he did not have a firm position on what to do.

"I think it's pretty clear that none of these were as robust at commit time as we would like, but that doesn't mean that they're still broken." He believed that some of the patches identified by his LLM inspection were low risk, "because they are only going to come up in fairly niche situations", but he worried that some of them could have "a long tail of bugs that we haven't found yet, in pretty critical areas".

One of his examples was a pair of patches from Amit Langote and Junwang Zhao designed to speed up PostgreSQL's foreign-key checks. The first patch provides a way to speed up foreign-key queries by bypassing the usual method of using PostgreSQL's Server Programming Interface and, instead, doing a direct index scan for foreign keys. The second patch builds on that to add batching. According to Haas's email, the two patches had required about 16 fixes after feature freeze, including "five distinct classes of incorrect [foreign key] enforcement (cross-type, domains, column order, nullable keys, non-btree indexes)" and a redesign of the feature's transactional model after the freeze.

Langote said that he had reviewed the fixes made since feature freeze; he was persuaded that the concerns about the batching code were justified and "considerably more concerning" than the per-row fast-path fixes. He acknowledged that both patches had required a number of fixes after the freeze, but the fast-path changes did not have "the same pattern of complexity as the fixes needed to manage the lifetime of batched checks". He sent patches to remove the fast-path batching from PostgreSQL 19, though leaving it in the PostgreSQL 20 development branch, while keeping the per-row fast path intact. On September 8, he promised an updated patch to deal with some comments from Amit Kapila about problems in the first patch to revert the batching feature.

Haas said that he generally agreed with Langote that "the batching stuff feels much riskier than the per-row fast path stuff". He was not entirely sure, though, that the batching patch was in good enough shape to keep for PostgreSQL 20, or that the per-row fast-path patch was good enough to keep in 19. "I think we should do at least as much as what you're proposing here, but possibly more. However, I'm not very sure what the right answer is at this point." For now, the per-row fast-path patch looks as if it will be included in the upcoming beta release.

Two patches contributed by Antonín Houska, and committed by Álvaro Herrera, were also identified as worrisome. The first patch adds a REPACK command to PostgreSQL, with a second patch that implements an option (CONCURRENTLY) for the command. Haas said that the two patches had a cumulative total of 28 bug fixes since the feature freeze, "including data loss [...] and two security-flavored ACL [access-control list] fixes". There is at least one outstanding patch for the CONCURRENTLY option that is still being discussed, which would disallow the use of REPACK CONCURRENTLY on user catalog tables.

Haas said he was most concerned with the two sets of patches described above as well as one from Daniel Gustafsson and Magnus Hagander that allows data checksums to be enabled or disabled in a running PostgreSQL cluster without restricting access to the cluster during processing. Before this patch, enabling or disabling data checksums was only possible as an offline operation. According to the LLM analysis, the patch had required about 25 "substantive fixes" since feature freeze, including false checksum failures. "A corruption-detection feature producing false positives is exactly the wrong failure mode." Gustafsson replied that he would prepare a revert for the feature.

The intent, Haas said, was not to jump straight to reverting the patch: "My sincere intent was to start a conversation, not jump straight to a conclusion." If Gustafsson was already considering reverting the patch then it might make sense to do so, but otherwise Haas was just looking to discuss the patches.

Since then, Gustafsson has continued to work on the feature. On September 4 he addressed the case for reverting the feature and noted that he had posted a patch to revert the feature "to give anyone interested a chance to see what it would look like, and what I propose leaving behind in v19". For now, it seems that the data checksums feature will be in the next beta. Whether it survives to the GA release remains to be seen.

LLM effect

PostgreSQL 19 release management team member Melanie Plageman said that she was not sure if there was consensus that Gustafsson's patch needed to be reverted. She also wondered "if the ease with which LLMs allow people to pressure test features means we are finding more bugs sooner than we have in the past." Nathan Bossart, also a member of the release-management team said that he had thought use of LLMs would make new features more stable by feature freeze, "but it seems that that hasn't turned out to be the case".

However, Haas replied to Plageman that he was not convinced that the problem with Gustafsson's patch was as simple as finding more bugs with LLMs. He was unsure what the right course of action was; it might be fine if the remaining bugs "have few architectural implications and can likely be cleaned up in a minor release without causing much trouble". But he expressed concern that there could be remaining bugs that would not be easily fixed in a point release without bumping the catalog version ("catversion" in PostgreSQL parlance): in other words, making a change that would cause a database created with PostgreSQL 19.1 (for example) to be incompatible with 19.0.

Gustafsson noted that most of the large features in PostgreSQL 19, "were written, reviewed and tested, before AI tools were either available or even remotely as good as they are now". He thought it would be a different story when the feature freeze rolled around for PostgreSQL 20. Kapila agreed, and suggested that LLMs would be good for long-term stability of the project, even though the project was seeing more post-freeze fixes this time around.

LLMs may be better at spotting bugs, but having more time helps as well. Haas observed that all of the features that have had a large number of bug fixes post-freeze were committed close to feature freeze in April. He suggested that "there's a good chance that they would have had most of the bugs flushed out by now" if the features had been committed to PostgreSQL's master branch in August 2025.

PGQs pulled

PostgreSQL core team member Tom Lane said he was "quite afraid" of another patch from Haas's list, an implementation of SQL property graph queries (PGQs) by Peter Eisentraut and Ashutosh Bapat. That feature had seen 17 bug fixes that Haas had characterized as lower severity. Lane worried that the project was still discussing fixes for the feature that might cause a catversion bump. "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20."

Haas said, without taking a stance on that particular patch, that no feature that requires a catalog version bump belongs in PostgreSQL 19 at this point. "The time for working out what the catalogs should look like was sometime well in advance of feature freeze, not four months after it".

On September 2, Plageman said that the release-management team had been looking at the current state of the PGQ patch and had "serious concerns about the number of design issues with either recently posted patches or without consensus on behavior". She said that the team felt it would be better to revert PGQ for 19, and fix things properly in time for 20, "without having to be burdened by backwards compatibility and backpatching". Eisentraut agreed and PGQ was ultimately backed out of both PostgreSQL 19 and the master branch. Whether it will resurface in time for PostgreSQL 20 is unclear.

Andres Freund said he was worried about the patch from Paul A. Jungwirth, committed by Eisentraut, that extends PostgreSQL's UPDATE and DELETE commands to add a "FOR PORTION OF" clause to work with temporal tables. (Hubert Lubaczewski has a good blog post that explains the new features.)

Haas said that Jungwirth's patch had 17 fixes, including three security fixes, that had to be addressed after freeze. Freund said that several of the bugs seemed fairly obvious. "Not recognizing & testing some complicated interaction, race conditions, etc. are one thing, but the oversights here seem to be pretty ... broad." He felt that this patch was on the high-risk side because the feature was available to users with relatively low privileges, which meant an attacker did not need to have superuser privileges to do "something intentionally adverse".

Jungwirth reported that Noah Misch had found an additional set of bugs in his FOR PORTION OF feature, "with some LLM investigation". He later said that he had also received a report of a memory leak from Tomas Vondra off list. Between Misch's and Vondra's additional reports, the bug count for Jungwirth's patch is now north of 30 since the feature freeze, and there may be others. So far, there has been no indication it will be removed.

Unprecedented situation

Core team member Bruce Momjian expressed concern about reverting patches like Gustafsson's: "We are in a situation where we might be reverting multiple big features, and we don't even know if their removal will affect other changes that were made assuming those feature existed". He said another beta release would be needed and that it felt like the project was in "an unprecedented situation". Jonathan S. Katz announced the extra beta to be released on September 24, and the release candidate and stable release dates are still unknown.

On September 7, Joshua Drake said that with the number of reverts under discussion the confidence in the release would be lower, whether the features were actually reverted or not. He proposed shifting the release to spring 2027. That would allow more time for testing and remove what he considered a "long-standing issue with the development cycle": the fact that PostgreSQL's testing window takes place during summer (and presumably vacation season) in the Northern hemisphere.

He argued that none of his customers had told him they needed PostgreSQL 19: "most people don't even run 18 [yet] so why are we in such a hurry?" He would rather have 19 ship late than for "all these great features and hard work [to be] gutted". So far, no one has responded to the idea of shifting the release to next year.

It seems most likely that the developers will try to get the release out as close to the original schedule as possible. The project hasn't put out a fourth beta release in recent memory, so it's unclear how many weeks it will allocate for beta testing—at least two weeks seems likely. The stable release is usually two to three weeks after the release candidate, so it seems there's a good chance that PostgreSQL 19 will slide into November even if all goes well from here.

Comments (8 posted)

Accelerating the kernel's build process

Kernel developers do a lot of kernel builds. Since the kernel is not a small program, those builds can take a fair amount of time, even on a fast machine. The kernel also has a complex build system; it is probably fair to say that few developers truly understand it, and fewer still are willing to try to improve it. Lorenzo Stoakes, armed with LLM-based assistance, decided to give it a try, though, and has managed to reduce the time it takes to build a kernel — and not by a small amount.

In the cover letter to his 23-part patch series, Stoakes described his tool use for this work:

An LLM was used to first determine where the bottlenecks were then to figure out how to improve them.

It generated a lot of code, much of it hideous.

I extensively audited and rewrote a lot of it, and heavily edited commit messages, the cover letter and comments.

The results of this work were summarized as "allmodconfig builds up to 36% faster, incremental builds up to ~70% faster, and noop builds up to ~90% faster".

How to accelerate kernel builds

Getting to that point required a lot of changes to the build process. Consider, for example, the kallsyms program, which runs during the build to create a table of all of the symbols (function and variable names) in the kernel. There are a lot of symbols, so this table can be large. Since the table can reside in memory, there is a strong incentive to make it smaller; kallsyms thus implements a special compression algorithm, described this way in the source:

Table compression uses all the unused char codes on the symbols and maps these to the most used substrings (tokens). For instance, it might map char code 0xF7 to represent "write_" and then in every symbol where "write_" appears it can be replaced by 0xF7, saving 5 bytes.

As Stoakes (or his LLM) observed, though, kallsyms performs this compression in a highly inefficient way, trying to perform each token replacement in every one of over 150,000 symbols, even though any given token will only appear in a small subset of them. This patch from the series tracks which tokens appear in which symbols, so that substitutions are only attempted in places where they will succeed. This change alone speeds kernel builds by 2-6%.

Even then, though, kallsyms outputs its table as a 37MB assembly-language file that must then be passed to the assembler to be turned into binary data. This patch causes kallsyms to output the binary data in a form that the assembler can pull in directly, reducing build times by up to 11% in the best case. Linus Torvalds applauded this change, but suggested that it could go further: kallsyms could simply output an ELF object, taking the assembler out of the picture entirely. Nobody, he suggested, would normally want to write the code needed to make kallsyms behave that way but, since an LLM is involved, "the obvious step would be to just ask the little helper bot to switch the whole kallsyms to using libelf-devel and writing an object file directly".

The build process uses the nm tool at various stages to query the contents of object files. The output from nm is sorted by default, but the build process rarely needs sorted data. This patch disables the sorting when it is not needed, improving build times by another couple of percentage points. In another patch, the various intermediate linking stages are changed to not emit relocation data, which is unneeded at that point, again improving build times by 2% or so.

Sometimes, though, the use of nm can be avoided altogether. The build process currently runs that tool on kernel objects, feeding the output to the mksysmap sed script to create data suitable for feeding to kallsyms. This patch replaces that script with new kallsyms code that reads ELF files directly and extracts the needed data, bypassing nm entirely. In the best case, this change improves build times by 12%, though the improvement seen in most cases is significantly more modest. Another modest improvement is had by not allocating the .modinfo section in the kernel image. This patch, which caches information about whether each object file is part of a module, speeds build performance, especially in larger directories.

The kernel contains a lot of header files, with the result that object files can have a huge number of dependencies. The make utility, it seems, spends a lot of time checking these dependencies in a single-threaded mode, slowing down the build, especially in cases where little has changed. This patch adds a new utility, called depcheck, that performs dependency checking in a more efficient way, taking care to only stat() each file once. This change may not last, though: Torvalds suggested that much of the trickery used to make dependency checks work properly may no longer be needed: "That whole thing is from a quarter century ago, and nobody has dared look at that code since". So the better solution might be to just remove it entirely.

Then, there is this patch, which aims to reduce the number of times that the build process invokes the compiler to probe whether a specific feature is supported. The compiler and its supported options do not change over the course of a kernel build, so it makes sense to remember which options are supported after querying them once. A new set of configuration options is added as a way of remembering and testing that information.

The modpost tool postprocesses symbol versions in loadable modules; that work involves calculating a lot of MD4 hashes. In current kernels, the data to be hashed is accumulated one byte at a time; this patch does the hashing on a per-file basis, yielding a build-time improvement of up to 6%. However, this functionality is being removed from modpost, so this change will be dropped from the series. This patch adds more caching to modpost, reducing build times by up to 12% in some cases. Finally, modpost generates a C file containing a descriptor for each module it handles; that file must then be compiled into an object file. As described in this patch, the resulting overhead is not small:

These files are compiled like any other kernel C file with all of the -include preamble, as well as including linux/module.h, header dependencies generated by fixdep of a few hundred headers, an objtool run and if LTO is being performed, a link is performed to generate native code.

On an x86-64 allmodconfig build 11,189 *.mod.c files are built, each taking ~0.24s of CPU time to compile, and module finalisation as a whole 6,300 CPU seconds, or 64 seconds of wall time when run over 128 threads.

Changing modpost to output assembly code, thus avoiding the compiler step, removes this overhead, speeding an allmodconfig build by 11% (and no-op builds by much more). Nobody will complain about an improvement like this but, again, Torvalds suggested that an even better approach would be to generate the object file directly and remove the assembler from the process as well. Beyond any speedups, he said, that change would remove the .mod.c files from the build entirely.

Other changes include this patch, which causes the finalization step at the end of each module build (which runs in milliseconds for any given module) to be batched, overcoming the inability of make to dispatch thousands of little tasks efficiently. Another patch parallelizes the hashing of files in modpost. There is a rather more complex patch that adds parallelization to the objtool utility, with large effects on some builds.

Then, there is the matter of Rust. Currently, the kernel's Rust crates are compiled serially, one at a time. That slows the kernel build considerably now, and will only slow things further as the amount of Rust code grows. This patch uses the -Zthreads option to rustc to build the crates in parallel; that option was added in Rust 1.84, which is (slightly) older than the minimum version (1.85) required by the kernel. The patch will also attempt to use the future --jobs option if it is available. Björn Baron warned, though, that parallel builds in rustc have not fully stabilized, so it is not clear that this mode should be used by default. This other patch, which allows Rust code to be built in parallel with the building of C code, should be rather safer.

The final patch in the series causes the build system to use pigz to compress the kernel if it is available. pigz is able to perform compression in parallel, significantly reducing the time required to complete this step.

In summary

See the plot (above) for another look at how these patches affect kernel-build times. All told, they add up to a significant reduction in the time required to build a kernel. It seems unlikely that developers will complain much about that. As long as they do not introduce build problems (and only the parallel Rust change appears to have any risk of doing that), there should not be much opposition to their merging.

Naturally, it was necessary to try it out. On my system, which is better suited to article writing than fast builds, a full kernel build with an empty ccache reliably takes about 960 seconds. With this patch series applied, that time drops to about 860 seconds (both are wall-clock time, the CPU-time numbers are quite a bit higher). That is roughly a 10% decrease in build time. The clean-ccache case was chosen because it is easily reproducible, but it is also dominated by actual compile time and is the scenario likely to show the least improvement. With a fully populated ccache, the patches made a difference of a few seconds in a roughly 90-second build.

At any given time, there must be an impressive number of machines performing kernel builds all over the planet. Developers will be running some of those, but there are probably far more in the many continuous-integration systems that are running. So build-time improvements may save more than developer time; they will reduce the carbon impact of the development process overall. This work, it seems, should have been undertaken long ago. One wonders what other savings may be waiting for a suitably motivated developer to take a close look.

Comments (82 posted)

Adding BPF to blk-iocost

The scheduling of block I/O requests has long been a challenge for operating-system kernels. For many years, the performance characteristics of rotating drives meant that putting considerable resources into request ordering was worthwhile. In a world with fast, solid-state drives, scheduling is more concerned with enforcing fairness between competing users while being fast enough to keep up with drives that can perform millions of I/O operations per second. The blk-iocost I/O controller was designed for the solid-state world and generally performs well, but there is always a desire to do better. This patch series from Tao Cui aims to make blk-iocost more flexible by enabling the loading of a BPF program to make cost decisions.

The blk-iocost controller was first covered here in 2019, when it was still known as "io.weight"; it was revisited in 2024. To summarize, it works by allocating a percentage of a block device's bandwidth to each control group. Every requested I/O operation is then evaluated and an associated cost, expressed in terms of how much of the device's time the operation is expected to take, is assigned. Each device has a virtual clock ("vtime"), as does each control group; executing an I/O operation advances the requesting group's vtime by the assigned cost. Operations are only dispatched to the device when the group's vtime is far enough behind the drive's vtime to accommodate them.

See this paper for more details on how blk-iocost works. One key point is that its operation is split into two parts. The calculation of the cost for each operation uses a number of pre-computed parameters in order to be as efficient as possible and not slow down the I/O operations themselves. A separate "planning" phase, which runs every few milliseconds, adjusts the weights of all of the control groups in order to reallocate bandwidth from groups that are not using their full allocation to others that are more busy. The planning phase also tweaks the rate at which the drive's vtime advances in an attempt to keep the drive fully busy — but not so busy that response time begins to suffer.

Cui's cover letter describes how the current cost model works and its shortcomings. To summarize: requests that are deemed to be sequential are assigned a relatively low cost, while those that look random are assigned a much higher (112x) cost. Sequential access is faster, even on solid-state drives, so a group that is performing mostly sequential operations should be entitled to more of them than groups performing random operations.

The problem, Cui says, is that the heuristics for determining the randomness of any given request do not work well for all workloads. A group that has two processes performing sequential operations can, if those operations are interleaved, appear to be doing random I/O; the controller will penalize that group, causing its I/O performance to suffer. Meanwhile, random operations within a sufficiently small window can be judged to be sequential, leading to an unfair boost for the relevant group. Additionally, some devices can behave differently depending on the type or the placement of an I/O operation, but blk-iocost does not take that into account. Given the range of devices and technologies out there, it may not even be possible for a single, general-purpose controller to take all of the relevant factors into account.

The solution, as always it seems, is to enable the loading of a BPF program so that the cost calculation can be customized. Cui's patch set only addresses the cost-calculation part of the controller; the planning portion is unchanged.

Specifically, the series enables the loading of a new type of struct_ops program built around this structure:

    struct iocost_model_ops {
	u64 (*calc_cost)(u64 opf, u64 nbytes, sector_t sector,
			 struct blkcg *blkcg, u64 model_flags);
	void (*blkcg_online)(struct blkcg *blkcg);
	void (*blkcg_offline)(struct blkcg *blkcg);

	/* model name, used to select the model through io.cost.model */
	char name[16];
    };

The core of this structure, and the only required operation, is calc_cost(), which calculates the cost of an I/O request. The opf parameter is a set of flags describing the request, including whether it is a read or a write, whether a cache flush is needed, and so on. nbytes is the size of the request, sector is the location of the desired blocks on the drive, blkcg is the block control group that controls the requesting process, and model_flags may contain a single flag, IOCOST_COST_F_MERGE, indicating that the current request is being merged into another that already existed. The return value is the cost that will be assigned to this request.

The other two functions, blkcg_online() and blkcg_offline(), are optional; if they exist, they will be called when this controller is added to (or removed from) a control group, allowing the BPF program to manage any housekeeping it may need. Loading the program does not, in itself, attach the new cost function to any devices; that is done by writing to the io.cost.model file in the control-group directory using the name provided in the iocost_model_ops structure.

Included in the patch set is an example program that attempts to improve performance for control groups that contain multiple processes performing sequential I/O. It uses a BPF map to keep track of each I/O stream that it observes; if a request looks sequential within any of the tracked streams, it is charged as a sequential request. The example program is able to track up to four independent streams, though the number of streams actually tracked will be lower if there is also random I/O being done.

This is still early-stage work, in its third RFC revision. The interface has evolved considerably since the posting of the first version on September 8. So it would not be surprising to see further changes before this feature is merged. Eventually, though, a version of this work does seem likely to be accepted, adding yet another place where BPF can be used to modify the operation of a core kernel subsystem.

Comments (none posted)

Lessons learned as the Debian Project Leader

What is it like to be a Debian Project Leader (DPL), or a former one? According to Andreas Tille, who stepped down this year after two consecutive terms as DPL, you'd have to be one to know. At the recent MiniDebConf in Winterthur, Switzerland, Tille spoke about what he learned while serving as DPL, some of the initiatives he led, mistakes that he made, and his thoughts on the general resolution (GR) on large language model (LLM) usage in Debian.

I did not have the opportunity to attend the MiniDebConf in person, but I watched the video of the session shortly afterward. The slides are also available, as are the slides and videos for many of Tille's talks back to 2001.

A short changelog

Tille said he was often asked what it feels like to be a former DPL. The only way to find out is to do it—and he hoped that a future DPL was sitting in the audience. "I can recommend it. It was less demanding than expected. So just try it, and then you will know." His wife had told him that he had also developed as a person while being DPL, "and I take this as a compliment".

He wanted to start with "a short changelog" of some of the projects he had worked on during his tenure. One of the things he wanted to do as DPL was to attract newcomers to become Debian contributors. He began a Bug of the Day program to train new people to triage and fix bugs, with a web page that lists one or more bugs that might be good candidates for inexperienced people looking to become contributors.

It was an interesting project, Tille said, that helped him learn a lot about Debian, such as the need to address social and cultural issues as well as technical ones. "I felt like a janitor taking a torchlight in the cellar and looking for things that needed clean up [...] and I learned way more than expected myself. And what I learned is that doing something and talking to people is essential for the process". The need for the DPL to spend a lot of time talking to people was a recurring theme in the talk.

Archive and DFSG teams

Tille said that he had spent "a lot of time in video conferences" talking to contributors about the ftpmaster team, which was responsible for two distinct tasks. The team was responsible for both the technical work of caring for the servers and software used in the process of bringing packages into Debian's archive, as well as the non-technical work of ensuring that packages entering Debian's new queue met packaging requirements, including the Debian Free Software Guidelines (DFSG).

"We called it the new queue, but actually it was a new heap", he said. Debian developers had complained for many years about long wait times for packages in the new queue to be reviewed and approved. Tille said that there was "a hint that was born inside the team to just split the distinct tasks", which is what happened.

"Splitting up a core team right before a stable release is not a good idea", Tille said. He waited until a few months after Debian 13 ("trixie") was released to split the ftpmaster team into two new teams. He created the Archive Operations Team for the technical job of managing the infrastructure, and the DFSG, Licensing, & New Packages Team (DFSG team) to do the non-technical job of reviewing packages entering the new queue. He said that the separation of teams has led to faster processing of the new queue and a more transparent system. LWN covered Andrew McMillan's report on the DFSG team's progress in July.

How to step back

Something unusual happened during Tille's term that he wanted to highlight: all three members of Debian's Data Protection Team said that they no longer wished to do the work and quit, which led to an urgent call for new members. The interesting thing about this was that they actually said that they no longer wanted to do the job. "I think the very good thing, and not so typical thing, was that the data protection team told the world that they will not do their job anymore."

Debian is a volunteer organization, and people step up to do a task but then their circumstances change. People have valid reasons for stepping back, but then fail to tell their teammates that they are no longer available. By announcing they wanted to quit, the team enabled a smooth handover to a new team that is now doing the work.

That led Tille to thinking about how delegations are handled within Debian. Typically, a delegation to a team has no time limit attached—it is valid until the DPL revokes it or a person announces that they are stepping down. But, he said, people are reluctant to tell their friends that they are unable to do a task any longer. Stepping down from a position, "is an active process from a person who is burnt out" or otherwise in need of a break.

Tille thought that it might be better to ask delegates if they are still interested in remaining on a team. It would be easier for them to say "no" when asked, rather than proactively stepping down. He raised the idea of time-limited delegations in February 2026 in one of his regular "Bits from the DPL" emails.

In some internal discussion people have raised the question of how Debian should deal with delegates becoming inactive, and how to do so in a way that is both effective and non-confrontational. I have read multiple thoughtful suggestions that converge on a common theme: we should normalize renewal and rotation, rather than treating changes as exceptional or adversarial events.

Tille said that he did not receive any responses about the idea, so he thought there was consensus that it was a good one. Tille asked incoming DPL Sruthi Chandran if it was acceptable to make all delegations in Debian time-limited, to end in October this year unless she renewed them, and she said that was fine. But when the change was announced, it was more controversial than he expected.

Some of the delegates, "stood up and said, 'You should have asked us'", even though Tille had publicly announced the idea. They were offended by the change in delegation procedure because "they felt some kind of distrust". Tille said that the process would have gone better if there was more communication with the delegates. "This is a problem in Debian in general, that we don't find so much time to talk to each other [...] I learned that governance is hard, but we have to do it somehow, and silence is hard to parse". Tille said that there was some clean-up to do after the announcement, but thought that things were fine in the end. "I made failures in my DPL term, yes", he said, but hoped that he admitted to them all openly.

Collaborative maintenance

When Tille began his term as DPL, there were more than 4,000 packages that were not hosted on Debian's GitLab-based collaborative-development platform, Salsa; one of his goals was to reduce that to number to 2,000 or fewer packages. He said that, at the time of his talk, there were only about 1,700 packages not on Salsa "which means no version-control system, or GitHub, or whatever". (The Debian Trends web site tracks the VCS hosting field for packages in the archive.) Even though Debian is a volunteer organization, he believes that it is good to have a shared collaboration platform. "I think this kind of professionalism is what makes volunteer projects scale".

Debian also has strict maintainer ownership of packages. "So if your name is in the maintainer field of the package, it's your package." Historically that was sensible, he said, "because we had experts for, say, 500 or 1,000 packages, and these were really the experts who know what this package is doing". Now Debian has more than 41,000 packages, "and the maintainer field is not always filled with a person who is really competent". He felt he could say that because he knows that he is maintaining packages where he is not an expert, and needs help from other colleagues to ensure he's on the right track. He works on Debian Med packages related to medicine and bioinformatics, while he is a physicist by profession.

But, Tille said, "my name is not on any maintainer field of any Debian packages". Instead, the packages he works on are always maintained by a team of packagers rather than a single packager. He is an uploader for packages, which means that he can make and push changes to the archive, but others can as well. He believes that is the best way to go for the future of packages in Debian.

"This historical strict maintainership is an increasing source of friction in Debian, because its hard to know whether a package is orphaned or just needs no work". Some packages may not be touched for years, but there is no indication why that may be. Silence, he noted again, is hard to interpret, "and also hard to accept for me, because there are maintainers who simply don't answer". The maintainer may be uploading from time to time, but "if you send them an email, they are not answering". He stressed that silence was not the rule, but an exception. "But it's a consequence of the fact that we have this strict maintainership that we can't touch these packages."

Tille had a goal of loosening the strict ownership of packages during his terms as DPL, but he failed to do so. "Debian is a great community, but we are a community of individuals. We have a lot of good teams, but we also have individuals who do not interact." That is fine, he said, but he thought that the project would benefit from stronger collaboration.

He mentioned some of the attempts to improve collaboration on packages and loosen ownership over the years, such as the introduction of non-maintainer uploads (NMUs), the Missing In Action team that checks to ensure maintainers are still active, and the package-salvaging process (more frequently referred to as "intent to salvage" or ITS) for packages that have not been officially orphaned but may be poorly maintained or completely unmaintained.

In late 2024, Tille suggested flipping the default assumption of package ownership to an open maintainership model by introducing a Debian control file file for packages, perhaps called "debian/dont_touch_my_package". A maintainer could indicate that they wanted to discourage others from making changes to a package by documenting their reasons. "This file could include a timestamp, and we could establish an agreed-upon timeframe for refreshing the statement to ensure its continued validity." If the file is not present, then it would be assumed that the package was open for maintenance by other Debian contributors.

That idea has not caught on, at least not yet, but Tille said that he would try to pick it up later. "You don't need to be the DPL to change anything in Debian. It's absolutely not necessary."

Responsible use of LLMs

LLMs and other generative-AI tools were just starting to make their presence felt in open-source communities when Tille began his first term as DPL in 2024. By the time he finished his second term, they had become an important and divisive topic within Debian. Not surprisingly, Tille had some thoughts about Debian's LLM usage GR, its vote to allow "responsible use of generative AI", and his own relationship with LLM tools.

Tille is German, and English is not his first language; thus, he is forced to communicate in a foreign language as part of participating in Debian. "And it's not only the language; you have also a foreign culture because Germans are quite straight. You usually tell what you think, and it's not very well perceived in other cultures." That led him to explore the use of LLMs to try to communicate more effectively as DPL.

He said, in what may have been the least-surprising disclosure in his talk, "you don't always get friendly emails as a response" when serving as DPL. That could lead to an angry response in return, but Tille opted to use LLMs as a buffer to prevent him from "responding quite emotionally", and instead try to discover the underlying problem and if the person had a point. He added that, separate from LLM usage, his advice was to avoid answering on the same day. "Draft your answer, sleep on it, send it the next day, or even better: delete it the next day." LLMs, Tille said, can help to focus on a topic, find new interpretations of an ambiguous response, and so forth.

So for me, LLMs are a legitimate tool; a tool for just clarity, not a ghostwriter. I never say to an LLM, "Please draft an email for me". No. It's kind of a depersonalization, but if you are in a responsibility situation like the DPL is, it makes sense to think wider than, or think beyond your own personality.

I own the intent of what I'm writing, and the LLM helps me with the right expression. So what I always can recommend: LLMs can be kind of an editor. Use this [as an] editor, but not as the author of your words.

He stressed that he drafted his own responses, reviewed all changes, and thought that he owned the final results. "There are people who might disagree, but this is my view on how to use [LLMs] responsibly."

Tille said that his view on the GR was that he perfectly understood the people who wanted to restrict LLM usage. "I know all of the drawbacks of LLMs. I think I'm aware of them". He thought it would have been better for those who wanted to restrict LLM usage to discuss possible restrictions, for those who wanted to enable LLM usage to propose their ideas and to find common sense ways to propose restrictions properly. Instead, there was a "heap" of proposals that "nearly made our software for voting [explode] because we have so many, admittedly interesting, proposals".

In the end, the "Responsible Use of Generative AI" option won, which he interpreted as Debian's voters saying "'we want to stand [by] the existing standards for quality, correctness, and maintainability', which is the core of Debian, in my opinion". He believed that it is not well-perceived within Debian if "someone is telling you, 'you are not permitted to do that'". That is why the non-permissive suggestions failed to even meet the majority requirements to pass, as well as failing to beat the permissive options. "I understand the reasons why the people wanted to have some restrictions, but this is not the way how you can push this on the Debian maintainers".

Lessons learned

Tille said he would cover some of the lessons he learned as DPL, starting with focusing on specific and reachable goals. This meant listening carefully to the community, and trying to find the input that indicates a support for change. He thought he could reach more of his goals, but learned that he had to concentrate on what was really important and leave other things to future DPLs.

"You also need the courage to make hard decisions." He said that he had to make the hardest decision of his life during the DPL term, though he did not specify what that decision was. "My specific goal required decisions which I'm absolutely not happy about, but they were necessary anyway". He added that a DPL should not fear pushback, but it will come.

Tille said that he had also learned that it was important to ensure cooperation from volunteers who will back up a decision. He again stressed the importance of talking to people in the community to find out their opinions and whether the "silent majority" agrees. A lot of people, he said, may be "on your side, but they are too busy to pronounce it on the mailing list".

It is not normal to acknowledge mistakes openly in "normal politics", Tille said, but that is wrong. "I think it was a good idea that I acknowledged my mistakes openly."

His favorite lesson, he said, was that the Debian Med team was able to function without him. In his 2024 DPL platform, Tille had talked about starting and leading the team, which had been "a significant part of half of my life". Being DPL was not as time-consuming as he was afraid it would be, but he had stepped back from his work with the Debian Med team while serving as DPL. "The good news is, the team kept on working." It made him happy to learn that the team could survive "at least for a couple of years" without his involvement. That was not, he noted, always the case for Debian teams when a main contributor steps back for some reason. It is harder, he had learned, for a contributor to step back gracefully than it is to find contributors to step up in the first place.

He had three "final" lessons. The first was that the opinions of Debian contributors are more diverse and divergent than he expected. The second was that—no matter what he said—the interpretation was "it's the DPL speaking". He wanted to "keep on being Andreas Tille talking to his friends", but he had to deal with treating him as the DPL anyway.

The third final lesson was that he couldn't do what he wanted to do in one term. It took him a year to understand the job before he could make the changes he wanted to make. He thought that it was a good thing that the DPL term was only for one year, because if he had known in advance that it would take two "maybe I would not have stepped up for the position. So do it one year and see what happens".

He finished his talk with his favorite quotation, which he credited to Giuseppe Tomasi di Lampedusa: "Everything must change so that everything can stay the same". Tille said that he liked that a lot, and it was fitting for Debian.

Questions

Marc Haber asked the first two questions. He wanted to know Tille's opinion about redefining "or putting some more definition" on the duties of package maintainers. The second question was what could a DPL do to bring more technical leadership into Debian.

Tille responded that the first question related to his own opinion that the historical model of package ownership is "not really meeting the current standards we need". He said that Debian needed to talk about it and that there was a lot of agreement that it needed to change, but "if you propose something, people stand up and say, 'No, I think it's good and we should keep on doing this'". The problem is that they may not represent the "about 1,000 Debian developers, who are all very busy doing their own stuff and don't have time to read long threads and mailing lists". He felt that the LLM GR illustrated this; the people who take part in discussions may not represent the majority view.

As to Haber's second question, Tille said that Debian did have technical leadership in some fields, but not all. The way to attract more was by "doing a good job, being open, being friendly, and inviting for them. But I also have no short and clear path to do this".

Another audience member said that Tille had talked about his Bug of the Day initiative, but he had not talked about whether it had succeeded. Did it bring in more people? Was it successful? Tille said that there were three people who are now Debian maintainers who were not before the program started, but overall "I was not able to break this barrier" of getting people who are "too shy" to participate and ask questions in order to become contributors. He admitted he also had no idea how to solve that problem.

Comments (none posted)

Emacs arbitrary code execution flaw

Sean Whitton has announced that the original fix for an arbitrary code execution flaw in Emacs (CVE-2024-53920) was incomplete. Bas Alberts discovered that viewing or editing untrusted files in modes other than Emacs's Lisp mode can also result in arbitrary code execution.

This problem affects all Emacs versions affected by CVE-2024-53920. This means Emacs 24 and newer, and possibly also older versions.

A minimal fix, attached, is queued up for release with Emacs 31.2. We (the Emacs upstream maintainers) don't expect to backport the fix to older Emacs releases ourselves.

LWN covered the original vulnerability in December 2024.

Comments (1 posted)

Forgejo 16.0.4 and 15.0.8 address critical security vulnerability

The Forgejo software-forge project has announced the release of versions 16.0.4 and 15.0.8, which fixes two security vulnerabilities. One is a critical flaw that would allow remote-code execution (RCE):

When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.

The project recommends upgrading to the latest version as soon as possible.

Comments (1 posted)

Kernel release status

The current development kernel is 7.3-rc3, released on September 13. Linus said: "Another fairly large rc release, and again one with a bigger filesystem footprint that we usually see."

This release has seen 16,533 non-merge changesets from 2,638 developers, 599 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.3-rc1	2026-08-30	16267	16267
v7.3-rc2	2026-09-06	681	681
v7.3-rc3	2026-09-13	733	733

See the LWN KSDB v7.3 page for a lot more details.

Stable updates: the large 7.2.5 and 6.18.51 updates were released on September 11, followed by the massive 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221, 5.10.270 updates on September 14.

Comments (none posted)

Quote of the week

The day has finally come. We are dropping the legacy C implementation of the Binder IPC driver in favor of its Rust version.

For 15+ years, the C driver has grown increasingly complex, making it incredibly painful to maintain and land new features without tripping over vulnerabilities. The Rust implementation alleviates most of these issues, so it's time for a change.

Alice Ryhl has worked hard on the Rust binder for the past couple of years, not only achieving full feature parity but also proving that it can match and often beat the performance of the C counterpart. Having run successfully on Android devices for some time now, we can no longer call this an "experiment".

It's time to move on, yank the C code, and focus all new features and optimizations on the Rust driver.

— Carlos Llamas

Comments (none posted)

Fedora 45 beta drags the Linux console into the 21st century (Register)

The Register looks forward to the upcoming Fedora 45 release.

The biggest surprise is that Linux's legacy in-kernel console – the text-mode interface normally hidden beneath the GUI – has been replaced with a software-controlled alternative. The replacement is kmscon, a userspace terminal emulator that has been in development for more than a decade.

Comments (33 posted)

GNU Core Utilities 9.12 released

Pádraig Brady has announced GNU Core Utilities (coreutils) version 9.12. "There have been 288 commits by 16 people in the 21 weeks since 9.11". New features include an -A option for uname which labels all output, as well as adding awareness of the failfs and nullfs filesystem types to stat and tail.

There are many bug fixes in this release as well, including one for a bug "present in 'the beginning'" that caused some utilities to fail when traversing hierarchies if files are being removed in parallel.

Comments (95 posted)

Julia 1.13 released

Version 1.13 of the Julia programming language has been released. Highlights include faster precompilation of packages, improvements to Julia's REPL, and Juliaup, a graphical interface for the Julia version manager. A full list of changes can be found in the release notes. LWN covered Julia 1.12 in November 2025.

Comments (none posted)

Vondra: PostgreSQL development activity

PostgreSQL contributor Tomas Vondra has published a blog post looking at development activity in the project, with data from the late 1990s to today.

We're doing ~50 commits per week, give or take. In ~2010 we were doing maybe 25/week, and the trend seems to be a slow and consistent growth. The monthly average makes the trend a bit easier to spot. Which is good, although there's a lot of other important details (size of commits, are they new features or fixes, ...).

It however nicely aligns with the number of active committers, which also grew ~2x between 2010 and today. So maybe that's working as expected.

Comments (none posted)

Development quotes of the week

The moral of this story is that, if positive engagement with your community is perceived as valuable, you have an enormous amount of leverage over big companies. At the time, Microsoft was (by market cap) the largest company in the world. The legal text, in contrast, isn't worth the paper it's written on when your adversary can afford to outspend you in court by six orders of magnitude. When they happen to be aligned, the legal text may look as if it's working, but that's a coincidence.

— David Chisnall

I often joke that the job [of open-source developer] is 50% diplomat, 50% politician, 50% therapist, 50% publicist, 50% engineer, and 100% volunteer.

— Barry Warsaw

AI agents are getting lots of people excited about coding again which is great. But eventually it comes back to boring and well maintained platforms.

Anybody can throw some code on the internet. That doesn't mean anybody will maintain the code – ensuring that things are rebuilt after Log4Shell happens again, two years from now. AI is great at writing code but you still better pay attention to what human is at the steering wheel and whether they seem like they are paying attention, or seem like they have any level of commitment to stick around. Or alternatively you need to be willing to take full ownership/responsibility yourself.

— Jeremy Schneider

Your next step could be creating a pull request and feel like you've made a valuable contribution to not just NLnet Labs, but the entire DNS operator community. This kind of contribution to your favorite open-source project may feel to you like "free as in beer" and "free as in speech" but to us it is like being handed a "free puppy": well intended, but accepting it has big consequences for years to come.

Most importantly though, we still think the same core principles for review apply. We need to be able to reason with the contributor about their design choices. In the end, they are handing responsibility for maintaining the code to us. We need to know what we're getting into before making a long-term commitment. Sadly, in almost all cases the response to any question about the code has been along the lines of "I dunno, it's what Claude came up with 🤷". That just doesn't work for us.

— Alex Band for Team NLnet Labs

Comments (none posted)

EuroPython 2026 videos published

All of the videos from the EuroPython 2026 conference, held in Kraków, Poland from July 13 through July 19, are now online along with a recap of the event from conference organizers.

Comments (1 posted)

CFP Deadlines: September 17, 2026 to November 16, 2026

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

Deadline	Event Dates	Event	Location
September 18	September 19	Software Freedom Day NJ	Montclair, NJ, US
September 21	October 10 October 11	GStreamer Conference 2026	Prague, Czech Republic
September 28	November 3 November 4	Open vSwitch and OVN 2026 Fall Conference	Heilbronn, Germany
October 1	November 7 November 8	OpenFest 2026	Sofia, Bulgaria
October 1	November 12 November 13	Ubuntu Summit 26.10	Online
October 4	November 7 November 8	OpenALT	Brno, Czechia
October 9	November 20 November 21	OLF Conference	Columbus, Ohio, US
November 1	April 1 April 4	Southern California Linux Expo	Pasadena, CA, US

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

Events: September 17, 2026 to November 16, 2026

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

Date(s)	Event	Location
September 17 September 18	Git Merge	Lisbon, Portugal
September 19 September 24	Akademy 2026	Graz, Austria
September 19	Software Freedom Day NJ	Montclair, NJ, US
September 19 September 20	Nextcloud Community Conference 2026	Berlin, Germany
September 21 September 23	Kernel Recipes	Paris, France
September 22 September 24	Reproducible Builds Summit	Gothenburg, Sweden
September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
September 28 September 30	X.Org Developers Conference	Toronto, Canada
September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
September 30 October 1	All Systems Go! 2026	Berlin, Germany
October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
October 2 October 4	GNU Tools Cauldron	Prague, Czechia
October 3 October 4	openSUSE.Asia Summit 2026	Yogyakarta, Indonesia
October 3 October 4	Linux Days 2026	Prague, Czechia
October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
October 6	Real-time Linux User Forum	Prague, Czechia
October 6	Yocto Project Developer Day 2026	Prague, Czechia
October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
October 8	Linux Security Summit Europe	Prague, Czechia
October 10 October 11	GStreamer Conference 2026	Prague, Czech Republic
October 13 October 15	OpenSSL Conference	Prague, Czech Republic
October 14 October 17	PyCon South Africa	Cape Town, South Africa
October 16 October 18	VideoLAN Developers' Days	Rome, Italy
October 18 October 20	All Things Open	Raleigh, NC, US
October 20 October 23	The Matrix Conference	Malmö, Sweden
October 20 October 23	PostgreSQL Conference Europe	Valencia, Spain
October 30 November 1	Qubes OS Summit	Berlin, Germany
November 3 November 4	Open vSwitch and OVN 2026 Fall Conference	Heilbronn, Germany
November 6 November 7	Texas Linux Festival	Austin, TX, US
November 7 November 8	OpenFest 2026	Sofia, Bulgaria
November 7 November 8	OpenALT	Brno, Czechia
November 12 November 13	Ubuntu Summit 26.10	Online
November 14 November 15	Capitole du Libre 2026	Toulouse, France

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

Alert summary September 10, 2026 to September 16, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:64785	10	389-ds-base	2026-09-14
AlmaLinux	ALSA-2026:64784	9	389-ds-base	2026-09-10
AlmaLinux	ALSA-2026:66248	8	ansible-core	2026-09-10
AlmaLinux	ALSA-2026:66392	10	apr-util	2026-09-11
AlmaLinux	ALSA-2026:66341	9	apr-util	2026-09-10
AlmaLinux	ALSA-2026:64777	10	buildah	2026-09-09
AlmaLinux	ALSA-2026:66403	9	coreutils	2026-09-11
AlmaLinux	ALSA-2026:64810	10	expat	2026-09-09
AlmaLinux	ALSA-2026:66349	10	freerdp	2026-09-14
AlmaLinux	ALSA-2026:66347	9	freerdp	2026-09-11
AlmaLinux	ALSA-2026:67161	8	git-lfs	2026-09-14
AlmaLinux	ALSA-2026:66364	9	git-lfs	2026-09-11
AlmaLinux	ALSA-2026:64799	10	glib2	2026-09-09
AlmaLinux	ALSA-2026:66451	8	glib2	2026-09-14
AlmaLinux	ALSA-2026:65162	10	gpsd	2026-09-09
AlmaLinux	ALSA-2026:65606	9	gpsd-minimal	2026-09-10
AlmaLinux	ALSA-2026:66460	10	gstreamer1-plugins-base	2026-09-11
AlmaLinux	ALSA-2026:67145	8	gstreamer1-plugins-base	2026-09-14
AlmaLinux	ALSA-2026:65998	8	gzip	2026-09-10
AlmaLinux	ALSA-2026:63128	10	kernel	2026-09-09
AlmaLinux	ALSA-2026:65334	10	kernel	2026-09-11
AlmaLinux	ALSA-2026:66325	8	kernel	2026-09-10
AlmaLinux	ALSA-2026:66000	8	kernel	2026-09-10
AlmaLinux	ALSA-2026:67468	8	kernel	2026-09-15
AlmaLinux	ALSA-2026:63129	9	kernel	2026-09-10
AlmaLinux	ALSA-2026:64808	9	kernel	2026-09-11
AlmaLinux	ALSA-2026:66180	9	kernel	2026-09-11
AlmaLinux	ALSA-2026:66324	8	kernel-rt	2026-09-10
AlmaLinux	ALSA-2026:67469	8	kernel-rt	2026-09-15
AlmaLinux	ALSA-2026:67267	10	libkcapi	2026-09-14
AlmaLinux	ALSA-2026:67266	8	libkcapi	2026-09-14
AlmaLinux	ALSA-2026:67265	9	libkcapi	2026-09-15
AlmaLinux	ALSA-2026:67314	10	nginx	2026-09-15
AlmaLinux	ALSA-2026:66542	9	nginx	2026-09-11
AlmaLinux	ALSA-2026:67315	8	nginx:1.24	2026-09-15
AlmaLinux	ALSA-2026:67308	9	nginx:1.24	2026-09-15
AlmaLinux	ALSA-2026:54530	8	nodejs:22	2026-09-14
AlmaLinux	ALSA-2026:55601	9	nodejs:22	2026-09-14
AlmaLinux	ALSA-2026:54371	8	nodejs:24	2026-09-14
AlmaLinux	ALSA-2026:67154	10	openssl	2026-09-15
AlmaLinux	ALSA-2026:67165	9	openssl	2026-09-15
AlmaLinux	ALSA-2026:65116	10	opentelemetry-collector	2026-09-10
AlmaLinux	ALSA-2026:65117	9	opentelemetry-collector	2026-09-10
AlmaLinux	ALSA-2026:66016	8	osbuild-composer	2026-09-10
AlmaLinux	ALSA-2026:67148	8	osbuild-composer	2026-09-14
AlmaLinux	ALSA-2026:65153	9	osbuild-composer	2026-09-15
AlmaLinux	ALSA-2026:67156	10	perl	2026-09-15
AlmaLinux	ALSA-2026:67162	8	perl	2026-09-15
AlmaLinux	ALSA-2026:67155	9	perl	2026-09-15
AlmaLinux	ALSA-2026:65887	10	perl-DBI	2026-09-10
AlmaLinux	ALSA-2026:66179	9	perl-DBI	2026-09-10
AlmaLinux	ALSA-2026:67269	8	perl-YAML-Syck	2026-09-14
AlmaLinux	ALSA-2026:67278	8	perl:5.32	2026-09-15
AlmaLinux	ALSA-2026:65899	10	postgresql16-postgis	2026-09-11
AlmaLinux	ALSA-2026:66204	9	python-lxml	2026-09-10
AlmaLinux	ALSA-2026:67147	10	python-tornado	2026-09-15
AlmaLinux	ALSA-2026:67146	9	python-tornado	2026-09-15
AlmaLinux	ALSA-2026:66203	9	python3.12-lxml	2026-09-10
AlmaLinux	ALSA-2026:65897	8	qt5-qtbase	2026-09-10
AlmaLinux	ALSA-2026:65993	9	qt5-qtbase	2026-09-10
AlmaLinux	ALSA-2026:65816	10	qt6-qt5compat	2026-09-10
AlmaLinux	ALSA-2026:67463	10	rsync	2026-09-15
AlmaLinux	ALSA-2026:67462	9	rsync	2026-09-15
AlmaLinux	ALSA-2026:50778	10	ruby	2026-09-14
AlmaLinux	ALSA-2026:50773	10	ruby4.0	2026-09-14
AlmaLinux	ALSA-2026:50728	8	ruby:3.3	2026-09-14
AlmaLinux	ALSA-2026:67286	10	rust	2026-09-15
AlmaLinux	ALSA-2026:67285	9	rust	2026-09-15
AlmaLinux	ALSA-2026:65159	10	thunderbird	2026-09-09
AlmaLinux	ALSA-2026:64796	10	valkey	2026-09-10
AlmaLinux	ALSA-2026:66336	10	vim	2026-09-11
AlmaLinux	ALSA-2026:66348	8	vim	2026-09-10
AlmaLinux	ALSA-2026:66366	9	vim	2026-09-11
AlmaLinux	ALSA-2026:64787	10	xz	2026-09-09
Debian	DSA-6499-1	stable	cjose	2026-09-15
Debian	DLA-4779-1	LTS	jbig2dec	2026-09-14
Debian	DSA-6494-1	stable	kamailio	2026-09-11
Debian	DSA-6493-1	stable	libevent	2026-09-11
Debian	DSA-6498-1	stable	network-manager-l2tp	2026-09-14
Debian	DSA-6496-1	stable	nginx	2026-09-12
Debian	DSA-6496-2	stable	nginx	2026-09-16
Debian	DLA-4778-1	LTS	pyasn1	2026-09-09
Debian	DSA-6492-1	stable	ruby-rack	2026-09-10
Debian	DSA-6495-1	stable	spip	2026-09-11
Debian	DLA-4780-1	LTS	urwid	2026-09-15
Debian	DSA-6497-1	stable	xorg-server	2026-09-12
Fedora	FEDORA-2026-1cb04a54d8	F44	GitPython	2026-09-10
Fedora	FEDORA-2026-63e7132525	F45	GitPython	2026-09-16
Fedora	FEDORA-2026-6cf9691266	F44	PackageKit	2026-09-13
Fedora	FEDORA-2026-95d69295a4	F45	PackageKit	2026-09-13
Fedora	FEDORA-2026-c70f6e6ebc	F45	baresip	2026-09-11
Fedora	FEDORA-2026-0adbf9c133	F45	bind	2026-09-11
Fedora	FEDORA-2026-6ed52ea50e	F43	bluez	2026-09-12
Fedora	FEDORA-2026-d4156b5fc5	F44	bluez	2026-09-11
Fedora	FEDORA-2026-84b4f1c43a	F45	bluez	2026-09-11
Fedora	FEDORA-2026-9e011ac6ed	F45	bluez	2026-09-12
Fedora	FEDORA-2026-de382db258	F45	bubblewrap	2026-09-11
Fedora	FEDORA-2026-6627e39af0	F45	chirp	2026-09-11
Fedora	FEDORA-2026-07ab59f891	F45	chromium	2026-09-11
Fedora	FEDORA-2026-a002299f28	F45	cockpit	2026-09-11
Fedora	FEDORA-2026-249d41312c	F45	composer	2026-09-11
Fedora	FEDORA-2026-c0427570d6	F43	corosync	2026-09-11
Fedora	FEDORA-2026-ef5ca6ecf7	F45	corosync	2026-09-11
Fedora	FEDORA-2026-6841033933	F43	curl	2026-09-11
Fedora	FEDORA-2026-f26b509a1a	F44	curl	2026-09-11
Fedora	FEDORA-2026-2719c6cac1	F44	darktable	2026-09-10
Fedora	FEDORA-2026-8a0b0bba30	F45	darktable	2026-09-11
Fedora	FEDORA-2026-046b69d591	F43	dokuwiki	2026-09-11
Fedora	FEDORA-2026-9bbb604ea2	F44	dokuwiki	2026-09-11
Fedora	FEDORA-2026-2ec7f70c76	F45	dokuwiki	2026-09-11
Fedora	FEDORA-2026-25056dbe2f	F43	elixir	2026-09-14
Fedora	FEDORA-2026-d4ca774d9e	F44	elixir	2026-09-14
Fedora	FEDORA-2026-688dc4a890	F45	elixir	2026-09-14
Fedora	FEDORA-2026-6a8bb95fd4	F43	environment-modules	2026-09-16
Fedora	FEDORA-2026-c419d5048d	F44	environment-modules	2026-09-16
Fedora	FEDORA-2026-972718725c	F45	environment-modules	2026-09-16
Fedora	FEDORA-2026-02481296e8	F43	erlang	2026-09-16
Fedora	FEDORA-2026-64363fe778	F44	erlang	2026-09-16
Fedora	FEDORA-2026-a0cb1e1e61	F45	exiv2	2026-09-11
Fedora	FEDORA-2026-fefd0cbb42	F45	expat	2026-09-11
Fedora	FEDORA-2026-823e097aaa	F45	firefox	2026-09-11
Fedora	FEDORA-2026-bf202f7b3b	F43	freeipa	2026-09-10
Fedora	FEDORA-2026-d2a288c8eb	F45	freerdp	2026-09-11
Fedora	FEDORA-2026-3fe3e3ae10	F43	freerdp2	2026-09-10
Fedora	FEDORA-2026-d91338eea8	F44	freerdp2	2026-09-10
Fedora	FEDORA-2026-20b7d49f70	F45	freerdp2	2026-09-11
Fedora	FEDORA-2026-cf5d926f46	F43	gdk-pixbuf2	2026-09-10
Fedora	FEDORA-2026-f55d6fc9f8	F45	gdk-pixbuf2	2026-09-11
Fedora	FEDORA-2026-03ea7c5707	F45	gegl04	2026-09-11
Fedora	FEDORA-2026-2f89cc806e	F43	golang-x-perf	2026-09-13
Fedora	FEDORA-2026-cdaa0a840e	F44	golang-x-perf	2026-09-13
Fedora	FEDORA-2026-09a9388be9	F45	golang-x-perf	2026-09-13
Fedora	FEDORA-2026-275646ea83	F43	grpcurl	2026-09-11
Fedora	FEDORA-2026-fc26634b91	F44	grpcurl	2026-09-11
Fedora	FEDORA-2026-ce70c33170	F45	grpcurl	2026-09-11
Fedora	FEDORA-2026-0a8e95dad5	F43	kernel	2026-09-13
Fedora	FEDORA-2026-9ce2715225	F44	kernel	2026-09-13
Fedora	FEDORA-2026-a0019f8ab9	F45	kernel	2026-09-11
Fedora	FEDORA-2026-bfc7ad7bad	F45	kernel	2026-09-13
Fedora	FEDORA-2026-a0019f8ab9	F45	kernel-headers	2026-09-11
Fedora	FEDORA-2026-4782ac1f8b	F44	knot	2026-09-16
Fedora	FEDORA-2026-e7ca68120c	F45	knot	2026-09-16
Fedora	FEDORA-2026-728dd9f704	F43	libevent	2026-09-11
Fedora	FEDORA-2026-0a83f1b852	F45	libevent	2026-09-12
Fedora	FEDORA-2026-0664f1b41b	F45	libmongocrypt	2026-09-13
Fedora	FEDORA-2026-c3fb234b87	F45	libpcap	2026-09-13
Fedora	FEDORA-2026-c70f6e6ebc	F45	libre	2026-09-11
Fedora	FEDORA-2026-fce2f41203	F43	libsoup3	2026-09-10
Fedora	FEDORA-2026-ce24b84bb1	F45	libsoup3	2026-09-12
Fedora	FEDORA-2026-fb82981047	F45	memcached	2026-09-11
Fedora	FEDORA-2026-4a2ee61320	F43	mingw-expat	2026-09-12
Fedora	FEDORA-2026-5660612c34	F44	mingw-expat	2026-09-12
Fedora	FEDORA-2026-9e9244744d	F45	mingw-expat	2026-09-11
Fedora	FEDORA-2026-94344a87fb	F45	mingw-openexr	2026-09-11
Fedora	FEDORA-2026-f74926c622	F43	mongo-c-driver	2026-09-13
Fedora	FEDORA-2026-8ed63cce6b	F44	mongo-c-driver	2026-09-13
Fedora	FEDORA-2026-83792d666c	F45	mongo-c-driver	2026-09-13
Fedora	FEDORA-2026-c2dba9f29d	F45	mrtg	2026-09-11
Fedora	FEDORA-2026-7ac5fb031f	F43	nagios-plugins	2026-09-12
Fedora	FEDORA-2026-c2fbd942bc	F44	nagios-plugins	2026-09-12
Fedora	FEDORA-2026-c56ac69334	F45	nsd	2026-09-11
Fedora	FEDORA-2026-823e097aaa	F45	nss	2026-09-11
Fedora	FEDORA-2026-00b3d3d018	F43	openssl	2026-09-10
Fedora	FEDORA-2026-3d5ab046c4	F45	openssl	2026-09-11
Fedora	FEDORA-2026-17203fb331	F45	openvpn	2026-09-12
Fedora	FEDORA-2026-ae048e451f	F44	pdns-recursor	2026-09-13
Fedora	FEDORA-2026-6c1e0af917	F45	pdns-recursor	2026-09-13
Fedora	FEDORA-2026-53e2875c88	F44	perl-Authen-SASL	2026-09-16
Fedora	FEDORA-2026-81cd7d0f41	F45	perl-Authen-SASL	2026-09-16
Fedora	FEDORA-2026-a4674c5df6	F43	perl-DBI	2026-09-15
Fedora	FEDORA-2026-195d764078	F44	perl-DBI	2026-09-15
Fedora	FEDORA-2026-2bf3261da2	F45	perl-DBI	2026-09-15
Fedora	FEDORA-2026-d0bededb87	F43	perl-Dancer2	2026-09-15
Fedora	FEDORA-2026-d13a2593b1	F44	perl-Dancer2	2026-09-15
Fedora	FEDORA-2026-28c5da9193	F45	perl-Dancer2	2026-09-15
Fedora	FEDORA-2026-8924ee53fe	F43	perl-Data-Entropy	2026-09-15
Fedora	FEDORA-2026-2c6e5be623	F44	perl-Data-Entropy	2026-09-15
Fedora	FEDORA-2026-f234be41fe	F45	perl-Data-Entropy	2026-09-15
Fedora	FEDORA-2026-1237afef8a	F43	perl-Net-DNS	2026-09-10
Fedora	FEDORA-2026-a0607111e6	F44	perl-Net-DNS	2026-09-10
Fedora	FEDORA-2026-27bab0e213	F45	perl-Net-OAuth	2026-09-11
Fedora	FEDORA-2026-06b545f607	F43	perl-Protocol-HTTP2	2026-09-15
Fedora	FEDORA-2026-e06691a7c4	F44	perl-Protocol-HTTP2	2026-09-15
Fedora	FEDORA-2026-038229756e	F45	perl-Protocol-HTTP2	2026-09-15
Fedora	FEDORA-2026-3a2db4368a	F45	perl-XML-Bare	2026-09-11
Fedora	FEDORA-2026-1576c48cce	F45	php-pecl-mongodb2	2026-09-13
Fedora	FEDORA-2026-14e836e595	F45	podman-tui	2026-09-15
Fedora	FEDORA-2026-79e569db98	F45	python-asteval	2026-09-11
Fedora	FEDORA-2026-2e605e01a6	F43	python-configargparse	2026-09-16
Fedora	FEDORA-2026-e3b2220f12	F44	python-configargparse	2026-09-16
Fedora	FEDORA-2026-d40fc39b57	F45	python-configargparse	2026-09-16
Fedora	FEDORA-2026-d083cbcc1a	F45	python-pip	2026-09-11
Fedora	FEDORA-2026-612edb2029	F45	rclone	2026-09-11
Fedora	FEDORA-2026-c2116e108f	F43	rest	2026-09-11
Fedora	FEDORA-2026-df38653cf2	F44	rest	2026-09-11
Fedora	FEDORA-2026-4baee57e28	F45	rest	2026-09-11
Fedora	FEDORA-2026-da06bdeb38	F44	ruby	2026-09-16
Fedora	FEDORA-2026-ab0c751524	F45	ruby	2026-09-16
Fedora	FEDORA-2026-2857104379	F44	rubygems	2026-09-16
Fedora	FEDORA-2026-9831a751e2	F45	rubygems	2026-09-16
Fedora	FEDORA-2026-e82315c1dc	F43	rust-hickory-net	2026-09-14
Fedora	FEDORA-2026-3c1acd5a65	F44	rust-hickory-net	2026-09-14
Fedora	FEDORA-2026-37e598af67	F45	rust-hickory-net	2026-09-14
Fedora	FEDORA-2026-e82315c1dc	F43	rust-hickory-proto	2026-09-14
Fedora	FEDORA-2026-3c1acd5a65	F44	rust-hickory-proto	2026-09-14
Fedora	FEDORA-2026-37e598af67	F45	rust-hickory-proto	2026-09-14
Fedora	FEDORA-2026-e82315c1dc	F43	rust-hickory-resolver	2026-09-14
Fedora	FEDORA-2026-3c1acd5a65	F44	rust-hickory-resolver	2026-09-14
Fedora	FEDORA-2026-37e598af67	F45	rust-hickory-resolver	2026-09-14
Fedora	FEDORA-2026-332a62112c	F43	rust-lru	2026-09-15
Fedora	FEDORA-2026-33c180c1b0	F44	rust-lru	2026-09-15
Fedora	FEDORA-2026-cf36f81efc	F45	rust-lru	2026-09-15
Fedora	FEDORA-2026-332a62112c	F43	rust-lru0.16	2026-09-15
Fedora	FEDORA-2026-33c180c1b0	F44	rust-lru0.16	2026-09-15
Fedora	FEDORA-2026-cf36f81efc	F45	rust-lru0.16	2026-09-15
Fedora	FEDORA-2026-a9bf99671c	F43	rust-ppmd-rust	2026-09-10
Fedora	FEDORA-2026-59fc59239b	F44	rust-ppmd-rust	2026-09-10
Fedora	FEDORA-2026-78406777e8	F45	rust-ppmd-rust	2026-09-11
Fedora	FEDORA-2026-64307ca6fb	F45	rust-webbrowser	2026-09-11
Fedora	FEDORA-2026-bf202f7b3b	F43	samba	2026-09-10
Fedora	FEDORA-2026-dff163317a	F43	sblim-sfcb	2026-09-16
Fedora	FEDORA-2026-c73fe793ea	F44	sblim-sfcb	2026-09-16
Fedora	FEDORA-2026-d613369130	F45	sblim-sfcb	2026-09-16
Fedora	FEDORA-2026-dfc8680f21	F43	srt	2026-09-12
Fedora	FEDORA-2026-57a6b069d5	F45	srt	2026-09-11
Fedora	FEDORA-2026-bd6debcfb6	F45	syncthing	2026-09-11
Fedora	FEDORA-2026-ee1eb89e7b	F45	tar	2026-09-12
Fedora	FEDORA-2026-a23a377e11	F45	tkimg	2026-09-11
Fedora	FEDORA-2026-cda5ad190f	F43	valkey	2026-09-10
Fedora	FEDORA-2026-3e6f9d599a	F45	valkey	2026-09-11
Gentoo	202609-02		Chromium, Google Chrome, Microsoft Edge, Opera, Vivaldi	2026-09-12
Gentoo	202609-03		Ruby	2026-09-12
Mageia	MGASA-2026-0399	9	bind	2026-09-13
Mageia	MGASA-2026-0403	10, 9	bzip2	2026-09-14
Mageia	MGASA-2026-0389	10	ceph	2026-09-10
Mageia	MGASA-2026-0407	10, 9	cups-filters, libcupsfilters	2026-09-14
Mageia	MGASA-2026-0398	10	ffmpeg	2026-09-13
Mageia	MGASA-2026-0387	10, 9	firefox, nss	2026-09-09
Mageia	MGASA-2026-0391	10	glibc	2026-09-11
Mageia	MGASA-2026-0395	10, 9	java-17-openjdk, java-21-openjdk	2026-09-12
Mageia	MGASA-2026-0397	10, 9	librabbitmq	2026-09-12
Mageia	MGASA-2026-0402	10, 9	libssh2	2026-09-14
Mageia	MGASA-2026-0400	10, 9	perl-Authen-SASL	2026-09-14
Mageia	MGASA-2026-0393	10, 9	perl-Catalyst-Plugin-Static-Simple	2026-09-12
Mageia	MGASA-2026-0390	10, 9	perl-DBI	2026-09-10
Mageia	MGASA-2026-0404	10, 9	perl-HTML-FormFu	2026-09-14
Mageia	MGASA-2026-0394	10, 9	perl-Imager	2026-09-12
Mageia	MGASA-2026-0401	10, 9	tar	2026-09-14
Mageia	MGASA-2026-0388	10, 9	thunderbird	2026-09-09
Mageia	MGASA-2026-0392	10, 9	tor	2026-09-12
Mageia	MGASA-2026-0405	10, 9	unzip	2026-09-14
Mageia	MGASA-2026-0386	10, 9	wget	2026-09-09
Mageia	MGASA-2026-0396	10, 9	xz	2026-09-12
Mageia	MGASA-2026-0406	10, 9	zip	2026-09-14
Oracle	ELSA-2026-64785-0	OL10	389-ds-base	2026-09-09
Oracle	ELSA-2026-64784-0	OL9	389-ds-base	2026-09-09
Oracle	ELSA-2026-64791-0	OL8	389-ds:1.4	2026-09-14
Oracle	ELSA-2026-66248-0	OL8	ansible-core	2026-09-14
Oracle	ELSA-2026-66392-0	OL10	apr-util	2026-09-14
Oracle	ELSA-2026-66341-0	OL9	apr-util	2026-09-14
Oracle	ELSA-2026-64777-0	OL10	buildah	2026-09-09
Oracle	ELSA-2026-66403-0	OL9	coreutils	2026-09-14
Oracle	ELSA-2026-64810-0	OL10	expat	2026-09-09
Oracle	ELSA-2026-64809-0	OL8	expat	2026-09-09
Oracle	ELSA-2026-64812-0	OL9	expat	2026-09-09
Oracle	ELSA-2026-67129-0	OL10	firefox	2026-09-15
Oracle	ELSA-2026-67133-0	OL9	firefox	2026-09-15
Oracle	ELSA-2026-66349-0	OL10	freerdp	2026-09-14
Oracle	ELSA-2026-66347-0	OL9	freerdp	2026-09-14
Oracle	ELSA-2026-64788-0	OL10	git-lfs	2026-09-09
Oracle	ELSA-2026-67161-0	OL8	git-lfs	2026-09-15
Oracle	ELSA-2026-66364-0	OL9	git-lfs	2026-09-14
Oracle	ELSA-2026-64799-0	OL10	glib2	2026-09-09
Oracle	ELSA-2026-66451-0	OL8	glib2	2026-09-14
Oracle	ELSA-2026-64800-0	OL9	glib2	2026-09-09
Oracle	ELSA-2026-42694	OL10	glibc	2026-09-09
Oracle	ELSA-2026-65162-0	OL10	gpsd	2026-09-09
Oracle	ELSA-2026-65606-0	OL9	gpsd-minimal	2026-09-09
Oracle	ELSA-2026-63136-0	OL9	grafana-pcp	2026-09-09
Oracle	ELSA-2026-54752	OL7	gstreamer1-plugins-bad-free	2026-09-10
Oracle	ELSA-2026-66460-0	OL10	gstreamer1-plugins-base	2026-09-14
Oracle	ELSA-2026-67145-0	OL8	gstreamer1-plugins-base	2026-09-15
Oracle	ELSA-2026-65998-0	OL8	gzip	2026-09-14
Oracle	ELSA-2026-64794-0	OL8	httpd:2.4	2026-09-14
Oracle	ELSA-2026-65534-0	OL10	image-builder	2026-09-14
Oracle	ELSA-2026-65886-0	OL9	image-builder	2026-09-14
Oracle	ELSA-2026-42895	OL10	java-21-openjdk	2026-09-14
Oracle	ELSA-2026-42895	OL8	java-21-openjdk	2026-09-14
Oracle	ELSA-2026-42895	OL9	java-21-openjdk	2026-09-14
Oracle	ELSA-2026-63128-0	OL10	kernel	2026-09-09
Oracle	ELSA-2026-64775-0	OL10	kernel	2026-09-14
Oracle	ELSA-2026-66355-0	OL10	kernel	2026-09-15
Oracle	ELSA-2026-63014-0	OL8	kernel	2026-09-09
Oracle	ELSA-2026-66325-0	OL8	kernel	2026-09-14
Oracle	ELSA-2026-66000-0	OL8	kernel	2026-09-15
Oracle	ELSA-2026-63129-0	OL9	kernel	2026-09-09
Oracle	ELSA-2026-64808-0	OL9	kernel	2026-09-14
Oracle	ELSA-2026-66180-0	OL9	kernel	2026-09-14
Oracle	ELSA-2026-67150-0	OL9	kernel	2026-09-15
Oracle	ELSA-2026-67267-0	OL10	libkcapi	2026-09-15
Oracle	ELSA-2026-67266-0	OL8	libkcapi	2026-09-15
Oracle	ELSA-2026-67265-0	OL9	libkcapi	2026-09-15
Oracle	ELSA-2026-62217-0	OL9	libssh	2026-09-09
Oracle	ELSA-2026-65832-0	OL8	mrtg	2026-09-14
Oracle	ELSA-2026-67314-0	OL10	nginx	2026-09-15
Oracle	ELSA-2026-59362	OL9	nginx	2026-09-09
Oracle	ELSA-2026-66542-0	OL9	nginx	2026-09-14
Oracle	ELSA-2026-67283-0	OL9	nginx:1.26	2026-09-15
Oracle	ELSA-2026-67154-0	OL10	openssl	2026-09-15
Oracle	ELSA-2026-67165-0	OL9	openssl	2026-09-15
Oracle	ELSA-2026-65895-0	OL10	osbuild-composer	2026-09-14
Oracle	ELSA-2026-66432-0	OL10	osbuild-composer	2026-09-15
Oracle	ELSA-2026-48790	OL8	osbuild-composer	2026-09-14
Oracle	ELSA-2026-65153-0	OL9	osbuild-composer	2026-09-14
Oracle	ELSA-2026-65887-0	OL10	perl-DBI	2026-09-14
Oracle	ELSA-2026-62667-0	OL8	perl-DBI	2026-09-10
Oracle	ELSA-2026-66179-0	OL9	perl-DBI	2026-09-14
Oracle	ELSA-2026-49758	OL7	perl-GD	2026-09-09
Oracle	ELSA-2026-67156-0	OL10	perl	2026-09-15
Oracle	ELSA-2026-67155-0	OL9	perl	2026-09-15
Oracle	ELSA-2026-67269-0	OL8	perl-YAML-Syck	2026-09-15
Oracle	ELSA-2026-65899-0	OL10	postgresql16-postgis	2026-09-14
Oracle	ELSA-2026-67280-0	OL10	postgresql18	2026-09-15
Oracle	ELSA-2026-66204-0	OL9	python-lxml	2026-09-14
Oracle	ELSA-2026-67147-0	OL10	python-tornado	2026-09-15
Oracle	ELSA-2026-67146-0	OL9	python-tornado	2026-09-15
Oracle	ELSA-2026-9031	OL7	python-urllib3	2026-09-10
Oracle	ELSA-2026-66203-0	OL9	python3.12-lxml	2026-09-14
Oracle	ELSA-2026-64795-0	OL10	python3.14-cryptography	2026-09-09
Oracle	ELSA-2026-64774-0	OL9	python3.14-cryptography	2026-09-09
Oracle	ELSA-2026-65897-0	OL8	qt5-qtbase	2026-09-10
Oracle	ELSA-2026-65993-0	OL9	qt5-qtbase	2026-09-10
Oracle	ELSA-2026-65816-0	OL10	qt6-qt5compat	2026-09-10
Oracle	ELSA-2026-64823-0	OL8	redis:6	2026-09-14
Oracle	ELSA-2026-65120-0	OL9	redis:7	2026-09-09
Oracle	ELSA-2026-67286-0	OL10	rust	2026-09-15
Oracle	ELSA-2026-67285-0	OL9	rust	2026-09-15
Oracle	ELSA-2026-64818-0	OL10	skopeo	2026-09-09
Oracle	ELSA-2026-65159-0	OL10	thunderbird	2026-09-09
Oracle	ELSA-2026-65160-0	OL8	thunderbird	2026-09-10
Oracle	ELSA-2026-65158-0	OL9	thunderbird	2026-09-09
Oracle	ELSA-2026-64796-0	OL10	valkey	2026-09-09
Oracle	ELSA-2026-64807-0	OL9	valkey	2026-09-09
Oracle	ELSA-2026-66336-0	OL10	vim	2026-09-14
Oracle	ELSA-2026-66348-0	OL8	vim	2026-09-14
Oracle	ELSA-2026-66366-0	OL9	vim	2026-09-14
Oracle	ELSA-2026-64772-0	OL8	xmlrpc-c	2026-09-09
Oracle	ELSA-2026-64787-0	OL10	xz	2026-09-09
Red Hat	RHSA-2026:58821-01	EL8.4	fence-agents	2026-09-16
Red Hat	RHSA-2026:58835-01	EL8.6	fence-agents	2026-09-16
Red Hat	RHSA-2026:58822-01	EL8.8	fence-agents	2026-09-16
Red Hat	RHSA-2026:58546-01	EL9.2	fence-agents	2026-09-16
Red Hat	RHSA-2026:58547-01	EL9.4	fence-agents	2026-09-16
Red Hat	RHSA-2026:58548-01	EL9.6	fence-agents	2026-09-16
Red Hat	RHSA-2026:67319-01	EL9.2	git-lfs	2026-09-16
Red Hat	RHSA-2026:67517-01	EL10.0	grafana	2026-09-15
Red Hat	RHSA-2026:67139-01	EL10	image-builder	2026-09-15
Red Hat	RHSA-2026:67138-01	EL9	image-builder	2026-09-15
Red Hat	RHSA-2026:67979-01	EL10	microcode_ctl	2026-09-16
Red Hat	RHSA-2026:65147-01	EL8	microcode_ctl	2026-09-16
Red Hat	RHSA-2026:66432-01	EL10	osbuild-composer	2026-09-11
Red Hat	RHSA-2026:66327-01	EL10.0	osbuild-composer	2026-09-16
Red Hat	RHSA-2026:67148-01	EL8	osbuild-composer	2026-09-16
Red Hat	RHSA-2026:67450-01	EL9.6	podman	2026-09-16
Red Hat	RHSA-2026:59243-01	EL10	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59238-01	EL10.0	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59240-01	EL7	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59241-01	EL8	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59248-01	EL8.4	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59246-01	EL8.6	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59245-01	EL8.8	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59242-01	EL9	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59239-01	EL9.2	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59244-01	EL9.4	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59247-01	EL9.6	python-pyasn1	2026-09-16
Red Hat	RHSA-2026:59329-01	EL7	resource-agents	2026-09-16
Red Hat	RHSA-2026:58820-01	EL8.4	resource-agents	2026-09-16
Red Hat	RHSA-2026:58834-01	EL8.6	resource-agents	2026-09-16
Red Hat	RHSA-2026:58811-01	EL8.8	resource-agents	2026-09-16
Slackware	SSA:2026-252-01		xz	2026-09-09
SUSE	SUSE-SU-2026:23574-1	SLE16.0	389-ds	2026-09-14
SUSE	openSUSE-SU-2026:11739-1	TW	389-ds	2026-09-12
SUSE	SUSE-SU-2026:4187-1	oS15.4	389-ds	2026-09-15
SUSE	SUSE-SU-2026:23601-1	SLE16.0	LibVNCServer	2026-09-14
SUSE	SUSE-SU-2026:4156-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	MozillaFirefox, MozillaFirefox-branding-SLE, mozilla-nspr, mozilla-nss, rust-cbindgen	2026-09-14
SUSE	SUSE-SU-2026:4140-1	SLE12	MozillaFirefox, mozilla-nspr, mozilla-nss, rust-cbindgen	2026-09-14
SUSE	SUSE-SU-2026:23590-1	SLE16.0	MozillaFirefox, mozilla-nss, mozilla-nspr, rust-cbindgen	2026-09-14
SUSE	SUSE-SU-2026:23475-1	SLE-m6.0	NetworkManager	2026-09-09
SUSE	SUSE-SU-2026:23525-1	SLE-m6.1	NetworkManager	2026-09-11
SUSE	SUSE-SU-2026:23499-1	SLE-m6.2	NetworkManager	2026-09-10
SUSE	SUSE-SU-2026:4181-1	SLE12	NetworkManager	2026-09-15
SUSE	SUSE-SU-2026:4144-1	SLE15 oS15.4	NetworkManager	2026-09-14
SUSE	SUSE-SU-2026:4148-1	SLE15 oS15.6	NetworkManager	2026-09-14
SUSE	SUSE-SU-2026:23656-1	SLE16.0	NetworkManager	2026-09-14
SUSE	SUSE-SU-2026:23639-1	SLE16.0	NetworkManager	2026-09-14
SUSE	SUSE-SU-2026:23670-1	SLE-m6.2	acl, attr	2026-09-14
SUSE	SUSE-SU-2026:4176-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	acl, attr	2026-09-14
SUSE	SUSE-SU-2026:4154-1	SLE15 oS15.4	ansible-core	2026-09-14
SUSE	openSUSE-SU-2026:21828-1	oS16.0	ansible-core	2026-09-11
SUSE	openSUSE-SU-2026:11729-1	TW	ansible-creator	2026-09-11
SUSE	openSUSE-SU-2026:11763-1	TW	ant	2026-09-15
SUSE	SUSE-SU-2026:23593-1	SLE16.0	apache2-mod_auth_openidc	2026-09-14
SUSE	SUSE-SU-2026:23551-1	SLE16.0	apr-util	2026-09-14
SUSE	SUSE-SU-2026:23659-1	SLE16.0	aws-nitro-enclaves-cli	2026-09-14
SUSE	SUSE-SU-2026:23643-1	SLE16.0	aws-nitro-enclaves-cli	2026-09-14
SUSE	SUSE-SU-2026:4125-1	MP4.3 SLE15 oS15.4	azure-storage-azcopy	2026-09-11
SUSE	openSUSE-SU-2026:11740-1	TW	azure-storage-azcopy	2026-09-12
SUSE	openSUSE-SU-2026:11767-1	TW	bson-devel	2026-09-15
SUSE	SUSE-SU-2026:23494-1	SLE-m6.2	bzip2	2026-09-10
SUSE	SUSE-SU-2026:23627-1	SLE16.0	bzip2	2026-09-14
SUSE	SUSE-SU-2026:23597-1	SLE16.0	c-ares	2026-09-14
SUSE	openSUSE-SU-2026:11730-1	TW	cargo-audit	2026-09-11
SUSE	openSUSE-SU-2026:11770-1	TW	chirp-20260911	2026-09-15
SUSE	openSUSE-SU-2026:11714-1	TW	chromedriver	2026-09-10
SUSE	openSUSE-SU-2026:11750-1	TW	chromedriver	2026-09-13
SUSE	openSUSE-SU-2026:0319-1	osB15	chromium	2026-09-11
SUSE	SUSE-SU-2026:4179-1	SLE12	clamav	2026-09-14
SUSE	SUSE-SU-2026:4180-1	SLE15 oS15.6	clamav	2026-09-14
SUSE	SUSE-SU-2026:2834-2	SLE5.5 SLE-m5.5	clamav	2026-09-14
SUSE	openSUSE-SU-2026:21824-1	oS16.0	containerized-data-importer1.65	2026-09-11
SUSE	openSUSE-SU-2026:11732-1	TW	containerized-data-importer1.66	2026-09-12
SUSE	openSUSE-SU-2026:11715-1	TW	corosync	2026-09-10
SUSE	SUSE-SU-2026:23464-1	SLE-m6.2	cpio	2026-09-09
SUSE	SUSE-SU-2026:23612-1	SLE16.0	cpio	2026-09-14
SUSE	SUSE-SU-2026:23521-1	SLE-m6.1	curl	2026-09-11
SUSE	SUSE-SU-2026:23498-1	SLE-m6.2	curl	2026-09-10
SUSE	SUSE-SU-2026:23638-1	SLE16.0	curl	2026-09-14
SUSE	SUSE-SU-2026:23562-1	SLE16.0	dhcpcd	2026-09-14
SUSE	openSUSE-SU-2026:11765-1	TW	docker	2026-09-15
SUSE	SUSE-SU-2026:4139-1	SLE15	dovecot23	2026-09-14
SUSE	SUSE-SU-2026:23595-1	SLE16.0	dovecot24	2026-09-14
SUSE	SUSE-SU-2026:23513-1	SLE-m6.1	dracut	2026-09-11
SUSE	SUSE-SU-2026:23466-1	SLE-m6.2	dracut	2026-09-09
SUSE	SUSE-SU-2026:23614-1	SLE16.0	dracut	2026-09-14
SUSE	SUSE-SU-2026:23589-1	SLE16.0	emacs	2026-09-14
SUSE	SUSE-SU-2026:4150-1	SLE15 oS15.4	ffmpeg-4	2026-09-14
SUSE	SUSE-SU-2026:4149-1	SLE15 oS15.6	ffmpeg-4	2026-09-14
SUSE	SUSE-SU-2026:23469-1	SLE-m6.2	fuse-overlayfs	2026-09-09
SUSE	SUSE-SU-2026:23618-1	SLE16.0	fuse-overlayfs	2026-09-14
SUSE	openSUSE-SU-2026:11720-1	TW	ggml-devel	2026-09-10
SUSE	openSUSE-SU-2026:11771-1	TW	gimp	2026-09-15
SUSE	SUSE-SU-2026:23573-1	SLE16.0	go1.25-openssl	2026-09-14
SUSE	SUSE-SU-2026:23576-1	SLE16.0	go1.26-openssl	2026-09-14
SUSE	SUSE-SU-2026:4106-1	SLE15 oS15.3	golang-github-vpenso-prometheus_slurm_exporter	2026-09-09
SUSE	SUSE-SU-2026:4178-1	SLE12	google-cloud-sap-agent	2026-09-14
SUSE	SUSE-SU-2026:23619-1	SLE16.0	google-cloud-sap-agent	2026-09-14
SUSE	openSUSE-SU-2026:21834-1	oS16.0	google-cloud-sap-agent	2026-09-15
SUSE	openSUSE-SU-2026:11742-1	TW	google-guest-agent	2026-09-13
SUSE	SUSE-SU-2026:23548-1	SLE-m6.0	google-osconfig-agent	2026-09-14
SUSE	openSUSE-SU-2026:11743-1	TW	google-osconfig-agent	2026-09-13
SUSE	openSUSE-SU-2026:11751-1	TW	google-osconfig-agent	2026-09-13
SUSE	SUSE-SU-2026:23625-1	SLE16.0	govulncheck-vulndb	2026-09-14
SUSE	SUSE-SU-2026:23572-1	SLE16.0	gstreamer-devtools	2026-09-14
SUSE	SUSE-SU-2026:23550-1	SLE16.0	gzip	2026-09-14
SUSE	openSUSE-SU-2026:11766-1	TW	hauler	2026-09-15
SUSE	openSUSE-SU-2026:21841-1	oS16.0	hauler	2026-09-15
SUSE	SUSE-SU-2026:23546-1	SLE-m6.0	helm	2026-09-14
SUSE	SUSE-SU-2026:23456-1	SLE-m6.0 SLE-m6.2	helm	2026-09-09
SUSE	SUSE-SU-2026:23522-1	SLE-m6.1	helm	2026-09-11
SUSE	SUSE-SU-2026:23506-1	SLE-m6.2	helm	2026-09-10
SUSE	SUSE-SU-2026:4175-1	SLE15 SLE5.5 SLE-m5.5	helm	2026-09-14
SUSE	openSUSE-SU-2026:21809-1	oS16.0	helm	2026-09-10
SUSE	SUSE-SU-2026:23610-1	SLE16.0	java-17-openjdk	2026-09-14
SUSE	SUSE-SU-2026:4107-1	SLE12	java-1_8_0-ibm	2026-09-09
SUSE	SUSE-SU-2026:4153-1	SLE15	java-1_8_0-ibm	2026-09-14
SUSE	SUSE-SU-2026:23624-1	SLE16.0	java-21-openjdk	2026-09-14
SUSE	SUSE-SU-2026:23591-1	SLE16.0	java-25-openjdk	2026-09-14
SUSE	SUSE-SU-2026:23671-1	SLE-m6.2	jq	2026-09-14
SUSE	openSUSE-SU-2026:11725-1	TW	jupyter-nbconvert	2026-09-11
SUSE	openSUSE-SU-2026:11704-1	TW	kbfs	2026-09-09
SUSE	SUSE-SU-2026:4190-1	SLE11	kernel	2026-09-15
SUSE	SUSE-SU-2026:4120-1	SLE15	kernel	2026-09-10
SUSE	SUSE-SU-2026:23481-1	SLE6.0 SLE-m6.0	kernel	2026-09-09
SUSE	SUSE-SU-2026:23477-1	SLE6.0 SLE-m6.0	kernel	2026-09-09
SUSE	SUSE-SU-2026:23490-1	SLE6.0 SLE-m6.0	kernel	2026-09-09
SUSE	SUSE-SU-2026:23491-1	SLE6.0 SLE-m6.0	kernel	2026-09-09
SUSE	SUSE-SU-2026:23529-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-09-11
SUSE	SUSE-SU-2026:23528-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-09-11
SUSE	SUSE-SU-2026:23510-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-09-11
SUSE	openSUSE-SU-2026:11703-1	TW	kernel-devel	2026-09-09
SUSE	openSUSE-SU-2026:21849-1	oS16.0	kimi-code	2026-09-15
SUSE	openSUSE-SU-2026:11753-1	TW	libBasicUsageEnvironment2	2026-09-14
SUSE	SUSE-SU-2026:23583-1	SLE16.0	libgpg-error	2026-09-14
SUSE	SUSE-SU-2026:23621-1	SLE16.0	libidn	2026-09-14
SUSE	openSUSE-SU-2026:11721-1	TW	libmariadb-devel	2026-09-10
SUSE	openSUSE-SU-2026:11707-1	TW	libopenslide-devel	2026-09-09
SUSE	SUSE-SU-2026:4188-1	SLE15	libpcap	2026-09-15
SUSE	SUSE-SU-2026:4195-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	libpcap	2026-09-15
SUSE	SUSE-SU-2026:4194-1	SLE15 oS15.6	libpcap	2026-09-15
SUSE	SUSE-SU-2026:23514-1	SLE-m6.1	libpng16	2026-09-11
SUSE	SUSE-SU-2026:23564-1	SLE16.0	librest	2026-09-14
SUSE	SUSE-SU-2026:4105-1	SLE12	libsoup	2026-09-09
SUSE	SUSE-SU-2026:4095-1	SLE15	libssh2_org	2026-09-09
SUSE	SUSE-SU-2026:23519-1	SLE-m6.1	libusb-1_0	2026-09-11
SUSE	SUSE-SU-2026:23501-1	SLE-m6.2	libusb-1_0	2026-09-10
SUSE	SUSE-SU-2026:23660-1	SLE16.0	libusb-1_0	2026-09-14
SUSE	SUSE-SU-2026:23644-1	SLE16.0	libusb-1_0	2026-09-14
SUSE	SUSE-SU-2026:23515-1	SLE-m6.1	libvirt	2026-09-11
SUSE	SUSE-SU-2026:23460-1	SLE-m6.2	libvirt	2026-09-09
SUSE	SUSE-SU-2026:4141-1	SLE12	libvirt	2026-09-14
SUSE	SUSE-SU-2026:23603-1	SLE16.0	libvirt	2026-09-14
SUSE	SUSE-SU-2026:4096-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	libzypp, zypper	2026-09-09
SUSE	SUSE-SU-2026:23547-1	SLE-m6.0	libzypp, zypper	2026-09-14
SUSE	SUSE-SU-2026:23507-1	SLE-m6.2	libzypp, zypper	2026-09-10
SUSE	SUSE-SU-2026:4129-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	libzypp, zypper	2026-09-11
SUSE	SUSE-SU-2026:4112-1	SLE15 oS15.6	libzypp, zypper	2026-09-10
SUSE	openSUSE-SU-2026:21808-1	oS16.0	libzypp, zypper	2026-09-10
SUSE	SUSE-SU-2026:23606-1	SLE16.0	lkl	2026-09-14
SUSE	SUSE-SU-2026:23496-1	SLE-m6.2	mcphost	2026-09-10
SUSE	SUSE-SU-2026:23636-1	SLE16.0	mcphost	2026-09-14
SUSE	SUSE-SU-2026:23630-1	SLE16.0	msgpack-c	2026-09-14
SUSE	SUSE-SU-2026:23476-1	SLE-m6.0	multipath-tools	2026-09-09
SUSE	SUSE-SU-2026:23526-1	SLE-m6.1	multipath-tools	2026-09-11
SUSE	SUSE-SU-2026:23502-1	SLE-m6.2	multipath-tools	2026-09-10
SUSE	SUSE-SU-2026:23662-1	SLE16.0	multipath-tools	2026-09-14
SUSE	SUSE-SU-2026:23646-1	SLE16.0	multipath-tools	2026-09-14
SUSE	SUSE-SU-2026:23604-1	SLE16.0	openexr	2026-09-14
SUSE	SUSE-SU-2026:23478-1	SLE-m6.0	opensc	2026-09-09
SUSE	SUSE-SU-2026:23527-1	SLE-m6.1	opensc	2026-09-11
SUSE	SUSE-SU-2026:23543-1	SLE-m6.2	opensc	2026-09-11
SUSE	SUSE-SU-2026:4108-1	SLE12	opensc	2026-09-09
SUSE	SUSE-SU-2026:4123-1	SLE15 oS15.6	opensc	2026-09-10
SUSE	SUSE-SU-2026:4122-1	SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	opensc	2026-09-10
SUSE	SUSE-SU-2026:23473-1	SLE-m6.0	openssl-3	2026-09-09
SUSE	SUSE-SU-2026:23512-1	SLE-m6.1	openssl-3	2026-09-11
SUSE	SUSE-SU-2026:23463-1	SLE-m6.2	openssl-3	2026-09-09
SUSE	SUSE-SU-2026:23609-1	SLE16.0	openssl-3	2026-09-14
SUSE	openSUSE-SU-2026:11734-1	TW	perl-Authen-SASL	2026-09-12
SUSE	openSUSE-SU-2026:11745-1	TW	perl-HTML-FormHandler	2026-09-13
SUSE	SUSE-SU-2026:4151-1	SLE15	perl-Mojolicious	2026-09-14
SUSE	openSUSE-SU-2026:11708-1	TW	perl-Net-DNS	2026-09-09
SUSE	SUSE-SU-2026:4182-1	SLE15 oS15.6	perl-Protocol-HTTP2	2026-09-15
SUSE	openSUSE-SU-2026:11735-1	TW	perl-Protocol-HTTP2	2026-09-12
SUSE	SUSE-SU-2026:23633-1	SLE16.0	perl-URI	2026-09-14
SUSE	SUSE-SU-2026:23635-1	SLE16.0	php-composer2	2026-09-14
SUSE	SUSE-SU-2026:4128-1	SLE15 oS15.4	php7	2026-09-11
SUSE	SUSE-SU-2026:23578-1	SLE16.0	postgresql14	2026-09-14
SUSE	SUSE-SU-2026:23579-1	SLE16.0	postgresql15	2026-09-14
SUSE	SUSE-SU-2026:23580-1	SLE16.0	postgresql16	2026-09-14
SUSE	SUSE-SU-2026:23582-1	SLE16.0	postgresql17	2026-09-14
SUSE	SUSE-SU-2026:23577-1	SLE16.0	postgresql18	2026-09-14
SUSE	SUSE-SU-2026:4111-1	SLE15 oS15.6	python-Authlib	2026-09-10
SUSE	SUSE-SU-2026:4191-1	SLE15 oS15.4	python-GitPython	2026-09-15
SUSE	SUSE-SU-2026:4113-1	MP4.3 SLE15	python-aiohttp	2026-09-10
SUSE	SUSE-SU-2026:23571-1	SLE16.0	python-aiohttp	2026-09-14
SUSE	SUSE-SU-2026:23570-1	SLE16.0	python-cryptography	2026-09-14
SUSE	SUSE-SU-2026:23563-1	SLE16.0	python-h2	2026-09-14
SUSE	openSUSE-SU-2026:21827-1	oS16.0	python-jwcrypto	2026-09-11
SUSE	SUSE-SU-2026:4104-1	SLE12	python-pip	2026-09-09
SUSE	SUSE-SU-2026:23607-1	SLE16.0	python-ruff	2026-09-14
SUSE	SUSE-SU-2026:4109-1	MP4.3 SLE15 oS15.4	python-sqlparse	2026-09-09
SUSE	SUSE-SU-2026:4145-1	SLE15 oS15.6	python-sqlparse	2026-09-14
SUSE	SUSE-SU-2026:23561-1	SLE16.0	python-sqlparse	2026-09-14
SUSE	SUSE-SU-2026:23634-1	SLE16.0	python-sqlparse	2026-09-14
SUSE	SUSE-SU-2026:23523-1	SLE-m6.1	python-tornado6	2026-09-11
SUSE	SUSE-SU-2026:4189-1	oS15.4	python310	2026-09-15
SUSE	openSUSE-SU-2026:11756-1	TW	python311	2026-09-14
SUSE	openSUSE-SU-2026:11757-1	TW	python312	2026-09-14
SUSE	openSUSE-SU-2026:11709-1	TW	python313-dnspython	2026-09-09
SUSE	openSUSE-SU-2026:11724-1	TW	python313-geopy	2026-09-11
SUSE	openSUSE-SU-2026:11711-1	TW	python313-idna	2026-09-09
SUSE	openSUSE-SU-2026:11736-1	TW	python313-modelscope	2026-09-12
SUSE	openSUSE-SU-2026:11746-1	TW	python313-modelscope-hub	2026-09-13
SUSE	openSUSE-SU-2026:11726-1	TW	python313-pypdf	2026-09-11
SUSE	openSUSE-SU-2026:11748-1	TW	python315	2026-09-13
SUSE	SUSE-SU-2026:4174-1	SLE15 oS15.3	python39.SUSE_SLE-15-SP3_Update	2026-09-14
SUSE	SUSE-SU-2026:23567-1	SLE16.0	rav1e	2026-09-14
SUSE	SUSE-SU-2026:23518-1	SLE-m6.1	rpcbind	2026-09-11
SUSE	SUSE-SU-2026:23495-1	SLE-m6.2	rpcbind	2026-09-10
SUSE	SUSE-SU-2026:23628-1	SLE16.0	rpcbind	2026-09-14
SUSE	openSUSE-SU-2026:11737-1	TW	sshamble	2026-09-12
SUSE	SUSE-SU-2026:23465-1	SLE-m6.2	sssd	2026-09-09
SUSE	SUSE-SU-2026:23613-1	SLE16.0	sssd	2026-09-14
SUSE	SUSE-SU-2026:4147-1	SLE12	strongswan	2026-09-14
SUSE	SUSE-SU-2026:4115-1	SLE15	strongswan	2026-09-10
SUSE	SUSE-SU-2026:4146-1	SLE15 oS15.4	strongswan	2026-09-14
SUSE	SUSE-SU-2026:4152-1	SLE15 oS15.5	strongswan	2026-09-14
SUSE	SUSE-SU-2026:4143-1	SLE15 oS15.6	strongswan	2026-09-14
SUSE	openSUSE-SU-2026:11749-1	TW	strongswan	2026-09-13
SUSE	openSUSE-SU-2026:11768-1	TW	syncthing	2026-09-15
SUSE	SUSE-SU-2026:23470-1	SLE-m6.2	systemd	2026-09-09
SUSE	SUSE-SU-2026:23454-1	SLE-m6.2	systemd	2026-09-09
SUSE	SUSE-SU-2026:23620-1	SLE16.0	systemd	2026-09-14
SUSE	SUSE-SU-2026:4126-1	SLE12	tomcat	2026-09-11
SUSE	openSUSE-SU-2026:11759-1	TW	tomcat	2026-09-14
SUSE	SUSE-SU-2026:4119-1	SLE15	tomcat10	2026-09-10
SUSE	SUSE-SU-2026:4114-1	SLE15 oS15.6	tomcat11	2026-09-10
SUSE	openSUSE-SU-2026:11761-1	TW	tomcat11	2026-09-14
SUSE	SUSE-SU-2026:23539-1	SLE-m6.1	ucode-intel	2026-09-11
SUSE	SUSE-SU-2026:23459-1	SLE-m6.2	ucode-intel	2026-09-09
SUSE	SUSE-SU-2026:23602-1	SLE16.0	ucode-intel	2026-09-14
SUSE	SUSE-SU-2026:23575-1	SLE16.0	udisks2	2026-09-14
SUSE	SUSE-SU-2026:23552-1	SLE16.0	vim	2026-09-14
SUSE	openSUSE-SU-2026:21815-1	oS16.0	waylyrics	2026-09-10
SUSE	SUSE-SU-2026:23455-1	SLE-m6.0	wget	2026-09-09
SUSE	SUSE-SU-2026:23520-1	SLE-m6.1	wget	2026-09-11
SUSE	SUSE-SU-2026:23592-1	SLE16.0	wicked2nm	2026-09-14
SUSE	openSUSE-SU-2026:11762-1	TW	yast2-samba-client	2026-09-15
SUSE	openSUSE-SU-2026:11769-1	TW	zstd-jni	2026-09-15
Ubuntu	USN-8772-1	22.04 24.04 26.04	aom	2026-09-16
Ubuntu	USN-8571-2	20.04	apache2	2026-09-11
Ubuntu	USN-8747-1	16.04 18.04 20.04 22.04 24.04 26.04	beets	2026-09-10
Ubuntu	USN-8757-1	16.04	cgit	2026-09-14
Ubuntu	USN-8749-1	22.04 24.04 26.04	civetweb	2026-09-14
Ubuntu	USN-8740-1	22.04 24.04 26.04	dotnet8, dotnet10	2026-09-10
Ubuntu	USN-8758-1	26.04	dracut	2026-09-14
Ubuntu	USN-8750-1	20.04 22.04	ffmpeg	2026-09-14
Ubuntu	USN-8716-2	26.04	ffmpeg	2026-09-10
Ubuntu	USN-8741-1	18.04 20.04 22.04 24.04	flatpak	2026-09-10
Ubuntu	USN-8754-1	16.04 18.04 20.04 22.04 24.04	freeciv	2026-09-14
Ubuntu	USN-8737-2	24.04	glibc	2026-09-10
Ubuntu	USN-8739-2	24.04	imagemagick	2026-09-15
Ubuntu	USN-8745-1	22.04 24.04 26.04	kissfft	2026-09-10
Ubuntu	USN-8763-1	24.04 26.04	kitty	2026-09-15
Ubuntu	USN-8752-1	16.04 18.04 20.04 22.04 24.04	konsole	2026-09-14
Ubuntu	USN-8746-1	16.04 18.04 20.04 22.04	libebml	2026-09-10
Ubuntu	USN-8753-1	24.04 26.04	libinput	2026-09-14
Ubuntu	USN-8730-2	22.04	linux-azure	2026-09-15
Ubuntu	USN-8761-1	24.04	linux-azure	2026-09-15
Ubuntu	USN-8748-1	24.04	linux-nvidia-6.17	2026-09-10
Ubuntu	USN-8760-1	24.04	linux-nvidia-7.0	2026-09-15
Ubuntu	USN-8742-1	24.04	netty	2026-09-10
Ubuntu	USN-8563-5	22.04 24.04 26.04	nginx	2026-09-14
Ubuntu	USN-8514-2	14.04 18.04 20.04	openssh	2026-09-16
Ubuntu	USN-8675-2	26.04	perl	2026-09-09
Ubuntu	USN-8743-1	22.04 24.04 26.04	php8.1, php8.3, php8.5	2026-09-10
Ubuntu	USN-8769-1	16.04 18.04 20.04 22.04 24.04 26.04	phpseclib	2026-09-15
Ubuntu	USN-8762-1	22.04 24.04 26.04	policykit-1	2026-09-15
Ubuntu	USN-8765-1	16.04 18.04 20.04 22.04 24.04	python-sql	2026-09-15
Ubuntu	USN-8759-1	16.04 18.04 20.04 22.04 24.04 26.04	python-webob	2026-09-16
Ubuntu	USN-8744-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	python2.7, python3.4, python3.5, python3.6, python3.7, python3.8, python3.9, python3.10, python3.11, python3.12, python3.14	2026-09-10
Ubuntu	USN-8768-1	20.04 22.04 24.04	shibboleth-sp	2026-09-15
Ubuntu	USN-8770-1	16.04 18.04 20.04 22.04 24.04	simplesamlphp	2026-09-15
Ubuntu	USN-8767-1	20.04 22.04 24.04	snapcast	2026-09-15
Ubuntu	USN-8764-1	20.04 22.04 24.04 26.04	srt	2026-09-15
Ubuntu	USN-8766-1	22.04 24.04 26.04	suricata-update	2026-09-15
Ubuntu	USN-8751-1	18.04 20.04 22.04 26.04	urwid	2026-09-14
Ubuntu	USN-8755-1	20.04 22.04 24.04 26.04	vips	2026-09-14
Ubuntu	USN-8756-1	16.04 18.04	yelp	2026-09-14

Full Story (comments: none)