Welcome to the LWN.net Weekly Edition for January 29, 2026

This edition contains the following feature content:

• Open source for phones: postmarketOS: an overview of an alternative Linux operating system for mobile devices.
• Linux Kernel Runtime Guard reaches its 1.0 release: runtime integrity checking for the Linux kernel.
• Who should vote in Fedora elections?: the project takes up the sticky question of what makes a contributor eligible to vote in FESCo elections.
• Filesystem medley: EROFS, NTFS, and XFS: status updates on three filesystems used with Linux.
• Fedora and GPG 2.5: as GNU Privacy Guard's 2.4 series approaches its end of life, Fedora discusses possible alternatives.
• Implicit arguments for BPF kfuncs: Ihor Solodrai attempts to solve the problem of passing arguments to kfuncs from BPF programs.

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)

Open source for phones: postmarketOS

Phones running Linux are ubiquitous these days and it has been that way since Android started working toward dominance in the smartphone market. Unfortunately, Android has slowly increased its freedom-unfriendliness and has become something of a privacy nightmare. In a talk entitled "We need an open-source phone OS" at Open Source Summit Japan 2025, Luca Weiss described the smartphone landscape and gave an overview of postmarketOS as an alternative Linux operating system for mobile handsets.

Weiss introduced himself as a software engineer at Fairphone, "which is a Dutch brand to make sustainable mobile phones". In his free time, he is a postmarketOS core contributor and a maintainer for the OpenRazer project to create Linux drivers for Razer gaming peripherals. He stressed that the talk was not being done for his employer; "these are my opinions".

Mobile phone OSes

There is a duopoly for mobile operating systems right now, he began: iOS for Apple phones and Android for phones from more than 100 manufacturers. With only a few exceptions, all of the Android phones are shipping with the proprietary Google Play Services so that the Google Play store is available. Most customers require this because they do not know where to get apps otherwise; in addition, some apps that they want are only available to phones with Google Play Services.

In order to be able to ship those services, Android phone makers must be bound by Google's rules, which is a double-edged sword. On the good side, there are some minimal security requirements for the Android version, as well as policies ensuring API compatibility for the apps. However, those manufacturers have far less independence in what they can do on their phones. It also requires a business relationship with a US company, which may be problematic for companies in some countries currently and it is unknown if those restrictions might expand over time. Beyond that, Google could change its rules at any time or even lose interest and stop providing Android source code at all.

There are multiple problem areas because there are no alternatives to that duopoly, he said. Google bundles and pushes privacy-invasive apps; his example was Google Photos, which defaults to sending photos to the Google cloud and, if that is disabled, regularly pops up messages to "warn" users that their photos are not being backed up—with a default action of re-enabling the feature to dismiss the popup.

While the Android Open Source Project (AOSP) is available under the Apache 2 license, development is done behind closed doors with releases tossed over the wall; getting code into AOSP is not impossible, he said, unless the feature does not align with Google's business interests. There is also the question of whether Android will stay open source, Weiss said. Meanwhile, installing apps that do not come from the Play store ("which they call 'sideloading'") is being restricted to apps made by developers registered with the company, which harms users who can no longer install whichever apps they want.

There is a large amount of proprietary code in any phone running Android and, even if that code was replaced with open-source software, there would still be proprietary code running in modems and other parts of the system. Android runs as user-space programs on top of the GPLv2-licensed Linux kernel, so the Android code can be released (or not) subject to the whims of Google, but the kernel code needs to be released when phones using it start shipping. Android and Linux are only running on a small part of the system-on-chip (SoC) for a phone, however; there are multiple other co-processors of various sorts (GPU, NPU, ...) that run proprietary firmware which cannot be replaced with free software because it is signed with a key that the vendor controls. Even if the signature checking is disabled, there are no efforts that he is aware of to create free alternatives for that firmware.

There are alternative Android distributions (or ROMs), such as LineageOS, /e/OS, CalyxOS, and others, Weiss said, which are more open source than stock Android, but still rely on proprietary blobs. Libraries and binaries that are shipped on stock Android are being incorporated into the community distributions. This includes GPU drivers, modem drivers, and the like, which sit between Android and the Linux kernel, but use non-standard kernel interfaces; he is not aware of any efforts to replace those components with open-source alternatives either.

Relying on those blobs means that all security updates have to come from the vendor; when the vendor stops updating a device because it is at its end of life, updates to those components will not be easily available, though they may be obtainable from updates to similar devices. Those alternative Android distributions are also reliant on Google releasing the AOSP code, which used to happen when the new code started shipping but had recently been delayed by two months. Since the talk, the company has announced that it will only be releasing AOSP code twice per year.

postmarketOS

The tagline for postmarketOS is "The Linux distribution for mobile phones and beyond...", he said to introduce the project. The goal is to make an operating system for phones with both user-space and kernel code that is fully open. PostmarketOS developers want to ensure "that the foundations are laid to actually be able to support devices for a long time"; that's possible because they are using the upstream kernel and not a fork of an older kernel. That allows updating all of the components "and if there's an incompatibility, you can actually fix it without any big issues".

The distribution is aimed at being largely generic, rather than having lots of device-specific parts. Right now, most devices have a device-specific root filesystem and boot image, but the plan is to have a single root filesystem for all devices, with just the kernel and some configuration that is customized for the device.

PostmarketOS is a volunteer-driven and donation-funded independent project, Weiss said. The donations are used to fund infrastructure, including "hacker phones to actually work on together", and to "have some stuff for the FOSDEM conference, where we're always present". It uses Alpine Linux and its package manager, so postmarketOS users "can install everything that you would ever want that is in the package repositories". On top of the Alpine base, postmarketOS provides some extra tooling, device packages, build infrastructure for creating install images, and documentation including an extensive wiki.

Android devices are based on a fork of a specific LTS kernel version that never changes for the life of the device. That lifetime is generally three years, which fits well within the lifecycle of the LTS kernels; once that is done, "you're stuck with this old Linux kernel version with millions of lines of code added and modified compared to the upstream version of Linux".

Instead of that path, postmarketOS is focused on using the upstream kernel by pulling the latest from kernel.org and adding the changes needed for specific devices. The developers are working to get the "ten to 100 patches" for each device into the upstream kernel, so that the diff gets smaller and they can more easily use the upstream kernels going forward. In addition, release candidates and linux-next can be tested to ensure that there are not any regressions and that devices will continue to function with upcoming kernel releases.

By sticking with upstream, the project gets the latest features in the kernel. "There's a lot of things happening there that are actually really cool, and there's no reason that you wouldn't want it on your phone as well". User-space components like to use the newer kernel features, so it is best not to get left behind.

Sometimes the postmarketOS developers are asked why they are not using parts of Android like some other projects do. For example, Ubuntu Touch is a contributor to the Halium project, which repackages "Android bits" and provides a translation layer that will allow Android hardware abstraction layers (HALs), such as the camera HAL, to work on top of a regular Linux user space. It will also allow binaries that are built with the Android C library (bionic) to be used from programs built with the GNU C library (glibc) via libhybris. "There are some very practical reasons for doing this", he said, because it allows relying on the hardware maker to provide a well-functioning camera driver for the hardware.

There are some downsides to that approach, however, including depending on Android updates and proprietary blobs for the functioning of the peripherals. It also would make the project dependent on a "sometimes a bit flaky layer between the Android components and the Linux components". Beyond that, it "doesn't encourage the development of native solutions", such as libcamera, which he noted had featured in the talk just prior to his. That does mean that the cameras that are supported have "quite limited" photo quality compared to, say, Ubuntu Touch, currently; the goal is to get to an acceptable photo quality while always using "100% open-source software".

Status and plans

Currently, postmarketOS "is not a finished product in any sense", Weiss said, but it is still being used. The project does not have any "report to the mothership" functionality or other analytics, so it relies on "anecdotal evidence" from social media and talking to users at conferences to get a sense for how it is being used. Some people do use postmarketOS as a daily driver phone, though some of those also carry a second phone for calls and, say, access to a banking app. "Banks are quite annoying with a lot of app requirements."

There are a lot of devices that are supported by postmarketOS: 111 in the "community" category, which covers the best-supported devices, 342 in "testing", which ranges from barely booting to mostly working for some use cases ("watching YouTube on your couch"), and 250 in the "downstream" category, which still use the Android kernel for the device. When the project began, there was little support for phone devices in the upstream kernel, so everything was in the downstream category; now the kernel supports around 450 devices, so those devices have moved to the other categories over time.

PostmarketOS is not ready for the average person at this point, he said, "but I would say that it is definitely ready for the average hacker". Those who want to hack on a phone will find it to be in good shape; even most of the phones in the testing category will boot and allow logging in via ssh. At that point, "you can do fun things with the phone". He noted that his FOSDEM 2025 talk went into more detail on device support for postmarketOS.

There are lots of plans for the future and various things being worked on, but there is no real roadmap because postmarketOS is volunteer-driven. He suggested following the blog. There are monthly progress reports posted there, which give a good sense of the progress being made. There is a big difference in what is working today compared to a year or two ago, he said.

"What can you actually do with postmarketOS today?" The first step is to install it; attendees probably already have an old phone—or can get a used one cheaply—that can run it. Once booted, the phone can be hacked on over ssh or with a GUI, such as Plasma Mobile, Phosh, GNOME Mobile, or Sxmo for a tiling-window-manager experience.

It is, after all, a Linux system, so users can do anything they might do with any other such system: run Docker containers, make a Kubernetes cluster of phones, or access USB peripherals of various sorts. The compost.party web site (which was not responding as this is written) runs on "a solar-powered old, broken phone"; postmarketOS could easily be used for something like that, he said. Other creative uses include a media-playback device, a musical instrument, or part of an audio-production system.

He noted that postmarketOS "could really use some help" on the technical side. Most of that work is on upstream projects, such as on the kernel for more hardware enablement and stability, middleware projects like libcamera or feedbackd (for haptic and visual feedback), improving the UI or adding features for various mobile GUI projects. Other possibilities are upgrading existing apps or developing new ones and helping to maintain packages in the Alpine aports repository and the postmarketOS-specific pmaports repository. Much of that work can be done from desktop Linux and some of it will not just improve mobile Linux or postmarketOS, but also Linux running on larger systems.

The project also welcomes contributions from non-developers, Weiss said, and there are many different ways to do so. If they are "tech curious", contributors could install postmarketOS on a phone; if they encounter any problems in doing so, they should point out where the documentation was inadequate—or propose updates to fix it. Translations for the user interfaces and apps would help as would getting the word out about the project in diverse spaces—including ones catering to non-technical people. Contributors can help out with the monthly blog posts, the podcast, which has languished a bit due to lack of time, or on applying for funding grants in different parts of the world.

Weiss took a few audience questions after completing his talk. One asked about a "golden device" that he would recommend for those who want to start working with postmarketOS. The OnePlus 6 and 6T were long recommended by the project, he said, but those are getting old enough they are hard to find in the used marketplace; the Pixel 3a is well-supported, as is the Fairphone 5. He suggested consulting the devices page on the wiki (linked above), which can help narrow things down based on which peripherals (camera, NFT, etc.) were most needed.

Interested readers may want to check out the YouTube video of the talk and Weiss's slides.

[ I would like to thank the Linux Foundation, LWN's travel sponsor, for assistance with traveling to Tokyo for Open Source Summit Japan. ]

Comments (32 posted)

Linux Kernel Runtime Guard reaches its 1.0 release

The Linux Kernel Runtime Guard (LKRG) is a out-of-tree loadable kernel module that attempts to detect and report violations of the kernel's internal invariants, such as might be caused by an in-progress security exploit or a rootkit. LKRG has been experimental since its initial release in 2018. In September 2025, the project announced the 1.0 version. With the promises of stability that version brings, users might want more information to decide whether to include it in their kernel.

Security through diversity

LKRG's mission is mildly hopeless — if an attacker has already compromised a running kernel, then there is no theoretical reason that the attacker could not also recognize and block or subvert the LKRG kernel module. In practice, however, an attacker would need to actually know to do that, and do it quickly enough to escape the periodic sweeps that LKRG performs. Using LKRG, therefore, raises the bar for attacks on the Linux kernel.

The project's documentation calls this "security through diversity" — if attackers haven't specifically addressed LKRG, running it can help spot attacks that would otherwise pass unnoticed. Of course, there is a cost to using LKRG as well, which makes the choice of whether to use it a tradeoff.

Running it

LKRG is packaged for Arch, Gentoo, NixOS, and Rocky Linux. On other systems, it can be built from source as a DKMS module. Once loaded, it provides a number of sysctl settings to control exactly what it should check for. LKRG supports two general categories of checks: those on the global state of the kernel and those on the state of a process.

The kernel has a lot of global state; right now, LKRG specifically checks a small but important subset of it. Specifically, it verifies whether code and read-only data within the kernel (including loaded modules) has the right permissions in the page table, whether the code or data has been modified (including whether the global SELinux settings have been tampered with), and some CPU-specific state registers. These last include the Supervisor Mode Execution Protection (SMEP) and Supervisor Mode Access Prevention (SMAP) settings, which prevent kernel code from accessing user-space memory. SMEP prevents the CPU from executing user-space code while in the kernel, and SMAP prevents other accesses. That protection must be disabled when the kernel is deliberately copying data to or from user-space memory, but the rest of the time it prevents an exploit in the kernel from making use of data stored in user space.

The SMEP and SMAP settings are trivial to check, but ensuring that the kernel's data has not been tampered with is more involved. When it first loads, LKRG takes a hash of all the data that should not change and stores this hash in its own memory. Then the data can be periodically re-hashed and checked against the stored hash. Some parts of the kernel can't be covered by the hash, because they do change during normal operation, but can still be checked for consistency against other parts of the kernel. For example, LKRG scans kernel memory to find loaded modules, and compares this to the kernel's own list of loaded modules. If a module is present but not in the list, it is probably trying to hide, and therefore likely to be nefarious. Each kernel module also gets its own hash calculated on first load and then checked periodically.

Kprobes also pose problems: they are dynamically inserted into otherwise-unchanging kernel code. LKRG can't ensure that these changes are correct using a hash, but it can check that the changes only show up when kprobes are actually enabled, and that the "enabled" setting is what it's expected to be.

By default, LKRG checks these global properties at 15-second intervals, but it can be configured to do so more or less frequently, or only when asked to do so. If it does find something suspicious, it can print a log message, restore the previous SELinux "enforcing" setting and SMEP/SMAP state, or panic the kernel.

The other set of checks it runs are per-process. These are also run periodically, but can additionally run just before any process attempts to do some privileged operation. LKRG verifies that the process has the credentials for the operation that it is about to perform, and that the stack pointer (and optionally the frames on the stack) make sense.

Each of these checks can be configured individually, but it is also possible to use LKRG "profiles". It offers several pre-configured levels of detection and enforcement. These range from "detect things only when requested" to "double-check everything whenever possible" (set via the lkrg.profile_validate sysctl) and from "when a violation is detected, log it" to "panic the kernel" (set via the lkrg.profile_enforce sysctl). The default is a reasonable middle ground: check kernel integrity without too much performance overhead, log for suspicious things, and crash the kernel when there's a definite problem.

Is it worth it?

On the one hand, LKRG comes with some admitted downsides: LKRG's default enforcement level is incompatible with running virtual machines VirtualBox; it works fine from within a virtual machine, but causes spurious alarms on the host when the guest CPU has a state that doesn't match the host. [An LKRG maintainer wrote in to point out that the problem exists only on VirtualBox, and that KVM works in the default configuration.] That's not a fundamental limitation of LKRG — it could be extended to track enters and exits from virtual machines, and adjust its expectations accordingly — but it does make it hard to recommend LKRG by default, given how many workloads involve some amount of virtualization.

There is also the matter of performance. A comparison of the Phoronix benchmark suite from 2020 with and without LKRG suggests that it introduced a performance overhead of about 4.4%. Since then, the LKRG developers have gotten this down to around 2.5%, but the error in the measurements makes it hard to be certain of the exact performance penalty, especially since it may be workload-dependent. There is also the fact that, as an out-of-tree module, it does not always support new kernel versions immediately. At the time of writing, it has been tested up through 6.17.0. [The project uses continuous integration testing, and keeps up to date with in-development kernels, but has somewhat infrequent releases.] The project's README suggests that the best use for LKRG would be systems that cannot always update to the latest kernel in response to disclosed vulnerabilities, for whatever reason.

Many users would welcome a small slowdown in the name of security, but there are easier ways to obtain some of the same benefits. For example, the kernel's built-in support for control flow integrity provides much the same benefit as LKRG's stack checking, through well-supported compiler and CPU features. The other things that it validates are less easily replaced, but the kernel has a long history of adopting new built-in ways to protect page-tables. There is always the possibility of bugs in the implementations of these ideas, but it's hard to judge whether LKRG would detect exploitation of those bugs reliably enough to be worthwhile.

On the other hand, the Singularity rootkit has plans to work around LKRG. The Metasploit framework has special code to deal with it and disable exploits that it would detect. It's hard to argue that LKRG is not worth using when it is demonstrably making attackers' lives harder.

Ultimately, LKRG has a relatively niche use case: when the performance overhead is acceptable, the computer's workload doesn't involve virtualization VirtualBox, and the system doesn't run bleeding-edge kernels [or the user is happy to run pre-release versions of LKRG], LKRG can provide defense in depth. Perhaps LKRG's data-validating features will one day make their way into the kernel proper; that does not currently seem to be a priority for the developers. Until LKRG's ideas do make their way into the kernel, users will have to make a judgment call about whether LKRG is right for their use case.

Comments (6 posted)

Who should vote in Fedora elections?

Creating fair governance models for open-source projects is not easy; defining criteria for participants to receive membership and voting rights is a particularly thorny problem for projects that have elections for representative bodies. The Fedora Council, the project's top-level governance body, is wrestling with that conundrum now. This was triggered by a Fedora special-interest group (SIG) granting temporary membership to at least one person for the sole purpose of allowing them to vote in the most recent Fedora Engineering Steering Council (FESCo) election. That opened a large can of worms about what it means to be a contributor and how contributors can be identified for voting purposes.

Fedora's elections are held after each release cycle; for example, the most recent was the FESCo Fedora 43 election, which ran from December 17, 2025 to January 7, 2026. It is not a high bar to be eligible to vote in a FESCo election. First, one must have membership in the "cla_done" group; that is available to anyone who has a Fedora account (which requires agreeing to the Code of Conduct) and has signed the Fedora Project Contributor Agreement. Secondly, a person must be a member of an additional group unrelated to the cla_done group. That could be membership in any of the eligible Fedora groups, and there are literally hundreds of Fedora groups that fit the bill. It is not difficult at all for someone who is active in the Fedora community in some fashion to gain membership to a group that would allow them to vote in an election.

Temporary SIG membership

Even though the barrier to voting was not high, some thought it should be lower still. During the Fedora 43 FESCo election cycle, Fedora user "JandeMus" asked why he was receiving an error when trying to vote:

It took me almost half an hour to find (some) groups but I have no idea which one to join. Why is this even necessary, can't I, with a FAS [Fedora Account System] account, not just vote? Joining a group means applying first, only for the sake of being able to vote. That's all I want to do.

Fedora does not make things easy.

Hristo Marinov replied with some links to the Fedora documentation about elections and groups. JandeMus replied that he would give up on the idea; he complained again that "Fedora makes things unnecessarily complicated" and that it was a shame that he, and others like him, who would not join a group for voting purposes, were prevented from participating in Fedora elections.

"MatH" replied on January 5 that the group membership requirement was merely "to keep the trolls out", and offered to grant JandeMus membership in the Fedora Join SIG so that he could vote. The Join SIG is a group that is involved in various efforts to welcome new people to Fedora. Marinov questioned whether that was a good or recommended practice, but MatH replied that JandeMus had been on Fedora's Discourse forum for more than two years and had made more than 400 posts, which had garnered lots of likes. "If that is the kind of person we want to keep out of Fedora, then please do let me know. [...] If some AI bots come and ask for membership I'll be sure to turn them down."

Christopher Klooz, one of the forum's moderators, joined in the discussion and objected to the idea that Fedora's group requirements were only to keep trolls out of the elections. He argued that the need to be sponsored into a group besides FAS was intentional and designed to ensure people voting for FESCo had the requisite understanding of the project. After further discussion, he said that MatH had abused his privileges in providing temporary group membership, and that he would report it if it happened again. JandeMus said that he was sorry he had asked the question and apologized "for all the commotion I caused". He also asked that the discussion thread be closed. Klooz responded that JandeMus had brought up a matter that needed attention, and he closed the topic thread.

On January 7, Klooz opened a ticket with the Fedora Council. In the ticket, he reported that MatH's position was shared by others in the Join SIG, and it was unclear how actively it would be used in the future. He asked the council to provide clear guidance on whether this was allowed or if the voting rules should be changed in some fashion.

Discussion

A discussion thread was opened on Discourse to allow the Fedora community to provide its thoughts on the matter. Join SIG member Ankur Sinha weighed in to say that he was uncomfortable with how the discussion about the SIG's actions had been handled to date. The Join SIG gave voting rights to people for contributions, such as editing the Fedora wiki, "because large parts of Fedora contribution do not rely on FAS groups". He felt that it would be putting process over people to bar the Join SIG from granting temporary memberships for voting.

Fedora Project Leader Jef Spaleta asked what the process is for establishing an entity with a FAS group. Could he simply create a Fedora Curling SIG that would allow creating a FAS group with voting rights? He said that he had deep concerns about tying voting rights to arbitrary FAS groups:

How many SIGs right now are in fact just ghost fas groups and are effectively non-functional with no attachment points for onboarding new contributors?

If you want to tie voting strongly with SIGs, then we need to have SIGs being functional self-governing groups.. and not the laissez-faire structures as they exist right now.

Eduard Lucena responded that the process to create a SIG is lightweight, but creating a FAS group requires opening a ticket with Fedora's infrastructure and release engineering team. "So basically is at discretion of the infra team what FAS groups are created". Kevin Fenzi, Fedora's infrastructure lead, said that there had been much discussion in the council and Fedora's community operations group to try to figure out what makes someone a contributor. The council has a goal of increasing the number of contributors, so it seemed like a good thing to come up with a commonly agreed criteria—especially if it could be expressed in a way that Fedora's election software could use to determine eligibility.

Spaleta said he would go farther than that; it seemed to him that it was not just a good thing, but a necessary thing to have such a criteria. He suggested it might be possible to use Fedora's badge system, which provides a leaderboard system for tracking contributions to various parts of Fedora, as a proxy for eligibility. Fenzi and Spaleta traded a few ideas, but no concrete proposal has been formed.

"Too complex"

Fedora Council member Justin Wheeler reported that the topic had been "the centerpiece of a significant debate" during the council's meeting on January 14. He said that there was tension between being inclusive and the potential that an election could be gamed via temporary memberships:

We discussed the difficulty of defining "active contributors" and noted that "legacy" voting rights for inactive members are just as problematic as new temporary ones. The Council determined this topic is too complex to resolve in a single meeting and requires detailed asynchronous discussion here on Fedora Discussion rather than waiting for the 2026 Strategy Summit.

The summit that Wheeler referred to is taking place in Tirana, Albania starting on February 3 and running through February 5; the participants are primarily council members and leads of council initiatives.

It is not clear how many people were granted voting rights by the Join SIG, but there was no sign of a major influx of new voters for the Fedora F43 FESCo election cycle. In fact, there were fewer voters than the previous cycle. According to the results page a total of 214 voters participated. There were 231 voters for the Fedora 42 election, only 166 for the Fedora 41 cycle, and 236 for Fedora 40. A spot check of the results going back to June 2008, shows that FESCo elections tend to draw a range somewhere between about 150 and 300 voters.

To put that in perspective, the FAS group for Fedora packagers has more than 1,400 members. That group is worth noting for two reasons. One, there is actually a fairly high bar for joining the packager group. Secondly, because there is a process for removing people from the packager group if they have been inactive for 12 months. The Fedora infrastructure team removes inactive packagers each release cycle, unlike other FAS groups that might have members who have not been active for years. Not to mention FAS groups that are, themselves, no longer related to active SIGs or working groups within Fedora. One might conclude that, at the moment, the problem is not that a few people are sneaking into the ballot booth for Fedora elections; it's that too few Fedora participants bother to vote at all.

For now, the discussion continues. Nailing down the right criteria to define contributors with the right to vote, and having a fair system in place to ensure they are able to do so, will not be easy.

Comments (5 posted)

Filesystem medley: EROFS, NTFS, and XFS

Filesystems seem to be one of those many areas where the problems are well understood, but there is always somebody working toward a better solution. As a result, filesystem development in the Linux kernel continues at a fast pace even after all these years. In recent news, the EROFS filesystem is on the path to gain a useful page-cache-sharing feature, there is a new NTFS implementation on the horizon, and XFS may be about to get an infrastructure for self healing.

EROFS page-cache sharing

The Enhanced Read-Only Filesystem (EROFS) is, as its name would suggest, a filesystem for read-only data. EROFS supports an assortment of advanced filesystem features and provides high-performance data compression. It can be found in a number of settings, perhaps most notably on Android devices. EROFS was merged for the 5.4 kernel release in 2019 and has been steadily developed since then.

One common use case for EROFS is as a base layer for container images. As such, an EROFS filesystem can often be mounted many times on a given machine, and there can be multiple variants of a given filesystem with minor differences. Several images may contain different application mixes, but all have the same C library, for example. While EROFS will deduplicate data within a given filesystem at creation time, it cannot do that for independently created filesystems. Duplication of files across filesystems can result in multiple open files containing the same data in the system as a whole, wasting a lot of memory as that data is placed in the page cache. It would be nice to find a way to deduplicate that page-cache data and eliminate that memory waste.

In early 2025, Hongzhen Luo posted a patch series implementing page-cache sharing for EROFS. Later on, Hongbo Li picked up and continued that work; the most recent posting is version 18. It works by assigning a "fingerprint" to each file within a filesystem at creation time; that fingerprint is later used to detect files containing the same data.

Specifically, each file within an EROFS filesystem is given an extended attribute; the name of that attribute can be set by the creator, but trusted.erofs.fingerprint appears to be standard usage. The actual contents of the fingerprint are not defined. A logical value to use would be a cryptographic hash of the file's contents but, as Gao Xiang said, it could simply be an integer value assigned by the image creator. It should, of course, be different for two files if they have different content.

The fingerprint is used if the filesystem is mounted with the inode_share option. Another option, domain_id, is used to separate users; only files mounted within the same domain ID will be deduplicated. In the absence of this restriction, an attacker who is able to mount an EROFS filesystem could attach arbitrary fingerprints to files with malicious content, possibly causing other users to obtain that content rather than the files they were hoping for.

When a fingerprinted file is opened, the EROFS code creates an internal inode that references the data within that file. The file opened by user space is redirected (within the kernel) to that deduplication inode, which is associated with the fingerprint internally. Subsequent opens of files with the same fingerprint will simply take a reference to the deduplication inode, and read operations will be redirected to that inode's backing store. As a result, all of the files will share the same folios in the page cache, eliminating the duplicate memory usage.

In the current implementation, at least, use of fingerprints is incompatible with direct I/O.

Depending on the workloads running within a system, page-cache sharing can reduce memory usage by as much as nearly half in the best cases. So the attractiveness of the idea is not entirely surprising. The patch series has evolved considerably over time and a lot of review concerns have been addressed, but some still remain. Christoph Hellwig, for example, is concerned about the security implications of this feature, and will likely need some convincing before coming around. So, while 18 revisions is quite a few, there will likely be more yet before this feature is merged.

A new NTFS

NTFS is the standard Windows filesystem format. One would think that Linux, which has long offered interoperability with as many systems as possible, would have a good NTFS implementation, but that has never really come to pass. For years, the kernel was limited to read-only support for NTFS. Linux users wanting full access to NTFS filesystems had to make do with ntfs-3g, running under FUSE in user space.

That situation appeared to change with the arrival of ntfs3 in 2021. This implementation offered full NTFS access and appeared to be what the community was waiting for, despite worries expressed at the time that the level of support behind this system was less than might be desired. It was merged for the 5.15 release, and the read-only NTFS filesystem was removed from the kernel for the 6.9 release in 2024.

The worries about the maintenance of ntfs3 have, to an extent, been realized since its merging. The ntfs3 code, having been freshly merged in 5.15, would normally be expected to see a fair rate of change in subsequent releases as bugs are fixed and more features added. In this case, though, there were exactly four ntfs3 patches in 5.16, only one in 5.17, five in 5.18, and so on. The pace picked up somewhat around 6.0, but has dropped off more recently. There have been 67 commits to fs/ntfs3 in the last year. Many of those changes are not by its maintainer (Konstantin Komarov), but by other developers fixing up ntfs3 for changes elsewhere in the tree.

In October 2025, Namjae Jeon surfaced with an alternative NTFS implementation called "ntfsplus"; the filesystem has since just been rebranded "ntfs", matching the old, read-only implementation. The work, Jeon said, was motivated by the fact that "ntfs3 still has many problems and is poorly maintained"; ntfs is meant to be a better-maintained and more functional NTFS implementation. The fifth revision of this patch set was posted on January 11.

The series begins by reverting the removal of the read-only NTFS filesystem. This code, Jeon says, "is much cleaner, with extensive comments, offers readability that makes understanding NTFS easier", so it makes a better base for ongoing development than the ntfs3 code base. From there, the series adds the code needed to turn the filesystem into a proper, read/write implementation of NTFS. Toward the end, the series removes the compatibility code that ntfs3 uses to emulate the old, read-only implementation.

There are, Jeon says, a number of advantages to this version. It uses the iomap layer to interface with the memory-management and block subsystems; ntfs3, instead, still uses the older buffer-head interface. (It should be said that there is a patch from Komorov adding iomap support to ntfs3 currently sitting in linux-next). There is an associated project adding a filesystem checker. Jeon claims that this filesystem passes many more fstests tests than ntfs3. A set of benchmarks shows better performance than ntfs3, as much as 110% better for some workloads.

The patch set has evolved quickly over the short time it has existed on the lists, and a lot of review comments have been addressed. The new filesystem appears to be mostly feature-complete, with one notable exception: it does not yet support journaling. The ntfs3 implementation is able to play back an existing journal (though Jeon says that this feature "in our testing did not function correctly"). The next step, according to the cover letter, will be full journaling support.

The kernel community is normally unenthusiastic about multiple implementations of the same functionality, and would rather see incremental improvements than wholesale replacements; that places a sizable obstacle in Jeon's path. Even so, the new code appears to be winning over the filesystem developers; there are a lot of review comments, still, but they are aimed at improving the code rather than questioning its existence. To replace the NTFS implementation again would be a big step, but it appears to not be an inconceivable one.

XFS self healing

The XFS filesystem tends to be associated with big systems; it is designed to scale to massive files in great number, on systems with a lot of CPUs. The organizations that run this type of system also tend to be concerned about reliability and data integrity. A lot of work has been done on XFS in those areas in recent times; one piece of that is the XFS autonomous self-healing infrastructure from Darrick Wong.

The kernel-based infrastructure will not, on its own, heal a problematic filesystem. It is primarily a reporting mechanism giving a user-space daemon the ability to learn about problems; the decision on how to respond to any particular problem can then be made in user space. That daemon might respond by killing and restarting a container, initiating some sort of scrub operation, or trying to correct an error in some other way. Regardless, this is a complex operation with policy decisions that are best made outside the kernel.

The series adds a new ioctl() operation, XFS_IOC_HEALTH_MONITOR, which will return a file descriptor to a suitably privileged process. Whenever an event of note takes place, a structure will be written to that file descriptor for user space to read and react to. For the curious, this patch starts with a justification of the decision to output events as binary C structures rather than using some sort of higher-level protocol encoding.

There is a wide variety of events that can be reported, starting with an "unmount" event; it indicates that the filesystem is no longer mounted, and no further events will be produced. There is a set of events for reporting metadata corruption, distinguishing between "sick" metadata (with corruption noted at run time) and "corrupt" metadata (detected by the filesystem checker). Other events report media and I/O errors. The series also adds an ioctl() operation to check whether a given file descriptor refers to a file on the filesystem that is being monitored; it can give the user-space daemon confidence that it is, indeed, operating on the right filesystem.

On the user-space side, Wong has a repository that includes an xfs_healer program designed to use the new interface. For the curious (and troff-capable), there is a minimal man page describing this utility; we have created a rendered version of that page that some may find a little easier on the eyes.

The kernel series is in its sixth revision, and it would appear to be stabilizing. It may find its way into the mainline in the near future. It might take a bit longer, though, to develop the user-space code to the point that administrators will trust it to operate on a live, production filesystem.

Comments (65 posted)

Fedora and GPG 2.5

The GNU Privacy Guard (GPG) project decided to break from the OpenPGP standard for email encryption in 2023, and instead adopted its own homegrown LibrePGP specification. The GPG 2.4 branch, the last one to adhere to OpenPGP, will be reaching the end of life in mid-2026. The Fedora project is currently having a discussion about how that affects the distribution, its users, and what to offer once 2.4 is no longer receiving updates.

gpg.fail

The Fedora discussion was prompted by the gpg.fail disclosures in late December. Christian Stadelmann learned about the GPG flaws reported by the gpg.fail researchers and noticed that Fedora's gnupg2 package had not received any updates to fix those flaws. In fact, the package had not been updated since July 2025. He asked about this on the Fedora devel mailing list and pointed to a bug that lists all the 2.5.x updates that have not been packaged for Fedora. "Is it possible that gnupg is unmaintained? This would pose a high security risk to the Fedora project."

The package was not unmaintained. Red Hat, which employs the GPG package's maintainer Jakub Jelen, has an annual shutdown at the end of the year during the holidays. Like many other Red Hat employees, Jelen was taking some time off. In addition, he explained on January 2, he was keeping the package on GPG's "oldstable" 2.4 branch deliberately. That was why the package had not seen updates in several months—its upstream had not pushed out any new 2.4 releases.

The 2.5 branch was originally an experimental branch that implemented LibrePGP. Jelen noted that LibrePGP is not compatible with anything else and would likely result in users shooting themselves in the feet. "Updating to 2.5 would result in new users generating incompatible LibrePGP keys, which I do not think is a good idea to do now for all Fedora users." Since that is undesirable, he had been staying on 2.4 and syncing with the FreePG repository that contains a set of patches that is maintained for downstream projects, such as Debian and Fedora. The gnupg2 package for Fedora 43 includes a number of patches from FreePG, though it does not include the patch for LibrePGP format support.

Jelen said that he hoped to have a better solution by the time that GPG 2.4 reaches the end of its life, "but I can not anticipate what it is going to be". Meanwhile, he also noted that he was pushing out a package with the 2.4 fixes from the GPG project.

Michael Gruber pointed out that some of the fixes were available since October on the 2.4 branch (but not yet in a release). Jelen said that he was unaware of that, because he tracked the CVE database and there had not been CVEs issued. He said it made him question, again, whether Fedora should invest time and resources into an upstream that is not disclosing vulnerabilities clearly.

The communication around 2.5 has been somewhat muddy in general. Until recently, the 2.5.x series was understood to be a development branch and the next stable version of GPG would be 2.6. In June 2025, Koch said in the announcement for GPG 2.5.8 that the release was "another one in a series of public testing releases leading to a new stable version 2.6". The 2.5.9 release in July had similar language. Versions 2.5.10 and 2.5.11 did not have release announcements sent to the GPG announcement list. In September, Koch announced 2.5.12 and said that the 2.5 series is fully supported and ready for production use. He also sent out an announcement for GPG 2.4.8 several months after it was actually released in August 2025; that announcement noted that 2.4 would reach end of life in June 2026. The news that 2.4's end of life was approaching was not quite in the bottom of a locked filing cabinet in a disused lavatory, but it would not be surprising if a number of users and packagers missed the message all the same.

Alternatives

In the discussion that followed, Clemens Lang pointed out that Red Hat was standardizing on the Sequoia project, and that Red Hat Enterprise Linux (RHEL) 10 had dropped GPG's libgcrypt as a core cryptography library. "RHEL 10 already contains RPM signing keys that cannot be understood by GnuPG." Gruber said that he was all for replacing GPG with something better, but complained that Red Hat was choosing key types that would force Sequoia adoption. He did not, however, offer a preferred replacement for GPG.

Neal Gompa said that Red Hat was not trying to drive Sequoia adoption with incompatible key types; it had chosen post-quantum cryptography (PQC) algorithms, and GPG simply does not support PQC. Jelen agreed and said that Red Hat was not forcing Sequoia adoption, and that any implementation of the OpenPGP standard should do. "We just want to stay on the 'standard' side".

Sequoia developer Neal H. Walfield said that there were two ways to replace GPG with Sequoia: convince application developers to switch, and finish the work-in-progress drop-in replacement (dubbed "Chameleon") for GPG that uses Sequoia.

The chameleon has the advantage that instead of forcing an application to switch to Sequoia, we give the user the freedom to choose what implementation they prefer. The disadvantage of the chameleon is that it has to be compatible with gpg, which means that we can't change the interface or the workflows. Further, since gpg's interface is quite complex with lots of subtle interactions, writing a perfect drop-in replacement will take a long time. So far we've implemented the functionality that some specific applications use. That has worked pretty well and I'd estimate that we have >90% coverage. But a lot more work is needed to cover the long tail of commands and their many options.

Petr Menšík brought up the %{gpgverify} macro used for Fedora RPM packaging. Fedora's packaging guidelines specify that packagers must use %{gpgverify} to perform verification of a source file's signature at the start of the build process for an RPM. Currently, that macro expands to an invocation of the gpgv signature tool. Gruber responded that the guidelines did not require that the macro call gpgv specifically, though; it could be changed to use Sequoia's sqv instead.

So far, no decision has been reached, though it would seem that the consensus is largely in favor of replacing GPG with Sequoia in instances where Fedora tooling requires signing and verification of OpenPGP signatures.

What to provide to users is still on the table. Arch Linux, Debian, Ubuntu, and other major distributions are still providing 2.4.x versions of GPG. Fedora tries to avoid deviating from upstream most of the time, but providing a version of GPG that does not implement the OpenPGP standard may not serve users well. The clock is ticking; the Fedora 44 release that is expected in April will likely ship with GPG 2.4.9, but a decision for Fedora 45 will need to be reached soon.

Comments (22 posted)

Implicit arguments for BPF kfuncs

The kernel's "kfunc" mechanism is a way of exporting kernel functions so that they can be called directly from BPF programs. There are over 300 kfuncs in current kernels, ranging in functionality from string processing (bpf_strnlen()) to custom schedulers (scx_bpf_kick_cpu()) and beyond. Sometimes these kfuncs need access to context information that is not directly available to BPF programs, and which thus cannot be passed in as arguments. The implicit arguments patch set from Ihor Solodrai is the latest attempt to solve this problem.

The BPF subsystem maintains a collection of context information in the massive bpf_prog_aux structure. Over the years it has grown to contain just about any sort of information that may be needed, including a list of maps the program is using, how long since it was loaded, the current stack depth, and dozens of other fields. It can almost be thought of as an analog to the self object passed to methods in some object-oriented languages. A number of kfuncs need to make use of this structure, but it is not something that BPF programs themselves can access.

The way this problem has been handled in the BPF subsystem so far — the __prog annotation — cannot be said to be overly elegant. Consider bpf_stream_vprintk(), which is defined as a macro:

    #define bpf_stream_printk(stream_id, fmt, args...)		\
    ({								\
	static const char ___fmt[] = fmt;			\
	unsigned long long ___param[___bpf_narg(args)];		\
								\
	___bpf_fill(___param, args);				\
	bpf_stream_vprintk_impl(stream_id, ___fmt, ___param,	\
		sizeof(___param), NULL);			\
    })

This macro marshals together the passed-in args and, in turn, calls bpf_stream_vprintk_impl, defined as:

    __bpf_kfunc int bpf_stream_vprintk_impl(int stream_id, const char *fmt__str, 
    					    const void *args, u32 len__sz,
					    void *aux__prog);

The BPF verifier sees the trailing __prog in the name of the final parameter and magically replaces whatever was passed (the NULL in the macro above) with a pointer to the bpf_prog_aux structure. It gets the job done, but what is going on here is not exactly obvious to the casual observer.

Solodrai first attempted to generalize this mechanism in late 2025 with a "magic function" abstraction. In this implementation, the __prog suffix was switched to __magic, and the in-kernel version of the API (the one with the __impl suffix) was generated automatically. The concept was well received, but there were a lot of comments on the implementation; as a result, the patches have evolved somewhat since then.

As the work stands now, a kfunc needing implicit arguments is declared normally, as it is expected to be invoked within the kernel. So, with the patch set applied, bpf_stream_vprintk() is declared as:

    __bpf_kfunc int bpf_stream_vprintk(int stream_id, const char *fmt__str, 
				       const void *args, u32 len__sz,
				       struct bpf_prog_aux *aux);

The pointer to the bpf_prog_aux structure is now without any magic adornments. Instead, when it comes time to inform the BPF subsystem about this kfunc, the declaration looks like:

    BTF_ID_FLAGS(func, bpf_stream_vprintk, KF_IMPLICIT_ARGS)

The KF_IMPLICIT_ARGS flag indicates that this function has an implicit argument that is not visible to BPF programs.

When the kernel loads a BPF program containing a call to one or more kfuncs, the verifier looks up those kfuncs in the BPF type format (BTF) data created when the kernel is built. That data describes the kfunc and lets the verifier ensure that the BPF program is calling it correctly. The patch series causes the kernel-build process to modify the generated BTF for KF_IMPLICIT_ARGS kfuncs in a couple of ways:

• An entry for a new function, using the name of the kfunc with _impl appended, is added to the BTF data. This entry has the prototype for the kfunc as declared, and links to that function within the kernel.
• The entry for the kfunc using the original name (without "__impl") is modified so that the last argument is omitted. That is the BTF data that is used to match kfuncs for BPF programs.

Whenever a call to a kfunc with implicit arguments is processed by the verifier, it modifies the call to add the bpf_prog_aux structure pointer as the final argument, essentially mapping the second form of the call above onto the first. So, in the end, the BPF program can access the kfunc with the expected API, with no need for wrapper macros to hide the work being done behind the scenes, and the kernel function can be declared under the name by which it will actually be used.

KF_IMPLICIT_ARGS is plural, implying that there could be more than one argument but, for the time being, the only thing that works is a struct bpf_prog_aux pointer as the final argument. Should that eventually prove to be insufficient, Solodrai said, "it is simple to extend this to more types". Given the apparent practice of shoving everything that might be needed into struct bpf_prog_aux, though, there may never be a need for anything else.

In the end, one could argue that the bpf_prog_aux pointer should have been implicitly passed to all kfuncs from the beginning. As it stands, this feature will make it easily and transparently available to the kfuncs that truly need it. There are already other patches (such as the sched_ext sub-scheduler series) that depend on this feature, so it seems likely to land in the mainline in the relatively near future.

Comments (none posted)

Stenberg: The end of the curl bug-bounty program

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

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

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

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

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

Comments (32 posted)

A critical GnuPG security update

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

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

Only versions 2.5.13 through 2.5.16 are affected.

Full Story (comments: 22)

Security quotes of the week

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

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

— Matthew Garrett

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

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

— Bruce Schneier and Nathan E. Sanders

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

— a letter signed by 21 computer scientists expert in election security

Comments (none posted)

Kernel release status

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

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

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

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

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

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

Comments (none posted)

PC Gamer on the scx_horoscope scheduler

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

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

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

Comments (22 posted)

GNU Guix 1.5.0 released

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

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

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

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

LWN last looked at Guix in February 2024.

Comments (1 posted)

30 years of ReactOS

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

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

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

Comments (16 posted)

Distributions quote of the week

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

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

— Jef Spaleta

Comments (none posted)

The GNU C Library is moving from Sourceware

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

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

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

Comments (none posted)

GNU C Library 2.43 released

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

Comments (50 posted)

Rust 1.93.0 released

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

Comments (none posted)

Xfwl4: the roadmap for a Xfce Wayland compositor

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

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

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

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

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

Comments (53 posted)

Development quote of the week

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

— Lars Wirzenius

Comments (none posted)

OSI pauses 2026 board election cycle

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

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

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

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

LWN covered the previous OSI election in March 2025.

Comments (12 posted)

Mourning Didier Spaier

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

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

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

He will be irreplaceable.

Comments (3 posted)

CFP Deadlines: January 29, 2026 to March 30, 2026

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

Deadline	Event Dates	Event	Location
January 31	April 10 April 11	Grazer Linuxtage	Graz, Austria
February 7	April 20 April 21	SambaXP	Göttingen, Germany
February 9	May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
February 14	April 23	OpenSUSE Open Developers Summit	Prague, Czech Republic
February 15	July 13 July 19	EuroPython	Kraków, Poland
February 15	April 27 April 28	foss-north	Gothenburg, Sweden
March 10	May 2	22nd Linux Infotag Augsburg	Augsburg, Germany
March 15	May 21 May 22	Linux Security Summit North America	Minneapolis, Minnesota, US

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

Events: January 29, 2026 to March 30, 2026

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

Date(s)	Event	Location
January 29 January 30	CentOS Connect	Brussels, Belgium
January 31 February 1	Free and Open source Software Developers' European Meeting	Brussels, Belgium
February 2	OpenEmbedded Workshop 2026	Brussels, Belgium
February 2 February 4	Config Management Camp	Ghent, Belgium
February 17	AlpOSS 2026	Échirolles, France
February 24 February 25	Linux Foundation Member Summit	Napa, CA, US
March 5 March 8	SCALE	Pasadena, CA, US
March 9 March 10	FOSSASIA Summit	Bangkok, Thailand
March 16 March 17	FOSS Backstage	Berlin, Germany
March 19	Open Tech Day 26: OpenTofu Edition	Nuremberg, Germany
March 23 March 26	KubeCon + CloudNativeCon Europe	Amsterdam, Netherlands
March 28	Central Pennsylvania Open Source Conference	Lancaster, Pennsylvania, US
March 28 March 29	Chemnitz Linux Days	Chemnitz, Germany

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

Alert summary January 22, 2026 to January 28, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:0914	9	gimp	2026-01-26
AlmaLinux	ALSA-2026:0975	10	glib2	2026-01-24
AlmaLinux	ALSA-2026:0991	8	glib2	2026-01-24
AlmaLinux	ALSA-2026:0936	9	glib2	2026-01-24
AlmaLinux	ALSA-2026:0921	8	go-toolset:rhel8	2026-01-26
AlmaLinux	ALSA-2026:0922	10	golang	2026-01-24
AlmaLinux	ALSA-2026:0923	9	golang	2026-01-24
AlmaLinux	ALSA-2026:0770	10	gpsd	2026-01-21
AlmaLinux	ALSA-2026:0932	8	java-1.8.0-openjdk	2026-01-28
AlmaLinux	ALSA-2026:0927	8	java-17-openjdk	2026-01-24
AlmaLinux	ALSA-2026:0927	9	java-17-openjdk	2026-01-24
AlmaLinux	ALSA-2026:0928	10	java-21-openjdk	2026-01-24
AlmaLinux	ALSA-2026:0928	8	java-21-openjdk	2026-01-26
AlmaLinux	ALSA-2026:0928	9	java-21-openjdk	2026-01-24
AlmaLinux	ALSA-2026:0786	10	kernel	2026-01-23
AlmaLinux	ALSA-2026:1142	8	kernel	2026-01-26
AlmaLinux	ALSA-2026:0793	9	kernel	2026-01-24
AlmaLinux	ALSA-2026:1148	8	kernel-rt	2026-01-26
AlmaLinux	ALSA-2026:0696	9	net-snmp	2026-01-26
AlmaLinux	ALSA-2026:0930	8	pcs	2026-01-24
AlmaLinux	ALSA-2026:1086	10	python-urllib3	2026-01-26
AlmaLinux	ALSA-2026:1087	9	python-urllib3	2026-01-27
AlmaLinux	ALSA-2026:1224	8	python3.11-urllib3	2026-01-27
AlmaLinux	ALSA-2026:1089	9	python3.11-urllib3	2026-01-27
AlmaLinux	ALSA-2026:1226	8	python3.12-urllib3	2026-01-27
AlmaLinux	ALSA-2026:1088	9	python3.12-urllib3	2026-01-27
AlmaLinux	ALSA-2026:0924	9	thunderbird	2026-01-24
Debian	DLA-4452-1	LTS	apache2	2026-01-24
Debian	DSA-6107-1	stable	bind9	2026-01-22
Debian	DSA-6108-1	stable	chromium	2026-01-22
Debian	DLA-4448-1	LTS	imagemagick	2026-01-24
Debian	DSA-6111-1	stable	imagemagick	2026-01-26
Debian	DSA-6109-1	stable	incus	2026-01-23
Debian	DLA-4453-1	LTS	inetutils	2026-01-25
Debian	DSA-6106-1	stable	inetutils	2026-01-22
Debian	DLA-4454-1	LTS	libuev	2026-01-25
Debian	DSA-6105-1	stable	modsecurity-crs	2026-01-21
Debian	DLA-4457-1	LTS	openjdk-11	2026-01-26
Debian	DLA-4456-1	LTS	openjdk-17	2026-01-26
Debian	DSA-6110-1	stable	openjdk-17	2026-01-25
Debian	DSA-6112-1	stable	openjdk-21	2026-01-27
Debian	DSA-6113-1	stable	openssl	2026-01-27
Debian	DLA-4426-2	LTS	osslsigncode	2026-01-23
Debian	DLA-4447-1	LTS	php7.4	2026-01-24
Debian	DLA-4446-1	LTS	python-urllib3	2026-01-23
Debian	DSA-6102-2	stable	python-urllib3	2026-01-22
Debian	DLA-4455-1	LTS	python3.9	2026-01-25
Debian	DLA-4451-1	LTS	shapelib	2026-01-24
Debian	DLA-4450-1	LTS	taglib	2026-01-24
Debian	DLA-4449-1	LTS	zvbi	2026-01-24
Fedora	FEDORA-2026-7069f6c1c8	F42	assimp	2026-01-28
Fedora	FEDORA-2026-567ff6c687	F43	bind	2026-01-27
Fedora	FEDORA-2026-567ff6c687	F43	bind-dyndb-ldap	2026-01-27
Fedora	FEDORA-2026-78ff346bb0	F42	chromium	2026-01-28
Fedora	FEDORA-2026-b4b553ec05	F43	chromium	2026-01-27
Fedora	FEDORA-2026-3b0e5b457d	F42	cpp-httplib	2026-01-22
Fedora	FEDORA-2026-e50e41fcea	F43	cpp-httplib	2026-01-22
Fedora	FEDORA-2026-3f0f0f85be	F42	curl	2026-01-28
Fedora	FEDORA-2026-e27b23af78	F43	curl	2026-01-22
Fedora	FEDORA-2026-943caf40d9	F42	freerdp	2026-01-28
Fedora	FEDORA-2026-23d669bf94	F43	freerdp	2026-01-23
Fedora	FEDORA-2026-d7cbd53e55	F42	ghostscript	2026-01-27
Fedora	FEDORA-2026-c60e345359	F43	ghostscript	2026-01-23
Fedora	FEDORA-2026-ebabb127fb	F43	gimp	2026-01-28
Fedora	FEDORA-2026-a2f3af8a86	F42	glibc	2026-01-27
Fedora	FEDORA-2026-205d532069	F43	glibc	2026-01-27
Fedora	FEDORA-2026-bac983cf83	F42	harfbuzz	2026-01-28
Fedora	FEDORA-2026-9af71a53ce	F42	hcloud	2026-01-23
Fedora	FEDORA-2026-f677c523ec	F42	mariadb11.8	2026-01-22
Fedora	FEDORA-2026-297c251448	F43	mariadb11.8	2026-01-22
Fedora	FEDORA-2026-0955012bb5	F42	mingw-glib2	2026-01-26
Fedora	FEDORA-2026-46fe567fd3	F43	mingw-glib2	2026-01-27
Fedora	FEDORA-2026-2301995d0a	F42	mingw-harfbuzz	2026-01-26
Fedora	FEDORA-2026-dc77eb63ae	F43	mingw-harfbuzz	2026-01-27
Fedora	FEDORA-2026-c3c95cc5f9	F42	mingw-libsoup	2026-01-26
Fedora	FEDORA-2026-20b533bbc7	F43	mingw-libsoup	2026-01-27
Fedora	FEDORA-2026-4ed69f3065	F42	mingw-libtasn1	2026-01-22
Fedora	FEDORA-2026-0dfbd2a5e2	F43	mingw-libtasn1	2026-01-22
Fedora	FEDORA-2026-00347cea5e	F42	mingw-libxslt	2026-01-22
Fedora	FEDORA-2026-84be018d47	F43	mingw-libxslt	2026-01-22
Fedora	FEDORA-2026-0e8fe3c8a3	F42	mingw-openexr	2026-01-26
Fedora	FEDORA-2026-1fbf91067c	F43	mingw-openexr	2026-01-27
Fedora	FEDORA-2026-01a62f2cfd	F42	mingw-python3	2026-01-22
Fedora	FEDORA-2026-009cb3c02a	F43	mingw-python3	2026-01-22
Fedora	FEDORA-2026-e55e601165	F42	pgadmin4	2026-01-25
Fedora	FEDORA-2026-0e6d3fbdcb	F43	pgadmin4	2026-01-25
Fedora	FEDORA-2026-9860efdad7	F42	python3.11	2026-01-25
Fedora	FEDORA-2026-36e1e6958c	F43	python3.11	2026-01-25
Fedora	FEDORA-2026-f8f1b315d0	F42	python3.12	2026-01-25
Fedora	FEDORA-2026-06aa85da91	F43	python3.12	2026-01-25
Fedora	FEDORA-2026-43e2b1e209	F42	python3.9	2026-01-24
Fedora	FEDORA-2026-975a15098b	F43	python3.9	2026-01-24
Fedora	FEDORA-2026-00a6b7589c	F43	qownnotes	2026-01-27
Fedora	FEDORA-2026-b4a6ca0bd0	F42	rclone	2026-01-23
Fedora	FEDORA-2026-3de3ece93a	F43	rclone	2026-01-22
Fedora	FEDORA-2026-d2431d8ac0	F42	rpki-client	2026-01-22
Fedora	FEDORA-2026-0d27571013	F43	rpki-client	2026-01-22
Fedora	FEDORA-2026-801214adba	F42	rust-rkyv0.7	2026-01-23
Fedora	FEDORA-2026-35d1dee2ab	F43	rust-rkyv0.7	2026-01-23
Fedora	FEDORA-2026-801214adba	F42	rust-rkyv_derive0.7	2026-01-23
Fedora	FEDORA-2026-35d1dee2ab	F43	rust-rkyv_derive0.7	2026-01-23
Fedora	FEDORA-2026-f6fadfed32	F42	vsftpd	2026-01-23
Fedora	FEDORA-2026-67442bdd84	F43	vsftpd	2026-01-23
Fedora	FEDORA-2026-eea5babc00	F42	wireshark	2026-01-25
Fedora	FEDORA-2026-3d29b96a25	F43	wireshark	2026-01-25
Gentoo	202601-04		Asterisk	2026-01-26
Gentoo	202601-05		Commons-BeanUtils	2026-01-26
Gentoo	202601-03		GIMP	2026-01-26
Gentoo	202601-02		Vim, gVim	2026-01-26
Gentoo	202601-01		inetutils	2026-01-26
Mageia	MGASA-2026-0016	9	avahi	2026-01-23
Mageia	MGASA-2026-0022	9	glibc	2026-01-27
Mageia	MGASA-2026-0019	9	haproxy	2026-01-27
Mageia	MGASA-2026-0015	9	harfbuzz	2026-01-23
Mageia	MGASA-2026-0021	9	iperf	2026-01-27
Mageia	MGASA-2026-0017	9	kernel	2026-01-24
Mageia	MGASA-2026-0018	9	kernel-linus	2026-01-26
Mageia	MGASA-2026-0020	9	python-pyasn1	2026-01-27
Oracle	ELSA-2026-0914	OL9	gimp	2026-01-22
Oracle	ELSA-2026-0975	OL10	glib2	2026-01-23
Oracle	ELSA-2026-0991	OL8	glib2	2026-01-23
Oracle	ELSA-2026-0936	OL9	glib2	2026-01-22
Oracle	ELSA-2026-0921	OL8	go-toolset:rhel8	2026-01-22
Oracle	ELSA-2026-0922	OL10	golang	2026-01-22
Oracle	ELSA-2026-0923	OL9	golang	2026-01-22
Oracle	ELSA-2026-0927	OL8	java-17-openjdk	2026-01-23
Oracle	ELSA-2026-0927	OL9	java-17-openjdk	2026-01-23
Oracle	ELSA-2026-0928	OL10	java-21-openjdk	2026-01-23
Oracle	ELSA-2026-0928	OL9	java-21-openjdk	2026-01-23
Oracle	ELSA-2026-0759	OL8	kernel	2026-01-22
Oracle	ELSA-2026-0793	OL9	kernel	2026-01-22
Oracle	ELSA-2026-0251	OL7	libpng	2026-01-23
Oracle	ELSA-2026-0698	OL8	mariadb-devel:10.3	2026-01-22
Oracle	ELSA-2026-0924	OL9	thunderbird	2026-01-22
Red Hat	RHSA-2026:0426-01	EL9.4	buildah	2026-01-22
Red Hat	RHSA-2026:0921-01	EL8	go-toolset:rhel8	2026-01-22
Red Hat	RHSA-2026:0923-01	EL9	golang	2026-01-22
Red Hat	RHSA-2026:0244-01	EL8.2	grafana	2026-01-22
Red Hat	RHSA-2026:0243-01	EL8.4	grafana	2026-01-22
Red Hat	RHSA-2026:0246-01	EL8.6	grafana	2026-01-22
Red Hat	RHSA-2026:0245-01	EL8.8	grafana	2026-01-22
Red Hat	RHSA-2026:1377-01	EL9	image-builder	2026-01-28
Red Hat	RHSA-2026:0927-01	EL9.0	java-17-openjdk	2026-01-26
Red Hat	RHSA-2026:0928-01	EL8	java-21-openjdk	2026-01-26
Red Hat	RHSA-2026:0453-01	EL10	kernel	2026-01-26
Red Hat	RHSA-2026:0755-01	EL7	kernel	2026-01-22
Red Hat	RHSA-2026:1142-01	EL8	kernel	2026-01-26
Red Hat	RHSA-2026:0793-01	EL9	kernel	2026-01-26
Red Hat	RHSA-2026:0917-01	EL9.4	kernel	2026-01-26
Red Hat	RHSA-2026:0804-01	EL9.6	kernel	2026-01-26
Red Hat	RHSA-2026:0754-01	EL7	kernel-rt	2026-01-22
Red Hat	RHSA-2026:1148-01	EL8	kernel-rt	2026-01-26
Red Hat	RHSA-2026:0794-01	EL9.2	multiple packages	2026-01-22
Red Hat	RHSA-2025:22794-01	EL10.0	openssl	2026-01-22
Red Hat	RHSA-2026:0337-01	EL8	openssl	2026-01-22
Red Hat	RHSA-2026:0887-01	EL8.2	openssl	2026-01-22
Red Hat	RHSA-2026:0714-01	EL8.6	openssl	2026-01-22
Red Hat	RHSA-2026:0602-01	EL8.8	openssl	2026-01-22
Red Hat	RHSA-2026:1473-01	EL9	openssl	2026-01-28
Red Hat	RHSA-2026:1378-01	EL10.0	osbuild-composer	2026-01-28
Red Hat	RHSA-2026:1380-01	EL8	osbuild-composer	2026-01-28
Red Hat	RHSA-2026:0987-01	EL8.4	osbuild-composer	2026-01-27
Red Hat	RHSA-2026:1025-01	EL8.6	osbuild-composer	2026-01-27
Red Hat	RHSA-2026:0973-01	EL8.8	osbuild-composer	2026-01-22
Red Hat	RHSA-2026:1381-01	EL9	osbuild-composer	2026-01-28
Red Hat	RHSA-2026:0314-01	EL9.2	osbuild-composer	2026-01-22
Red Hat	RHSA-2026:1379-01	EL9.6	osbuild-composer	2026-01-28
Red Hat	RHSA-2026:0424-01	EL9.4	podman	2026-01-22
Red Hat	RHSA-2026:0477-01	EL9.4	skopeo	2026-01-22
Slackware	SSA:2026-021-01		bind	2026-01-21
Slackware	SSA:2026-027-01		mozilla	2026-01-27
SUSE	openSUSE-SU-2026:10073-1	TW	alloy	2026-01-22
SUSE	SUSE-SU-2026:0259-1	SLE15 oS15.6	avahi	2026-01-23
SUSE	openSUSE-SU-2026:20110-1	oS16.0	avahi	2026-01-27
SUSE	SUSE-SU-2026:0273-1	SLE12	azure-cli-core	2026-01-23
SUSE	openSUSE-SU-2026:10080-1	TW	bind	2026-01-23
SUSE	openSUSE-SU-2026:20080-1	oS16.0	buildah	2026-01-25
SUSE	SUSE-SU-2026:0235-1	SLE15	busybox	2026-01-22
SUSE	SUSE-SU-2026:0236-1	SLE15 oS15.5 oS15.6	busybox	2026-01-22
SUSE	SUSE-SU-2026:20096-1	SLE16	cargo-c	2026-01-23
SUSE	openSUSE-SU-2026:20103-1	oS16.0	chromium	2026-01-25
SUSE	openSUSE-SU-2026:0028-1	osB15	chromium	2026-01-23
SUSE	openSUSE-SU-2026:0027-1	osB15	chromium	2026-01-23
SUSE	openSUSE-SU-2026:20099-1	oS16.0	coredns	2026-01-25
SUSE	openSUSE-SU-2026:10074-1	TW	corepack22	2026-01-22
SUSE	openSUSE-SU-2026:10075-1	TW	corepack24	2026-01-22
SUSE	openSUSE-SU-2026:10088-1	TW	cups	2026-01-27
SUSE	SUSE-SU-2026:20110-1	SLE-m6.2	curl	2026-01-23
SUSE	SUSE-SU-2026:0221-1	SLE15	curl	2026-01-22
SUSE	SUSE-SU-2026:20112-1	SLE-m6.2	docker	2026-01-23
SUSE	SUSE-SU-2026:20095-1	SLE16	docker	2026-01-23
SUSE	SUSE-SU-2026:0238-1	SLE15	dpdk	2026-01-22
SUSE	SUSE-SU-2026:0231-1	SLE15 oS15.4 oS15.6	exiv2-0_26	2026-01-22
SUSE	SUSE-SU-2026:0229-1	SLE15 oS15.4	ffmpeg-4	2026-01-22
SUSE	SUSE-SU-2026:0198-1	SLE15 oS15.6	ffmpeg-4	2026-01-21
SUSE	SUSE-SU-2026:0260-1	SLE15 oS15.6	firefox	2026-01-23
SUSE	openSUSE-SU-2026:10089-1	TW	gio-branding-upstream	2026-01-27
SUSE	SUSE-SU-2026:0264-1	SLE-m5.2	glib2	2026-01-23
SUSE	SUSE-SU-2026:0266-1	SLE12	glib2	2026-01-23
SUSE	SUSE-SU-2026:0286-1	SLE15 oS15.6	glib2	2026-01-26
SUSE	SUSE-SU-2026:0219-1	SLE15 oS15.6	go1.24	2026-01-22
SUSE	SUSE-SU-2026:0296-1	SLE15	go1.24-openssl	2026-01-26
SUSE	SUSE-SU-2026:0218-1	SLE15 oS15.6	go1.25	2026-01-22
SUSE	SUSE-SU-2026:0297-1	SLE15	go1.25-openssl	2026-01-27
SUSE	SUSE-SU-2026:0298-1	SLE15 oS15.6	go1.25-openssl	2026-01-27
SUSE	openSUSE-SU-2026:10090-1	TW	google-osconfig-agent	2026-01-27
SUSE	SUSE-SU-2026:0292-1	oS15.6	govulncheck-vulndb	2026-01-26
SUSE	SUSE-SU-2026:20108-1	SLE-m6.2	gpg2	2026-01-23
SUSE	SUSE-SU-2026:0214-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	gpg2	2026-01-22
SUSE	SUSE-SU-2026:0215-1	SLE15 oS15.6	gpg2	2026-01-22
SUSE	SUSE-SU-2026:20109-1	SLE-m6.2	haproxy	2026-01-23
SUSE	SUSE-SU-2026:0287-1	SLE15 oS15.6	harfbuzz	2026-01-26
SUSE	openSUSE-SU-2026:10091-1	TW	java-11-openjdk	2026-01-27
SUSE	openSUSE-SU-2026:10092-1	TW	java-17-openjdk	2026-01-27
SUSE	openSUSE-SU-2026:10093-1	TW	java-21-openjdk	2026-01-27
SUSE	SUSE-SU-2026:0281-1	SLE15	kernel	2026-01-26
SUSE	SUSE-SU-2026:0278-1	SLE15	kernel	2026-01-23
SUSE	SUSE-SU-2026:0263-1	SLE15 SLE-m5.5 oS15.5	kernel	2026-01-23
SUSE	SUSE-SU-2026:0293-1	SLE15 oS15.6	kernel	2026-01-26
SUSE	SUSE-SU-2026:0267-1	SLE12	kernel-firmware	2026-01-23
SUSE	SUSE-SU-2026:0216-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	kernel-firmware	2026-01-22
SUSE	SUSE-SU-2026:0305-1	SLE15 SLE-m5.5 oS15.5	kernel-firmware	2026-01-28
SUSE	SUSE-SU-2026:0217-1	SLE15 oS15.4 oS15.6	keylime	2026-01-22
SUSE	openSUSE-SU-2026:20076-1	oS16.0	libheif	2026-01-25
SUSE	openSUSE-SU-2026:10094-1	TW	libmatio-devel	2026-01-27
SUSE	openSUSE-SU-2026:10095-1	TW	libopenjp2-7	2026-01-27
SUSE	SUSE-SU-2026:0234-1	SLE15 oS15.6	libpng16	2026-01-22
SUSE	SUSE-SU-2026:0243-1	SLE15 oS15.6	librsvg	2026-01-22
SUSE	SUSE-SU-2026:0194-1	SLE12	libsodium	2026-01-21
SUSE	SUSE-SU-2026:0223-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	libsodium	2026-01-22
SUSE	SUSE-SU-2026:0265-1	SLE12	libsoup	2026-01-23
SUSE	SUSE-SU-2026:0211-1	SLE15 oS15.4	libsoup	2026-01-22
SUSE	SUSE-SU-2026:0257-1	SLE15 oS15.6	libsoup	2026-01-23
SUSE	SUSE-SU-2026:0258-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	libsoup2	2026-01-23
SUSE	SUSE-SU-2026:0253-1	SLE15 oS15.6	libsoup2	2026-01-23
SUSE	SUSE-SU-2026:0224-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	libtasn1	2026-01-22
SUSE	SUSE-SU-2026:0193-1	SLE12	libvirt	2026-01-21
SUSE	SUSE-SU-2026:0279-1	SLE15	libvirt	2026-01-23
SUSE	SUSE-SU-2026:0254-1	SLE15 oS15.6	log4j	2026-01-23
SUSE	SUSE-SU-2026:0195-1	SLE12	net-snmp	2026-01-21
SUSE	SUSE-SU-2026:0225-1	SLE15 SLE-m5.3	net-snmp	2026-01-22
SUSE	SUSE-SU-2026:0227-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	net-snmp	2026-01-22
SUSE	SUSE-SU-2026:0228-1	SLE15 oS15.6	net-snmp	2026-01-22
SUSE	SUSE-SU-2026:0301-1	SLE15	nodejs22	2026-01-27
SUSE	SUSE-SU-2026:0295-1	SLE15 oS15.6	nodejs22	2026-01-26
SUSE	SUSE-SU-2026:20114-1	SLE-m6.2	open-vm-tools	2026-01-23
SUSE	SUSE-SU-2026:20100-1	SLE16	open-vm-tools	2026-01-23
SUSE	openSUSE-SU-2026:20067-1	oS16.0	open-vm-tools	2026-01-21
SUSE	SUSE-SU-2026:0291-1	SLE15	openCryptoki	2026-01-26
SUSE	openSUSE-SU-2026:10086-1	TW	openCryptoki	2026-01-24
SUSE	SUSE-SU-2026:0256-1	SLE15 oS15.5 oS15.6	openldap2_5	2026-01-23
SUSE	SUSE-SU-2026:0280-1	SLE15 oS15.6	openvswitch	2026-01-23
SUSE	SUSE-SU-2026:0290-1	SLE15 SLE-m5.5 oS15.5 oS15.6	openvswitch3	2026-01-26
SUSE	SUSE-SU-2026:0196-1	SLE12	ovmf	2026-01-21
SUSE	SUSE-SU-2026:0212-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	ovmf	2026-01-22
SUSE	SUSE-SU-2026:0213-1	SLE15 SLE-m5.5 oS15.5	ovmf	2026-01-22
SUSE	SUSE-SU-2026:0232-1	SLE15 oS15.3	pgadmin4	2026-01-22
SUSE	SUSE-SU-2026:0245-1	SLE15 oS15.4 oS15.6	php7	2026-01-22
SUSE	openSUSE-SU-2026:20113-1	oS16.0	php8	2026-01-27
SUSE	SUSE-SU-2026:20116-1	SLE-m6.2	podman	2026-01-23
SUSE	SUSE-SU-2026:20103-1	SLE16	podman	2026-01-23
SUSE	openSUSE-SU-2026:20072-1	oS16.0	podman	2026-01-25
SUSE	SUSE-SU-2026:0197-1	SLE12	postgresql17, postgresql18	2026-01-21
SUSE	SUSE-SU-2026:0199-1	SLE15 oS15.6	python-FontTools	2026-01-21
SUSE	SUSE-SU-2026:0268-1	SLE15 oS15.6	python	2026-01-23
SUSE	SUSE-SU-2026:0220-1	SLE15 oS15.4 oS15.6	python-filelock	2026-01-22
SUSE	SUSE-SU-2026:0226-1	MP4.3 SLE15 oS15.4 oS15.6	python-marshmallow	2026-01-22
SUSE	SUSE-SU-2026:0252-1	MP4.3 SLE15 oS15.4 oS15.6	python-pyasn1	2026-01-23
SUSE	SUSE-SU-2026:0300-1	SLE12	python-pyasn1	2026-01-27
SUSE	SUSE-SU-2026:0307-1	oS15.6	python-python-multipart	2026-01-28
SUSE	SUSE-SU-2026:0222-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-tornado	2026-01-22
SUSE	SUSE-SU-2026:0255-1	MP4.3 SLE15 oS15.4 oS15.6	python-urllib3	2026-01-23
SUSE	openSUSE-SU-2026:20088-1	oS16.0	python-urllib3	2026-01-25
SUSE	SUSE-SU-2026:0233-1	SLE15 oS15.4 oS15.6	python-virtualenv	2026-01-22
SUSE	openSUSE-SU-2026:20069-1	oS16.0	python-weasyprint	2026-01-21
SUSE	SUSE-SU-2026:0210-1	SLE12	python3	2026-01-22
SUSE	SUSE-SU-2026:0299-1	MP4.3 SLE15 oS15.4	python311	2026-01-27
SUSE	openSUSE-SU-2026:10078-1	TW	python311-pyasn1	2026-01-22
SUSE	openSUSE-SU-2026:10096-1	TW	python311-urllib3_1	2026-01-27
SUSE	openSUSE-SU-2026:10079-1	TW	python311-weasyprint	2026-01-22
SUSE	SUSE-SU-2026:0288-1	SLE15	qemu	2026-01-26
SUSE	openSUSE-SU-2026:10097-1	TW	qemu	2026-01-27
SUSE	openSUSE-SU-2026:20082-1	oS16.0	rabbitmq-server	2026-01-25
SUSE	SUSE-SU-2026:20099-1	SLE16	rust1.91, rust1.92	2026-01-23
SUSE	SUSE-SU-2026:0230-1	SLE15	util-linux	2026-01-22
SUSE	openSUSE-SU-2026:10083-1	TW	vlang	2026-01-23
SUSE	SUSE-SU-2026:20102-1	SLE16	webkit2gtk3	2026-01-23
SUSE	openSUSE-SU-2026:20065-1	oS16.0	webkit2gtk3	2026-01-21
SUSE	SUSE-SU-2026:0237-1	SLE15 oS15.6	wireshark	2026-01-22
SUSE	SUSE-SU-2026:0303-1	SLE-m5.2 oS15.3	xen	2026-01-28
SUSE	SUSE-SU-2026:0304-1	SLE-m5.5 oS15.5	xen	2026-01-28
SUSE	SUSE-SU-2026:0306-1	oS15.6	xen	2026-01-28
Ubuntu	USN-7973-1	20.04 22.04 24.04 25.10	cjson	2026-01-26
Ubuntu	USN-7982-1	16.04 18.04 20.04 22.04 24.04 25.10	ffmpeg	2026-01-28
Ubuntu	USN-7977-1	18.04 20.04 22.04 24.04 25.10	git-lfs	2026-01-26
Ubuntu	USN-7971-1	22.04 24.04 25.10	glib2.0	2026-01-21
Ubuntu	USN-7979-1	25.10	jaraco.context	2026-01-27
Ubuntu	USN-7974-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10	libxml2	2026-01-22
Ubuntu	USN-7976-1	14.04 16.04 18.04 20.04 22.04 24.04	node-form-data	2026-01-27
Ubuntu	USN-7972-1	22.04 24.04 25.10	opencc	2026-01-21
Ubuntu	USN-7980-2	14.04 16.04 18.04 20.04	openssl, openssl1.0	2026-01-27
Ubuntu	USN-7980-1	22.04 24.04 25.10	openssl	2026-01-27
Ubuntu	USN-7975-1	22.04 24.04 25.10	pyasn1	2026-01-22
Ubuntu	USN-7978-1	22.04 24.04	screen	2026-01-26

Full Story (comments: none)