Welcome to the LWN.net Weekly Edition for November 20, 2025

This edition contains the following feature content:

• The current state of Linux architecture support: 21 flavors of hardware architecture that Linux can run on.
• Debian debates amending architecture support stratagem: should Debian have a blanket policy on retiring support for aging hardware architectures?
• Another Fedora Flatpak discussion: a fuss over Flatpak manifest attribution may lead to better Fedora Flatpak policies.
• A struct sockaddr sequel: Kees Cook continues trying to increase safety around the sockaddr structure.
• Hot-page migration and specific-purpose NUMA nodes: two patch sets are under review to address problems around the management of different types of memory.
• Pouring packages with Homebrew: an extra package repository and beer-themed way to manage software on Linux.

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.

Note that November 27 is the Thanksgiving holiday in the United States. As is our tradition, there will be no LWN Weekly Edition that day; we will be too busy eating to put one together. However, we will keep the lights on over the break and post the occasional article. We will be back to normal service with the December 4 Edition.

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

Comments (none posted)

The current state of Linux architecture support

There have been several recent announcements about Linux distributions changing the list of architectures they support, or adjusting how they build binaries for some versions of those architectures. Ubuntu introduced architecture variants, Fedora considered dropping support for i686 but reversed course after some pushback, and Debian developers have discussed raising its architecture baseline for the upcoming Debian 14 ("forky"). Linux supports a large number of architectures, and it's not always clear where or by whom they are used. With increasing concerns about diminishing support for legacy architectures, it's a good time to look at the overall state of architecture support on Linux.

The 6.17 kernel supports 21 different architectures (perhaps soon to be 22, thanks to the recent WebAssembly port), but making that statement already requires going into a bit more detail on what counts as an architecture. For example, Linux supports the User Mode Linux "architecture", which lets the kernel run as an unprivileged process inside an existing kernel for testing purposes. By most normal definitions, User Mode Linux isn't really a CPU architecture, even if the code for it lives alongside the kernel's other architecture support code. On the other hand, the kernel considers all PowerPC CPUs to be one architecture, regardless of whether they're running in big-endian or little-endian mode; most distributions count those as two architectures because software compiled for different endiannesses must be packaged separately. Even without architecture-wide incompatibilities like that, several architectures also offer different "levels" or optional extensions that make describing a piece of software's requirements a bit difficult. RISC-V has, at the time of writing, 48 different standards adding a larger number of extensions.

Still, the kernel's list of supported architectures is the closest thing to a definitive list of what counts as an architecture in the Linux world. Using that as a baseline, I checked the status of support in several popular distributions. The most restrictive is Arch, which only supports x86_64. Close behind is Fedora, which only has two main architectures and three secondary ones. Debian supports the second-most architectures, with six or seven officially supported architectures and something like 11 unofficial ones, depending on how one counts. Gentoo offers official installers for 13 architectures. Ubuntu is somewhere in between, with five official architectures and a vague suggestion that it may work on Debian's unofficial architectures as well.

The distinction between official and unofficial support is a bit fuzzy. In practice, a lot of software packaged by the different distributions will compile fine on unsupported architectures, provided an appropriate compiler is available. In Debian's case, official support means that it is part of the official release, it has been tested, and it will receive security updates. Unofficial architectures may be released on a delayed schedule, may have to deal with breaking changes, and might be dropped in between major versions if there are no volunteers to keep things working. For Fedora, a primary architecture is one where build failures on Koji, Fedora's package build farm, block the release process. Secondary architectures might also cause build failures on Koji, or might have their own separate package-build infrastructure, but failures don't stop the release.

Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH. The discussion around Rust's architecture support was recently reinvigorated by the fact that Debian's APT packaging tool will require Rust after May 2026. The project offers different tiers of support for various architectures, ranging from tier one (continuously tested and has official releases), through tier two (builds but does not have dedicated tests), to tier three (code is present to handle it, but support isn't being tested automatically).

A well-formatted table is worth a thousand words, so here is one summarizing the current state of architecture support on Linux:

Architecture	Commercially available	In kernel since	Minimum supported in kernel	Debian	Ubuntu	Fedora	Rust
Alpha	1992-2007	1994	EV56+	Unofficial	-	-	-
ARC	1996-	2013	ARC600	-	-	-	-
Arm (32-bit)	1985-	1998	ARMv4	ARMv5 (forky increases this to ARMv7-A+VFPv3D16)	-	-	Tier 2
Arm (64-bit)	2011-	2012	ARMv8-A+	Official	Official	Official	Tier 1
C-SKY	2017-	2018	v1	-	-	-	v2+, Tier 3
Hexagon	2006-	2011	V2+	-	-	-	Tier 3
LoongArch	2021-	2022	N/A	Unofficial	-	-	Tier 2
m68k	1979-	1996	68000+	Unofficial*	-	-	Tier 3
MicroBlaze	2002-	2009	v3.00.a+	-	-	-	-
MIPS	1985-	1995	mips1+	-	-	-	Tier 3
Nios II	2000-2023	2014	r1+	-	-	-	-
OpenRISC	2000-	2011	OR1k	-	-	-	-
PA-RISC	1986-2008	2000	1.1+	Unofficial [edited]	-	-	-
PowerPC (32-bit)	1992-2021	1995	ppc8xx, ppc603, or better	Unofficial, big-endian	-	-	Tier 2
PowerPC (64-bit)	1997-	2002	powerpc970+	Little-endian, officially; big-endian unofficially; version 8 or newer (proposed to raise to 9)	-	Little-endian; version 8 or newer	Tier 2
RISC-V	2014-	2017	It's complicated	Official	Official	Official	Tier 2
s390	1965-	2000	z10+	Official (z196; proposed to raise to z15)	Official	Official	Tier 2
SPARC	1986-	1994	v8+	Unofficial	-	-	Tier 2
SuperH	1992-2025	1999	SH-2 (with no MMU) or SH-3 (with a MMU)	Unofficial	-	-	-
x86 (32-bit)	1985-	1991	i486+	User-space only (i686+)	User-space only	User-space only	Tier 1
x86_64	2003-	2003	All	Official (raising baseline to v2 proposed)	Official (both v2 and v3)	Supported (all versions)	Tier 1
Xtensa	1999-	2005	N/A	-	-	-	Tier 3

Looking at this table, a few things are immediately clear. For one, the Debian project is doing a lot of work to ensure older CPUs remain usable. For another, the only architectures that are supported by Debian but not Rust are Alpha (for which no new CPUs have been produced since 2007), and SuperH. It might be tempting to assume that this means concerns about Rust compatibility are overblown, but it would be more accurate to say that people working with unpopular CPU architectures are probably not using mainstream Linux distributions.

In Arnd Bergman's OSS EU talk this year, he said that some of these architectures, primarily 32-bit Arm, are being kept alive for embedded development. New hardware is still being produced with 32-bit Arm CPUs, so he expects the kernel to support that configuration for at least ten years. The kernel still supports over a dozen 32-bit architectures that are used in older embedded systems, but their 64-bit replacement designs have almost exclusively moved to Arm and RISC-V, he said.

The Linux kernel's support for many architectures is both a strength — allowing it to be deployed in a huge number of possible use cases — and a source of complexity for maintainers. The kernel's memory-management code is particularly prone to architecture-induced special cases. For now, the kernel supports many more architectures than the mainstream distributions that depend on it do. If embedded uses continue to adopt RISC-V, however, that might not be the case in another few decades.

Appendix: Architecture information

Many of the architectures listed above were unfamiliar to me, so it was hard to imagine who might be using them. Below are brief descriptions of each architecture supported by the kernel, for context.

Alpha

Supported by: Debian (unofficially).

Introduced by DEC in 1992, Alpha is a 64-bit RISC architecture. The underlying intellectual property was sold to Compaq in 1998, which didn't do much with it until Hewlett-Packard purchased the company in 2002. The last Alpha-based systems were sold in 2007.

The kernel has supported Alpha since version 1.1.67 in 1994, making it the first non-x86 port. Alpha support is still kept up to date by Richard Henderson and Matt Turner. Debian officially supported Alpha between versions 2.1 and 5.0, and the port is still maintained unofficially.

ARC

Arc processors were first introduced in 1996, although support only reached the kernel in 2013. The kernel only supports 32-bit ARC CPUs; 64-bit support has not made it upstream so far. Work is continuing, though. The primary manufacturer of ARC CPUs, Synopsys, has largely pivoted to RISC-V designs, but ARC CPUs are still available. Support in the kernel is maintained by Vineet Gupta.

Arm

Supported by: Debian, Ubuntu, Fedora.

Arm is a considerably older architecture, dating from 1985. Despite its age, it has continued evolving and specifying different compatibility levels. Debian and Ubuntu both only support it when the CPU has built-in hardware for processing floating point numbers, but, as that is the typical configuration for Arm CPUs outside of embedded development, that doesn't pose any great hardship.

The kernel has supported Arm CPUs since version 2.1.80 in 1998, but the CPU version required has increased over time. Debian currently requires at least "armv7-a+fp": version 7-A, with floating point support. The kernel theoretically still compiles with GCC version 8, which in turns supports Arm version 2, but the kernel has deprecated anything earlier than Arm version 4. That release added support for half-word loads and stores, and removed support for 26-bit addressing.

C-SKY

C-SKY v1 CPUs are compatible with Motorola M·CORE, which have been available since 1997, but the first C-SKY-branded CPUs were released in 2017. C-SKY is the second most recent architecture added to the kernel. It was introduced in 2018, in version 4.20. At the time, Bergman said that it might well be the last architecture ever added to the kernel, since newer designs seem to be focusing on RISC-V, which the kernel already supports. That prediction did not prove to be correct, however, with LoongArch being added to the kernel in 2022. C-SKY is a 32-bit architecture that is not much used outside of China, where it is produced by a company of the same name.

Hexagon

Unlike the other architectures in this list, Hexagon is the architecture of a family of digital signal processors from Qualcomm. First introduced in 2006, support was added to the kernel in 2011, where it is maintained by Brian Cain. Hexagon is notable for having a number of features dedicated to hardware-assisted parallelism.

LoongArch

Supported by: Debian (unofficially).

LoongArch is the newest architecture supported by the kernel, arriving in 2022. It is a RISC architecture quite similar to MIPS, although newer architecture revisions have been adding more custom instructions. The company that created it, Loongson, uses it in high-performance, multi-core servers; its previous lower-power CPUs used MIPS. Kernel support is maintained by Huacai Chen.

m68k

Supported by: Debian (unofficially).

Motorola 68000, usually abbreviated m68k, is a big-endian 16- or 32-bit architecture originally released in 1979. It was discontinued in 1996 — ironically, the same year that support first appeared in the kernel, in version 1.3.94. It is maintained in the kernel by Geert Uytterhoeven. The unofficial Debian port runs on the original m68k CPUs, but not the newer coldfire CPUs.

This architecture is notable for powering several early home computers and portable computing devices, including early Apple Macintoshes, Commodore Amigas, the Atari ST, the Sega Genesis, the AT&T UNIX PC, the NeXTstation, TI-89 calculators, and the Palm Pilot. Because of its extremely wide use, m68k is likely to continue being supported, one way or another, by folks passionate about that era of hardware.

MicroBlaze

MicroBlaze is a CPU core design intended for embedding in a field-programmable gate array. It was introduced in 2002, with support coming to the kernel in 2009. Support in the kernel is maintained by Michal Simek. The kernel has, so far, supported only the 32-bit version of the CPU. 64-bit support exists out-of-tree, but is unlikely to be merged in the future because the company behind MicroBlaze, Xilinx, has moved on to RISC-V designs.

MIPS

MIPS was released in 1985. Since then, it has received regular updates, the most recent of which was version 6 in 2014. Linux has supported it since version 1.1.82 in 1995. Even though the architecture is regularly updated (and the oldest processors for it have fallen out of their patent period), no major Linux distribution maintains a port. The overall maintainer for MIPS in the kernel is Thomas Bogendoerfer, but there are a large number of other maintainers who work on specific chips, drivers, and other components of MIPS support.

Nios II

A 32-bit RISC CPU intended for embedded use in field-programmable gate arrays (FPGAs), Nios II has been supported in the kernel since 2014, where it is maintained by Dinh Nguyen. Intel deprecated the design in 2023 in favor of a RISC-V-based successor. Nios II is interesting because it was implemented entirely in programmable logic, meaning that the CPU could be extended with custom instructions or peripherals that were programmed directly into the same FPGA.

OpenRISC

OpenRISC is a project to develop an open-source CPU; the design of the OpenRISC 1000 CPU is available under a GPL license. It was introduced in 2000, with support in the kernel introduced in 2011. It is maintained by Jonas Bonn, Stefan Kristiansson, and Stafford Horne. The OpenRISC web site has links to three different processor implementations and several simulators that can be used to try out OpenRISC code.

PA-RISC

Supported by: Debian (unofficially).

Also known as HPPA, PA-RISC was released in 1986 as a way for HP to consolidate its different computer offerings on the same CPU design. That sort of happened, although HP continued offering some products based on other designs. Support was added to the kernel in 2000, where it is maintained by James Bottomley and Helge Deller.

PowerPC

Supported by: Debian, Ubuntu, and Fedora.

PowerPC is another architecture that supports running in big-endian or little-endian mode; unlike Alpha, SPARC, or MIPS, however, there is good support for actually running Linux on it in either endianness configuration. The architecture was introduced in 1992, and supported in the kernel since version 1.3.45 in 1995, although that support has moved around between a few different architecture names over time. PowerPC code has gone by "ppc", "ppc64", and "powerpc" at various points in the kernel's history (currently the latter). Presently, support for the architecture is maintained by Madhavan Srinivasan and Michael Ellerman.

Debian supports little-endian 64-bit PowerPC officially, and has two different unofficial ports for 32-bit big-endian PowerPC and 64-bit big-endian PowerPC. The official port seems to require version 8 (released in 2014) or newer hardware, although there is a proposal to increase that to version 9 (released in 2017) for the next Debian release, since Debian's build fleet is all version 9. Ubuntu has official support for both the big-endian and little-endian 64-bit variants, interestingly. That makes big-endian 64-bit PowerPC the only architecture that Ubuntu supports officially that Debian does not. Fedora restricts itself to supporting little-endian 64-bit PowerPC.

RISC-V

Supported by: Debian, Ubuntu, and Fedora.

RISC-V is an interesting architecture because, while it has taken some time to get going, there are a large number of implementations with different targeted use cases in development at the moment. It's also notable for having a large number of optional extensions that can be implemented independently. On the one hand, this makes it possible for the same architecture to scale from low-power embedded cores to high-performance server CPUs. On the other hand, it makes testing software more difficult. Since the extensions can be implemented independently, there isn't a simple way to agree on a baseline for support beyond just listing extensions. Kernel support was added in 2017, and is maintained by Paul Walmsley, Palmer Dabbelt, and Albert Ou.

s390

Supported by: Debian, Ubuntu, and Fedora.

IBM's System/390 mainframes, with their custom microprocessors, are surprisingly well-supported by modern Linux. The base design of the architecture dates from the s/360 in 1965, but the first mainframes theoretically capable of running Linux were introduced in 1990. Those mainframes transitioned to a new 64-bit architecture with a different name in 2000, the same year that support was introduced to the kernel in version 2.3.99pre8. Despite the new architecture officially being "z/Architecture", most references call it s390x.

The architecture has continued receiving updates, and Ubuntu requires the relatively recent z15 version, released in 2019. Debian has proposed updating to the same baseline, although the build infrastructure is actually composed entirely of z16 processors. Fedora theoretically supports anything after z13, although the project's documentation on the topic has not been updated in some time.

SPARC

Supported by: Debian (unofficially).

SPARC is an architecture introduced in 1986. Support in the kernel was added in version 1.1.71 in 1994, and is maintained today by David Miller and Andreas Larsson. Debian unofficially supports 64-bit SPARC, but no distribution still supports 32-bit SPARC. A new open-source design for SPARC cores, LEON5, was released in 2019. The kernel supports v8, but that version lacks proper atomics, which can lead to problems. A more practical lower limit would be v8e or v9.

SuperH

Supported by: Debian (unofficially).

SuperH is a 32-bit architecture originally produced by Hitachi and later sold to Renesas. It's notable for being entirely out from under its design patents, which has allowed the architecture to be reverse engineered and reimplemented. Official support from Renesas ended in 2025, so those reimplementations are the only source of new SuperH CPUs.

x86

Supported by: Debian, Ubuntu, Arch, and Fedora.

Released in 1978, and then incrementally updated to larger word sizes in 1985 and 2003, x86 is an extremely popular architecture. It is little-endian, still under active development, and has been supported in the kernel since the beginning. Despite that, the support story is actually not as straightforward as it might appear. Since x86 has evolved over time, there are differences between support for the 32-bit version and the 64-bit version. Debian supports a full 32-bit installation on CPUs newer than i486Debian supports a 32-bit userspace in some circumstances, but has stopped shipping 32-bit kernels. Ubuntu only supports some 32-bit binaries running in a 64-bit installation. Other distributions are all-in on 64-bit, but still have different baseline architecture versions.

Ubuntu recently announced that the project, while continuing to support older versions, would compile separate versions of all packages for x86-64-v3, dating from 2013. Fedora and Arch both support any 64-bit-capable CPU, regardless of version.

Xtensa

Finally, Xtensa is yet another 32-bit RISC architecture. It's specifically designed for extension, with the possibility of configuring many CPU features and adding custom instructions. It is mostly used in digital signal processors.

[ Thanks to Bergman for his help in fact-checking this article. ]

Comments (65 posted)

Debian debates amending architecture support stratagem

The Linux kernel supports a large number of architectures. Not all of those are supported by Linux distributions, but Debian does support many of them, officially or unofficially. On October 26, Bastian Blank opened a discussion about the minimum version of these architectures that Debian should support: in particular, raising the de-facto minimum versions in the next Debian release ("forky"). Thread participants were generally in favor of keeping support for older architecture variants, but didn't reach a firm conclusion.

Blank noted that Debian doesn't currently have a policy for which architecture versions should be supported. Three architectures do specify a minimum version of GCC, which in turn implies some limits on architecture versions: Arm CPUs must be armv7-a+fp or newer, 32-bit x86 CPUs must be i686 or newer, and s390 CPUs must be z196 or newer. (Version z196 is followed, naturally, by z114, then by zEC12, zBC12, and z13. Since z13, IBM has continued counting with the same numbers that everyone else uses.) These architectures are all fairly old. Arm version 7 dates from 1993, with the last processors being sold in 2001. ARM7 was from 1993, but ARMv7 is from 2005, and CPUs are still being sold.

Starting in Debian 14 ("forky"), Blank proposed that 64-bit x86 CPUs should require version x86-64-v2, PowerPC CPUs should require power9, and s390x CPUs should require z15. x86-64-v2, in particular, features wider atomic compare-and-exchange operations and more single-instruction multiple-data (SIMD) instructions.

As a general guidance I would like to aim for a ten to 15 years support range at release time. The cutoff in respect to the expected 2027 release date of Forky would therefor be 2012 to 2017. More time is given for widely used architectures, less for more specialized ones."

This recommendation was seemingly motivated by matching the composition of Debian's build infrastructure, which doesn't have any PowerPC machines older than power9, or s390x machines older than z16. If Blank's proposal were adopted, the distribution could potentially drop support for older architecture versions in 2030, which would be the end of Debian 13 ("trixie") long-term support.

Marco d'Itri thought that retiring architecture variants after 15 years from release was reasonable: "Debian's purpose is not to enable retrocomputing projects." That didn't sit will with all members of the list, however. Jan-Daniel Kaplanski objected, noting that the ability to use Debian with a wide variety of hardware was one of the appealing properties of the distribution. Even if a 15-year rule were adopted, however, it should be from the last year the CPU was available to buy: PowerPC version 8 CPUs were still sold last year, he said. Kaplanski would want them supported through 2039. Romain Dolbeau didn't think that was enough:

Debian is (at least up to now) the Linux distribution one could rely on to support hardware as long as its actual life without forcing users to upgrade. I have ~2007 (Penryn) systems still in use that were deployed with Debian when new, and I'm sure I'm not the only one. If it ain't broke, don't fix it, just upgrade Debian :-)

Marc Haber pointed out that Debian depends on kernel and toolchain support for its different architectures; he then clarified that his concern was about upstream support timelines. If the kernel or the toolchain did drop support for an older version of an architecture, it might do so with relatively little notice compared to Debian's long-term support timelines. He thought that Blank had a point in wanting to establish a policy years in advance of any potential deprecation, so that people could plan around it. Diederik de Haas opined that the kernel would not drop support without an announcement far in advance, and said that all of the concerns that had been raised in favor of Blank's proposal so far were hypothetical.

Simon Richter thought that the decision should be based on potential performance improvements, not just how old an architecture is. SIMD instructions (and other specialized instructions) can be noticeably faster for some programs, although they don't help with programs that spend most of their time waiting on I/O. He also suggested that it would be nice to have a way to automatically migrate users to an unofficial Debian port if the official releases raise their minimum supported versions.

John Klos asked why any change was needed — if it was intended to reduce the amount of work for Debian maintainers, what specific work would be avoided? Peter Green replied that architecture improvements sometimes "eliminate a significant source of bullshit", and gave the example of moving from x87 to sse2 floating point instructions on x86_64. On the other hand, he didn't think that Blank's proposed updates really gained that much: the newer versions that the proposal would mandate don't actually contain significant architectural changes.

Ultimately, the discussion did not result in any specific decision being made. It seems likely that Debian will maintain its current level of architecture support for forky, but in the absence of a specific policy, the debate will certainly arise again. The Linux community is, in some ways, a tug of war between different interests: some people want the maximum performance possible from their software, some people want to continue using the hardware they have available, and everyone has problems with getting enough time and energy to work on these things. How those competing interests eventually shake out — and whether people are eventually able to find a compromise position — comes down to who shows up to do the work.

Comments (95 posted)

Another Fedora Flatpak discussion

Many distributions provide support out of the proverbial box for Flatpak packages, but Fedora is unusual in that it also provides, and defaults, to its own repository of Fedora-built Flatpaks. This has been a source of confusion for Fedora users, who expect to get the Flatpak built by the original developers and hosted on Flathub. It has also been a source of conflict with upstream projects, because users complain of bugs in Flatpak packages they are not responsible for. The situation has also frustrated some Fedora developers, who would prefer to put Flathub's offerings first. A new complaint that Fedora has apparently used manifests from Flathub to build the packages for Fedora—without giving credit to the original authors—has spurred discussions about Fedora's Flatpaks once again. While no concrete changes are on the table, yet, there may be some movement toward addressing persistent complaints.

Any developer or project can provide a repository with their software in Flatpak format; however, Flathub is the de facto hosting service for Flatpaks these days. Projects that publish Flatpaks expect users to get them from Flathub, and users looking for software would generally expect to get the Flathub version of a Flatpak.

However, Fedora provides its own repository and runtime for Flatpaks, and the Workstation edition ships GNOME Software configured to install Fedora Flatpaks by default—rather than Fedora's RPMs or Flathub Flatpaks—when they are available. LWN covered Fedora's Flatpak offerings and priorities in February, following a disagreement with the Open Broadcaster Software (OBS) Studio project about problems with Fedora's OBS packages.

The complaint

Every application on Flathub has a link to its manifest file: a JSON or YAML file with information on building its Flatpak. For example, the Foliate e-book reader's Flathub page links to its manifest repository on GitHub.

Fedora's most recent discussion around Flatpaks began with an accusation from Hari Rana on November 3, which claimed that Fedora is acting as a "hostile 'alternative' to Flathub":

An indeterminate amount of their packages are, in fact, directly based on existing manifests from Flathub. Not by manually inspecting code themselves; rather, by running a script that goes through Flathub's APIs and parses the respective apps' manifest to generate manifests for Fedora Flatpaks: [link]

All this, without crediting the original authors.

Flathub and Fedora use different tools to build Flatpaks, and publish them using different formats: currently, Flathub uses the OSTree format, while Fedora has switched to the Open Container Initiative (OCI) image format to ship its Flatpaks. Using the OCI format allows Fedora to host its Flatpaks along with its other container images, and means Fedora does not have to host a separate Flatpak repository. It also means that Fedora can use container tooling to build its Flatpaks. The tools for building Fedora Flatpaks do not use the manifest file; they use a container.yaml file to provide the recipe for building a container to be used for the Flatpak.

The Fedora Flatpak packaging tutorial explains that the flatpak-module tool searches Flathub for an application that matches a search term. If found, it uses that application's manifest to initialize the configuration file used by Fedora's tools. However, in doing so, it does not provide any attribution or mention of the original manifest.

The manifest file format does not contain author or licensing metadata for itself. In the case of Foliate, for example, the manifest JSON file is in its own repository under the Flathub organization. There is no license associated with the repository, and there are nine contributors to the file throughout its history. Skimming the other manifests in Flathub repositories, I have not found any that contain a license for the manifest or provide clear attribution for the manifest. Fedora's tooling could, however, simply provide a link back to the manifest that is used to generate the container.yaml file.

It is worth noting that there is a school of thought that such build instructions are not subject to copyright at all. However, many distributions—including Fedora—do assign a license to package build configuration files. LWN covered the topic of licensing control files in November 2024, when Arch Linux announced it would assign a license to its PKGBUILD files.

Discussion

The post was shared on Fedora's Discourse forum on November 4, by "Victoria". Michael Gruber replied that the responses on social media to Rana's post were by people who did not understand Fedora or Flatpaks: "But this gives Fedora as a whole bad PR. We need to do and communicate our flatpaks right." Victoria replied that Fedora should just drop its Flatpaks: "Fedora is the only distro that's feeling the need to be different."

That led to a back-and-forth discussion about the desirability of Fedora providing its own Flatpaks. Ashley Thorne said that they were glad that Fedora's repository exists, if only to provide an alternative:

I don't think Fedora should compromise on its ideals (security/philosophical) because people pressure them into doing so. At the very least, I would like to see some big security improvements (no EOL runtimes, more rules for vendored dependencies) from Flathub before it becomes "default". But I have my doubts those improvements will happen. Flathub needs to be easy with little maintenance for proprietary companies to buy-in.

Kyle Gospodnetich, creator and a maintainer of the Fedora-based Bazzite distribution, complained that Fedora's Flatpaks are "actively damaging flatpak's reputation among the Linux community and making the out-of-box experience of Fedora as painful as possible", and later referred to the dispute with the OBS project's maintainers as an example of a problem with Fedora Flatpaks. He noted that the maintainers of Fedora's Atomic Desktops had asked "multiple times to be freed from Fedora Flatpak". Most recently, Timothée Ravier put forward a change proposal for Fedora 43 that would have limited the number of Fedora Flatpaks available on the Atomic editions of Fedora. He listed a number of disadvantages to Fedora's Flatpaks, including "little maintenance and traction in the community", no procedure to remove or deprecate Fedora Flatpaks, as well as technical downsides with the OCI format used by Fedora.

In considering the proposal, Fedora Engineering Steering Committee (FESCo) member Stephen Gallagher outlined his perspective on why Fedora needed to offer its own repository. He cited a need to vet any application shipped by Fedora:

As a distributor of software, we have an obligation to our users to validate what we provide in some way. This does not necessarily mean that it has to be built directly by us, but it does mean that at some point Fedora needs to evaluate the delivery pipeline of any application we ship.

He said that there was "definitely room for improvement on both the Fedora side and the Flathub side", and was optimistic that things could be improved. He voted against the proposal, and FESCo rejected the proposal.

Flathub problems

On November 5, Fedora Project Leader (FPL) Jef Spaleta replied to the thread. He said that he had been specifically unable to talk about Flathub for about three months, "because I found a very significant copyright license violation problem with the flatpak runtimes they host" in July. Spaleta said that if he had wanted "an actively hostile relationship" with Flathub, he could have made noise about the copyright violations. Instead, "I had some quiet conversations" with people who could resolve the problem and gave them time to do so.

The problem Spaleta referred to was announced by Bartłomiej Piotrowski of the Flathub project on October 24. Copyright notices and license files were being omitted when software was being bundled as a Flatpak and distributed via Flathub. He said that the problem was "a genuine oversight", and that the project had worked with GNOME, KDE, Flatpak developers, and the freedesktop-sdk teams to "make it easier than ever for developers to ensure their applications properly include license and copyright notices".

Spaleta said that he would love nothing more than to make a case that Fedora could stop providing its own Flatpaks. However, he said that Fedora could not live with the amount of time it takes Flathub to address compliance problems. Fedora has "a higher risk profile than either Flathub or other projects that depend on it", and taking months to address copyright-compliance issues is not acceptable.

I have to have a way to address the inherent liability associated with license compliance from a distributor point of view for any flatpaks that Fedora pre-installs as part of any composed images.

Aside from license-compliance concerns, he noted that Fedora also needed its own solution because it builds Flatpaks for architectures that Flathub does not support.

Ravier replied that his change proposal for Flatpaks on Atomic desktops specifically addressed those concerns, but was rejected. Spaleta replied that he was aware of that, but the proposal had not addressed other spins and editions that might preinstall other Flatpaks that could cause Fedora liability.

Discussion

Victoria asked if Spaleta would commit to working with Flathub to resolve problems. He replied: "do you think I was looking at the internals of the flatpak runtimes for fun when I found the compliance problem?" He said that he was trying to build a bridge with Flathub to improve the relationship, and it would help if people stopped starting fires.

In that spirit, Gospodnetich asked if Fedora could change the way Flatpak itself is packaged for Fedora. Currently, the package includes a systemd service that enables Fedora's Flatpak repository. He pointed to a pull request to make the Fedora Flatpaks service an optional package. Spaleta said that he had no power to decide if the pull request would be accepted, but "it seems a reasonable adjustment to me without a lot of risk".

Spaleta said later that he had discussed the original complaint about uncredited use of Flathub manifests with Rob McQueen of the GNOME Foundation. "Neither of us identify this as something expected to be attributed." However, if Flathub decides later that it should be documented "we'll try to figure it out".

There was a lengthy discussion, and a fair amount of finger pointing and airing of past grievances. The thread was set to "slow mode" which only allowed participants to comment once every two hours. Rana joined the conversation and recounted their previous involvement with Fedora's Flatpaks and reasons for losing interest in the effort. Spaleta replied to say that he was not around during Rana's tenure with Fedora, but sympathized with their frustration.

Eventually, Spaleta floated the idea that Fedora's Flatpak special interest group (SIG) could be organized more like EPEL, which provides extra packages for Red Hat Enterprise Linux (RHEL) and its derivatives like AlmaLinux and Rocky Linux. He also suggested that Ravier's proposal could be revived and approved for the Fedora 44 release.

Spaleta did not provide a concrete plan but he did say that a proposal to get Fedora's Flatpak SIG "in a healthier place overall" could show up as a change proposal in the release cycle for Fedora 44 "if we can get it together". The "if" in that comment is doing a lot of work; depending on the scope of the eventual proposal, the deadline for submission could be as early as December 17.

With luck, Fedora will be able to address some of the persistent complaints from its users, upstream open-source projects, and downstream projects that use Fedora as a base. In particular, ensuring that users are aware of the difference between Fedora and Flathub Flatpaks, and have full control over which repositories and packages are installed, would go a long way toward reducing (if not eliminating) complaints.

Comments (139 posted)

A struct sockaddr sequel

One of the many objectives of the Linux Kernel Self-Protection Project (KSPP), which just completed ten years of work, is to ensure that all array references can be bounds-checked, even in the case of flexible array members, the size of which is not known at compile time. One of the most challenging flexible array members in the kernel is not even declared as such. Almost exactly one year ago, LWN looked at the effort to increase safety around the networking subsystem's heavily used sockaddr structure. One year later, Kees Cook is still looking for a way to bring this work to a close.

In short, the problem is that struct sockaddr is traditionally defined as:

    struct sockaddr {
        short sa_family;
	char sa_data[14];
    };

The sa_data field was more than large enough to hold a network address in the early 1980s when this structure was first defined for BSD Unix, but it is not large enough now. As a result, a great deal of code, in both the kernel and user space, passes around struct sockaddr pointers that, in truth, point to different structures with more space for the addresses they need to hold. In other words, sa_data is being treated as a flexible array member, even though it is not declared as one. The prevalence of struct sockaddr has thrown a spanner into the works of many attempts to better check the uses of array members in structures.

At the end of last year's episode, much of the kernel had been changed to use struct sockaddr_storage (actually implemented as struct __kernel_sockaddr_storage), which has a data array large enough to hold any known network address. An attempt was made to change the definition struct sockaddr to make its sa_data field into an explicit flexible array member, but that work ran into a minor snag. There are many places in the kernel where struct sockaddr is embedded within another structure. In most of these cases, sa_data is not treated as a flexible array member, so developers have freely embedded struct sockaddr anywhere within the containing structure, often not at the end.

If sa_data is redefined as a flexible array member, the compiler no longer knows how large the structure will actually be. That, in turn, means that the compiler does not know how to lay out a structure containing struct sockaddr, so it guesses and emits a warning. Or, in the case of a kernel build, tens of thousands of warnings. Kernel developers, as it turns out, would rather face the prospect of an array overflow than a warning flood of that magnitude, so this work came to a halt.

One possible solution would be to replace embedded struct sockaddr fields with struct sockaddr_storage, eliminating the flexible array member. But that would bloat the containing structures with memory that is not needed, so that approach is not popular either.

Instead, Cook is working on a patch series that introduces yet another struct sockaddr variant:

    struct sockaddr_unsized {
	__kernel_sa_family_t	sa_family;	/* address family, AF_xxx */
	char			sa_data[];	/* flexible address data */
    };

Its purpose is to be used in internal network-subsystem interfaces where the size of sa_data needs to be flexible, but where its actual size is also known. For example, the bind() method in struct proto_ops is defined as:

    int	(*bind) (struct socket *sock,
		 struct sockaddr *myaddr,
		 int sockaddr_len);

The type of myaddr can be changed to struct sockaddr_unsized * since sockaddr_len gives the real size of the sa_data array. Cook's patch series does many such replacements, eliminating the use of variably sized sockaddr structures in the networking subsystem. With that done, there are no more uses of struct sockaddr that read beyond the 14-byte sa_data array. As a result, struct sockaddr can be reverted to its classic, non-flexible definition, and array bounds checking can be applied to code using that structure.

That change is enough to make all of those warnings go away, so many would likely see it as a good stopping point. There is still, though, the matter of all those sockaddr_unsized structures, any of which might be the source of a catastrophic overflow at some point. So, once the dust settles from this work, we are likely to see some attention paid to implementing bounds checking for those structures. One possible approach mentioned in the patch set is to eventually add an sa_data_len field, so that the structure would contain the length of its sa_data array. That would make it easy to document the relationship between the fields with the counted_by() annotation, enabling the compiler to insert bounds checks.

While the ability to write new code in Rust holds promise for reducing the number of memory-safety bugs introduced into the kernel, the simple fact is that the kernel contains a huge amount of C code that will not be going away anytime soon. Anything that can be done to make that code safer is thus welcome. The many variations of struct sockaddr that have made the rounds may seem silly to some, but they are a part of the process of bringing a bit of safety to an API that was defined over 40 years ago. Ten years of KSPP have made the kernel safer, but the job is far from done.

Comments (14 posted)

Hot-page migration and specific-purpose NUMA nodes

For better or for worse, the NUMA node is the abstraction used by the kernel to keep track of different types of memory. How that abstraction is used, though, is still an active area of development. Two patch sets focused on this problem are currently under review; one addresses the perennial problem of promoting heavily used folios from slower to faster memory, while the other aims to improve the kernel's handling of nodes containing special memory installed for a specific purpose.

Hot-page tracking

Over the last several years, there has been an ongoing push to create systems with multiple classes (or "tiers") of memory. While most memory might be ordinary RAM, a system could also be equipped with a small amount of high bandwidth memory and, perhaps, larger amounts of relatively slow memory. In the absence of other concerns (such as a policy requiring low-price tenants to languish in slower memory), the system is generally best served by placing the most frequently accessed data in its fastest memory.

Actually placing data that way can be tricky, though. The kernel can, with relative ease, detect memory that has not been accessed for a while; the data stored there can then be pushed down to slower memory. Figuring out which data in slower memory should be moved to faster tiers is harder, but it is an important problem to solve; otherwise demotion to lower tiers could become a one-way trip. Some types of hardware are beginning to gain features that can track frequency of access, but the kernel is not yet prepared to make the best use of those features.

Bharata B Rao has been working on a solution to this problem for a while; this work was covered here in March 2025. The latest version of his patch series has evolved somewhat since then. At its core, though, it remains a mechanism by which any kernel subsystem that has information about when a given page was last accessed can report that data to a central registry, which then uses the accumulated data to determine which pages (or, more correctly, which folios containing those pages) should be migrated to faster memory.

This new subsystem provides a call that can be used to report memory activity:

    int pghot_record_access(unsigned long pfn, int nid, int src,
                            unsigned long time);

The pfn parameter should contain the page-frame number of the page that was accessed. If the NUMA node from which the access originated is known, it should be passed in nid; otherwise the caller should pick a top-tier node to identify here. The time of the access, if known, is passed in time. The src parameter describes the source of this information — how the activity on the given page was detected. It should be one of PGHOT_HW_HINTS (activity reported by the hardware), PGHOT_PGTABLE_SCAN (obtained by scanning page tables), or PGHOT_HINT_FAULT (a page fault).

The way this data is managed has changed in this version of the patch set, which now maintains a single long int value for each page being tracked. That is a significant amount of overhead in a kernel where efforts are being made to squeeze every bit out of struct page, but it is significantly reduced from previous versions. That integer value is split into four fields containing a NUMA node ID, an access count, the time of last report, and a "should be promoted" flag.

When a new report comes in, pghot_record_access() looks at the existing information for the indicated page. If the NUMA node stored there differs from the node passed to this call, or if the time since the last reported access exceeds a threshold, old data will be discarded and the access count set to one, attributed to the indicated nid. Otherwise, the existing access count will be incremented (unless that would cause it to overflow). If the access count exceeds another threshold (wired to two in this series), the sign bit will be set as an indicator that the page is hot and should be moved to a faster tier.

Also part of this series is a new kernel thread that occasionally scans the hotness data and attempts to promote the pages that have been marked as active. There is a set of sysctl knobs that the administrator can use to control which types of hotness data should be accepted. Another new kernel thread performs page-table scanning, noting which pages are accessed and reporting that information so that the hot pages can be promoted.

The benchmark results included with the series seem somewhat inconclusive, showing some improvements and some significant regressions. This series might be converging on an approach that will pass muster, but there is still clearly work to be done.

Specific-purpose nodes

As a general rule, if a NUMA node presents memory to the system, that memory becomes freely available for the kernel, and eventually user space, to use as it will. The list of nodes that a process can be allocated can be restricted with the kernel's memory-policy API or the cpuset mechanism, but the default is to allocate memory globally. That approach does not work well in the presence of memory that has special characteristics that make it unsuitable for general use. Gregory Price is looking to address that problem with the concept of specific-purpose memory NUMA nodes, which would host memory that is not generally available for use as system RAM.

As an example of the type of node he is planning for, he mentions a compressed-memory node. This could be a CXL-attached device that automatically compresses pages written to it, and decompresses them when they are read back. It would work well as a sort of swap device but, since data stored there is essentially read-only, this memory is not suitable for use as ordinary system RAM. This node could be marked as a specific-purpose node when it is added to the system; a modified version of zswap could allocate pages from it and swap data there, but that node's memory would not be available for most allocation requests.

The implementation of this concept is simple and clearly not intended to be the complete solution. When added to the system, a memory node can be marked as either "sysram" (ordinary memory) or "specific-purpose"; that designation cannot be changed during the life of the system. The sysram nodes are collected into a list and used to satisfy normal allocation requests. To obtain memory from a specific-purpose node, a kernel function must specify that node explicitly in its allocation request and provide the new __GFP_SPM_NODE allocation flag. There is no way to directly allocate specific-purpose memory from user space.

That is about as far as the series goes; a few things are missing still. For example, while a node can be marked as specific-purpose, there is no way to indicated which of many possible purposes the memory is specific to. The zswap implementation simply takes the first specific-purpose node it finds and assumes it will be of the right type. There has also not yet been effort put into implementing basic memory-management functions like reclaim and compaction on specific-purpose memory.

The purpose of this patch set is clearly to get a conversation started on how nonstandard types of memory should be handled in the kernel. Price has a proposed session at the upcoming Linux Plumbers Conference that will try to push some of these ideas forward. Thus, further developments can presumably be expected in December.

Comments (1 posted)

Pouring packages with Homebrew

The Homebrew project is an open-source package-management system that comes with a repository of useful packages for Linux and macOS. Even though Linux distributions have their own package management and repositories, Homebrew is often used to obtain software that is not available in a distribution's repository or to install more current versions of projects than are available from long-term-support (LTS) distributions. Homebrew 5.0.0, released on November 12, 2025, expanded Linux support to include 64-bit Arm packages in addition to x86_64, and turned on concurrent downloads by default to speed up package downloads.

The project began in 2009 as a package-management system for Mac OS X, later macOS, which did not (and still does not) have a package manager as such. It allowed users to easily install and manage software not included with the operating system or available in Apple's App Store; in particular, it is popular for installing open-source applications that are either unavailable with macOS or shipped with the operating system but severely outdated.

Over time, a fork of the project called Linuxbrew became a popular way to install software on Linux as well. It was merged with Homebrew for the 2.0.0 release in 2019. In addition to serving as a supplement to a distribution's package repositories, Homebrew has become a recommended method of managing software on some image-based distributions, such as Bazzite, which do not support traditional Linux package management using APT, DNF, etc. It makes a good complement to Flatpak for such systems; Homebrew's focus is command-line and server software, rather than desktop applications.

Getting started

Homebrew is written in Ruby and available under a BSD 2-clause license. The recommended way to install Homebrew on Linux is, unfortunately, by fetching the install script via curl and feeding it to bash. It prompts for sudo access during the install, so users need to be able to use sudo to install Homebrew—or to persuade the system's administrator to do it for them—but afterward it does not require sudo to install or manage software.

The installer puts Homebrew in /home/linuxbrew/.linuxbrew; users will need to add that to their path afterward. The project's install documentation notes that it is possible to install Homebrew elsewhere, but it is unsupported: "If you decide to use another prefix: don't open any issues, even if you think they are unrelated to your prefix choice. They will be closed without response."

That may seem a bit odd, but there is a reason for the project's choice of directory and insistence that users stick to that directory or take their chances. It is possible to compile Homebrew packages from source, but the default is to install a prebuilt binary package which is (maintaining the overall theme) called a bottle. Some of the precompiled binaries contain hard-coded paths, so the project chose /home/linuxbrew as the default directory. In the early days of the Homebrew project, the default was to compile from source rather than to install precompiled binaries—so there were no doubt many packages that already had ~/.linuxbrew as the default location.

Once installed, the brew command can be used to install, update, remove, and otherwise manage software. The "brew help" command will provide a short list of available operations and a link to the documentation. As one might suspect from the name and logo (a mug of beer), the project leans heavily into beer-related terminology, which is helpfully documented online.

A package definition for Homebrew that builds from upstream open-source projects is called a formula (plural "formulae"); these are written in Ruby. A Git repository of formulae is called a tap, and the project maintains a core repository (the "core tap") with hundreds of formulae.

So, "brew install fzf" would install the bottle for the fzf command-line fuzzy finder project, as well as any dependencies. Adding the source option (-s) would build fzf from source, though it still downloads fzf's dependencies as binaries. It seems something of a terminology miss that dependencies are not called "chasers", but I digress.

Brewing

Anyone can submit a formula to the core repository: the guidelines for acceptable formulae include a requirement that the software is available under a license that meets the Debian Free Software Guidelines. That is not the sole requirement, of course. The project also has a prohibition on software that upgrades itself (rather than being updated using "brew update"), and discourages vendoring other software, though the guidelines indicate flexibility. If something cannot be packaged without vendoring, "so be it; better to have packaged software in Homebrew than not." Homebrew refers to the policies from Debian and Fedora as examples of acceptable vendoring practices. Homebrew also has the sensible requirement that a formula must use a stable version tagged by the upstream project; the project does not want to be shipping unstable software, unreleased versions, etc.

Finally, its documentation notes that exceptions to its guidelines may be made in either direction: some software that meets the written criteria may be rejected, and some software may be accepted that does not meet all the criteria. "Although some rejections may seem arbitrary or strange they are based on years of experience making Homebrew work acceptably for our users."

Software need not be in the core repository to work with Homebrew, however. Users may want to package software for their own use without submitting it to the project, which can be done by creating a custom tap. The "brew tap" command can be used to add a third-party repository; the project maintains a list of interesting third-party taps users may want to try out.

Homebrew also provides packages that are only available in binary format and that are not (necessarily) open source; these are called casks. This is mostly a convenience feature for macOS; it allows users to install and manage popular desktop applications, such as Ghostty, GIMP, or Zoom, from the command line instead of having to use the App Store or download an Apple Disk Image (DMG). Homebrew added preliminary support for Linux casks with the 4.5.0 release in April 2025. I haven't, so far, found any packages I wanted to install via Homebrew that were casks rather than formulae, but I expect that the community will add a larger selection of casks over time.

Linux users who are comfortable with DNF or APT will have no problem acclimating to using Homebrew. The basics are pretty much the same; "brew install" installs packages, "brew search" is used to find available packages, "brew upgrade" upgrades packages, and so forth. Running "brew commands" will display a full list of brew's built-in commands, including those for creating and working with formulae. For example, "brew edit fzf" will open the Ruby script for fzf's package.

One thing I like about Homebrew is the amount of information provided about packages and how easy it is to search the development history of packages. The "brew search --pull-request text" option allows users to search Homebrew's GitHub repositories, including the formulae, cask, and main project repository, for any pull requests that have been submitted to the project with "text" in them. This means that one can search for all pull requests that match a package name or other term of interest.

Analytics

The "brew info package" command provides the version of the package, its repository information, how much space it takes up on disk, license, and the analytics information for the package. That last bit is something Linux users will no doubt want to know more about.

By default, Homebrew enables anonymous analytics after it is installed and has shown the user a notice about analytics. No analytics are sent during the installation. The notice is part of many messages displayed to the user after install, and is easy to miss; but the project does provide a link to the documentation that explains what is collected, how long it is retained (365 days), and how it is used. Users who do not want to provide analytics can opt-out by setting an environment variable ("HOMEBREW_NO_ANALYTICS=1") or by running "brew analytics off".

The project's documentation explains why it collects analytics, and I am sympathetic to the fact that it is a volunteer project that uses the data to try to guide development. Still, it would be better if users were asked about analytics during installation rather than collecting them by default. Even a prompt that defaulted to "yes, take my data please" would be preferable.

All that said, Homebrew's analytics data is publicly available and provides some interesting insights about the use of the project. In particular, the OS versions for events data shows that Linux users make up a larger part of Homebrew's install base than one might expect. Mac users are far and away the majority of Homebrew users. But, in the last year, Ubuntu LTS users accounted for about 12% of the events tracked by Homebrew's analytics. It also shows the relative usage and popularity of various Linux distributions; the 90-day and 30-day views indicate that Bazzite is steadily becoming more popular, having climbed from 0.23% of events in the year view to 1.01% in the last 30 days.

The Homebrew project is fairly mature at this point, so its releases mostly bring modest enhancements and improvements rather than big changes. The significant changes in 5.0.0 that concern Linux users are the promotion of Arm64/Aarch64 packages to Tier 1 support, and turning on concurrent downloads by default. Even though Homebrew is an all-volunteer project, it has well-defined support tiers to help users understand how well things are expected to work on different systems. Each tier describes the combination of operating system, hardware, and Homebrew configuration. For example, the definition of a Tier 1 Linux system only includes Ubuntu releases still within their support window, or a Homebrew Docker image, running on x86_64 or Arm 64-bit systems. Thus, the project would consider Debian, Fedora, or other distributions to be Tier 2.

Tier 1, for instance, receives the highest level of support and test coverage. If a patch or formula fails to build for a Tier 1 system, it is rejected. Tier 2 and Tier 3, of course, have reduced expectations and the maintainers do not commit to fixing bugs or accepting pull requests for these tiers.

The concurrent downloads feature was added in the 4.6.0 release, but was opt-in only. In 5.0.0 it is turned on by default and set to "auto", which sets the number of downloads to twice the number of CPU cores on a system. So, for example, if a system has 16 cores, "brew—install foo" will attempt up to 32 parallel downloads if the operation requires it. This can be faster if a package has many dependencies that also need to be downloaded and installed. The command also displays download progress as each dependency is downloaded; this is not exactly a critical feature, but it's fun to watch.

Homebrewing

If one has a bit of Ruby background or is willing to learn, packaging software for Homebrew is not terribly difficult. The Formula Cookbook explains the package definition format and has plenty of tips for creating formulae. The project also has a good guide for opening pull requests whether one wants to submit a new formula, cask, or make changes to brew itself.

Homebrew is a fairly active project with well-documented governance policies. The project is on Open Collective, and its finances and expenses are visible there. The project is volunteer-run but does provide some stipends to maintainers as well as things like reimbursing for conference travel.

It is by no means a full replacement for distribution package management or repositories, but Homebrew does help fill in the gaps on older systems and image-based systems. It is straightforward to work with as an end user and amateur packager.

Comments (11 posted)

Privilege escalation in LightDM Greeter by KDE (SUSE Security Team Blog)

The SUSE Security Team has published an in-depth article on its findings after reviewing a D-Bus service contained in LightDM Greeter by KDE (the lightdm-kde-greeter package) for addition to openSUSE Tumbleweed. The team found a privilege escalation from the lightdm service user to root, as well as other attack vectors in the service:

In agreement with upstream, we assigned CVE-2025-62876 to track the lightdm service user to root privilege escalation aspect described in this report. The severity of the issue is low, since it only affects defense-in-depth (if the lightdm service user were compromised) and the problematic logic can only be reached and exploited if triggered interactively by a privileged user.

The fixes are contained in the 6.0.4 release of the project.

Comments (none posted)

Rust in Android: move fast and fix things (Google Security Blog)

The Google Security Blog has a new post on just how well the use of Rust is working out for the Android project.

We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android's C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.

Comments (108 posted)

Kernel release status

The current development kernel is 6.18-rc6, released on November 16. Linus said: "So we have a slightly larger rc6 than usual, but I think it's just the random noise and a result of pull request timings rather than due to any issues with the release. But I guess we have a couple of weeks remaining to find out."

Stable updates: 6.17.8 and 6.12.58 were released on November 13.

Comments (none posted)

Quote of the week

Each step took somewhere between 90 minutes and two hours on a total of 1600 CPUs, and all ~11 bisection steps completed without my intervention. Thus far, neither the test grid, the systems, the scripting, nor git bisect have complained about my having wasted their time, but what with AI they probably soon will do so.

— Paul McKenney

Comments (none posted)

Josefsson: Introducing the Debian Libre Live Images

Debian developer Simon Josefsson has announced the Debian Libre Live Images project, to allow installing Debian without any non-free software:

Since the 2022 decision on non-free firmware, the official images for bookworm and trixie contains non-free software.

The Debian Libre Live Images project provides Live ISO images for Intel/AMD-compatible 64-bit x86 CPUs (amd64) built without any non-free software, suitable for running and installing Debian. The images are similar to the Debian Live Images...

He does warn that this is a first public release, so there may be problems. See the current list of known issues before trying the images out.

Comments (25 posted)

Postmortem of the Xubuntu.org download site compromise

In mid-October, the Xubuntu download site was compromised and had directed users to a malicious zip file instead of the Torrent file that users expected. Elizabeth K. Joseph has published a postmortem of the incident, along with plans to avoid such a breach in the future:

To be perfectly clear: this only impacted our website, and the torrent links provided there.

If you downloaded or opened a file named "Xubuntu-Safe-Download.zip" from the Xubuntu downloads page during this period, you should assume it was malicious. We strongly recommend scanning your computer with a trusted antivirus or anti-malware solution and deleting the file immediately.

Nothing on cdimages.ubuntu.com or any of the other official Ubuntu repositories was impacted, and our mirrors remained safe as long as they were also mirroring from official resources.

None of the build systems, packages, or other components of Xubuntu itself were impacted.

Comments (49 posted)

Blender 5.0 released

Version 5.0 of the Blender animation system has been released. Notable improvements include improved color management, HDR capabilities, and a new storyboarding template. See the release notes for a lengthy list of new features and changes, and the bugfixes page for the 588 commits that fixed bugs in Blender 4.5 or older.

Comments (none posted)

Git 2.52.0 released

Version 2.52.0 of the Git source-code management system has been released. Changes include a new last-modified command to find the closest ancestor commit that touched one or more paths, a couple of git refs improvements, a new git repo command for obtaining information about the repository itself, and more. See the announcement and this GitHub blog entry for more information.

Comments (none posted)

GStreamer Conference 2025 video recordings now available

Recordings from the GStreamer Conference 2025, held in London in late October, are now available on the GStreamer Conferences Archive site. Includes the GStreamer State of the Union talk by Tim-Philipp Müller, State of MPEG 2 Transport Stream (MPEG-TS) by Edward Hervey, and many others.

Full Story (comments: none)

Thunderbird 145 released

Version 145 of the Thunderbird email client has been released. Notable changes in this release include enabling DNS over HTTPS, support for Microsoft Exchange via Exchange Web Services, and quite a few bug fixes. As of 145, the project is no longer shipping 32-bit binaries for Linux on x86.

Comments (9 posted)

Development quote of the week

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

— Nick Wellnhofer

Comments (1 posted)

CFP Deadlines: November 20, 2025 to January 19, 2026

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

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

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

Events: November 20, 2025 to January 19, 2026

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

Date(s)	Event	Location
November 18 November 20	Open Source Monitoring Conference	Nuremberg, Germany
November 19 November 20	Open vSwitch OVN Conf'25	Prague, Czech Republic
November 20	NLUUG Autumn Conference 2025	Utrecht, The Netherlands
December 1 December 3	Critical Decentralisation Cluster at 39C3	Hamburg, Germany
December 2 December 4	Yocto Project Virtual Summit 2025.12	Online
December 6	OLF Conference	Columbus, OH, US
December 6 December 7	EmacsConf	online
December 8 December 10	Open Source Summit Japan	Tokyo, Japan
December 8 December 10	Automotive Linux Summit	Tokyo, Japan
December 10 December 11	Open Source Experience 2025	Paris, France
December 11 December 12	Open Compliance Summit	Tokyo, Japan
December 11 December 13	Linux Plumbers Conference	Tokyo, Japan
December 13 December 14	LibreOffice Asia Conference 2025	Tokyo, Japan
December 13 December 15	GNOME Asia Summit 2025	Tokyo, Japan

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

Alert summary November 13, 2025 to November 19, 2025

Dist.	ID	Release	Package	Date
Debian	DSA-6055-1	stable	chromium	2025-11-13
Debian	DLA-4370-1	LTS	firefox-esr	2025-11-13
Debian	DSA-6054-1	stable	firefox-esr	2025-11-12
Debian	DLA-4371-1	LTS	gst-plugins-base1.0	2025-11-14
Debian	DSA-6056-1	stable	keystone	2025-11-13
Debian	DSA-6058-1	stable	lasso	2025-11-15
Debian	DLA-4373-1	LTS	libwebsockets	2025-11-17
Debian	DSA-6057-1	stable	lxd	2025-11-13
Debian	DLA-4374-1	LTS	pdfminer	2025-11-18
Debian	DLA-4372-1	LTS	thunderbird	2025-11-16
Debian	DSA-6059-1	stable	thunderbird	2025-11-16
Fedora	FEDORA-2025-d9f9394ecd	F42	bind9-next	2025-11-16
Fedora	FEDORA-2025-b68f7f541d	F43	bind9-next	2025-11-16
Fedora	FEDORA-2025-7c82e2b870	F41	chromium	2025-11-19
Fedora	FEDORA-2025-c92c2e0d79	F42	chromium	2025-11-18
Fedora	FEDORA-2025-36898b8750	F43	chromium	2025-11-16
Fedora	FEDORA-2025-80ed98504b	F41	containerd	2025-11-15
Fedora	FEDORA-2025-daa6238745	F42	containerd	2025-11-15
Fedora	FEDORA-2025-ffac32ead0	F43	containerd	2025-11-15
Fedora	FEDORA-2025-122a933cad	F41	docker-buildkit	2025-11-14
Fedora	FEDORA-2025-ac008831d6	F42	docker-buildkit	2025-11-14
Fedora	FEDORA-2025-d1dade0612	F43	docker-buildkit	2025-11-14
Fedora	FEDORA-2025-ba7105c612	F41	firefox	2025-11-19
Fedora	FEDORA-2025-457ee8a964	F42	firefox	2025-11-14
Fedora	FEDORA-2025-2d9e01e0fc	F43	firefox	2025-11-13
Fedora	FEDORA-2025-c0d54269e6	F41	fvwm3	2025-11-18
Fedora	FEDORA-2025-f7d7958683	F42	fvwm3	2025-11-18
Fedora	FEDORA-2025-a5cdd30644	F43	fvwm3	2025-11-17
Fedora	FEDORA-2025-6981d97f47	F43	gh	2025-11-14
Fedora	FEDORA-2025-a10fad6506	F42	gitleaks	2025-11-14
Fedora	FEDORA-2025-7e6204e34e	F41	lasso	2025-11-14
Fedora	FEDORA-2025-3edcd991a4	F42	lasso	2025-11-14
Fedora	FEDORA-2025-78747a63cd	F41	luksmeta	2025-11-16
Fedora	FEDORA-2025-457000540a	F42	luksmeta	2025-11-16
Fedora	FEDORA-2025-c555ce4089	F41	opentofu	2025-11-15
Fedora	FEDORA-2025-6ab111452f	F42	opentofu	2025-11-15
Fedora	FEDORA-2025-21b93506d5	F43	opentofu	2025-11-15
Fedora	FEDORA-2025-d019d16668	F41	python-pdfminer	2025-11-17
Fedora	FEDORA-2025-453047be66	F42	python-pdfminer	2025-11-17
Fedora	FEDORA-2025-63872f52bb	F43	python-pdfminer	2025-11-17
Fedora	FEDORA-2025-00e5b3d89c	F41	python-uv-build	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	python-uv-build	2025-11-15
Fedora	FEDORA-2025-a35addbf9b	F41	rubygem-rack	2025-11-13
Fedora	FEDORA-2025-eae2126736	F42	rubygem-rack	2025-11-13
Fedora	FEDORA-2025-b6e0f437b6	F43	rubygem-rack	2025-11-13
Fedora	FEDORA-2025-00e5b3d89c	F41	ruff	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	ruff	2025-11-15
Fedora	FEDORA-2025-6924245627	F41	runc	2025-11-14
Fedora	FEDORA-2025-ef192f5d10	F42	runc	2025-11-14
Fedora	FEDORA-2025-ebd4913540	F43	runc	2025-11-14
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-get-size-derive2	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-get-size-derive2	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-get-size2	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-get-size2	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-regex	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-regex	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-regex-automata	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-regex-automata	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign-aws-v4	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign-aws-v4	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign-command-execute-tokio	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign-command-execute-tokio	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign-core	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign-core	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign-file-read-tokio	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign-file-read-tokio	2025-11-15
Fedora	FEDORA-2025-00e5b3d89c	F41	rust-reqsign-http-send-reqwest	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	rust-reqsign-http-send-reqwest	2025-11-15
Fedora	FEDORA-2025-e49d776723	F41	seamonkey	2025-11-14
Fedora	FEDORA-2025-4eaa870223	F42	seamonkey	2025-11-14
Fedora	FEDORA-2025-5f24a0c1ba	F43	seamonkey	2025-11-14
Fedora	FEDORA-2025-01148de25a	F42	skopeo	2025-11-13
Fedora	FEDORA-2025-0490389cb0	F42	suricata	2025-11-17
Fedora	FEDORA-2025-a366512b23	F43	suricata	2025-11-17
Fedora	FEDORA-2025-00e5b3d89c	F41	uv	2025-11-15
Fedora	FEDORA-2025-e60a4ba4d7	F42	uv	2025-11-15
Fedora	FEDORA-2025-4ffeeb504f	F42	webkitgtk	2025-11-13
Fedora	FEDORA-2025-9d4a8ab586	F41	xmedcon	2025-11-17
Fedora	FEDORA-2025-805b8f571a	F42	xmedcon	2025-11-17
Fedora	FEDORA-2025-977a26e133	F43	xmedcon	2025-11-17
Mageia	MGASA-2025-0301	9	apache	2025-11-18
Mageia	MGASA-2025-0299	9	apache-commons-beanutils	2025-11-15
Mageia	MGASA-2025-0296	9	apache-commons-fileupload	2025-11-15
Mageia	MGASA-2025-0293	9	apache-commons-lang	2025-11-15
Mageia	MGASA-2025-0295	9	botan2	2025-11-15
Mageia	MGASA-2025-0303	9	bubblewrap, flatpak	2025-11-19
Mageia	MGASA-2025-0304	9	cups-filters	2025-11-19
Mageia	MGASA-2025-0300	9	firefox	2025-11-17
Mageia	MGASA-2025-0274	9	perl	2025-11-12
Mageia	MGASA-2025-0285	9	perl-Authen-SASL	2025-11-13
Mageia	MGASA-2025-0276	9	perl-CPAN, perl-HTTP-Tiny	2025-11-12
Mageia	MGASA-2025-0284	9	perl-Cpanel-JSON-XS	2025-11-13
Mageia	MGASA-2025-0287	9	perl-Crypt-OpenSSL-RSA	2025-11-13
Mageia	MGASA-2025-0279	9	perl-Data-Entropy	2025-11-12
Mageia	MGASA-2025-0277	9	perl-FCGI	2025-11-12
Mageia	MGASA-2025-0278	9	perl-File-Find-Rule	2025-11-12
Mageia	MGASA-2025-0283	9	perl-JSON-XS	2025-11-13
Mageia	MGASA-2025-0275	9	perl-YAML-LibYAML	2025-11-12
Mageia	MGASA-2025-0302	9	postgresql13, postgresql15	2025-11-18
Mageia	MGASA-2025-0292	9	python-django	2025-11-15
Mageia	MGASA-2025-0286	9	python-flask-cors	2025-11-13
Mageia	MGASA-2025-0289	9	python-py	2025-11-14
Mageia	MGASA-2025-0288	9	python-setuptools	2025-11-14
Mageia	MGASA-2025-0282	9	python-tornado	2025-11-12
Mageia	MGASA-2025-0281	9	python-urllib3, python-pip	2025-11-12
Mageia	MGASA-2025-0280	9	python3	2025-11-12
Mageia	MGASA-2025-0290	9	ruby	2025-11-14
Mageia	MGASA-2025-0294	9	spdlog	2025-11-15
Mageia	MGASA-2025-0298	9	stardict	2025-11-15
Mageia	MGASA-2025-0305	9	thunderbird	2025-11-19
Mageia	MGASA-2025-0273	9	unbound	2025-11-12
Mageia	MGASA-2025-0291	9	webkit2	2025-11-14
Mageia	MGASA-2025-0297	9	yelp-xsl	2025-11-15
Oracle	ELSA-2025-21232	OL8	container-tools:rhel8	2025-11-19
Oracle	ELSA-2025-21140	OL8	idm:DL1	2025-11-17
Oracle	ELSA-2025-17649	OL7	ipa	2025-11-12
Oracle	ELSA-2025-18814	OL7	java-1.8.0-openjdk	2025-11-13
Oracle	ELSA-2025-19962	OL10	kernel	2025-11-12
Oracle	ELSA-2025-19931	OL8	kernel	2025-11-12
Oracle	ELSA-2025-25757	OL8	kernel	2025-11-12
Oracle	ELSA-2025-21398	OL8	kernel	2025-11-19
Oracle	ELSA-2025-25757	OL9	kernel	2025-11-12
Oracle	ELSA-2025-19930	OL9	kernel	2025-11-12
Oracle	ELSA-2025-25757	OL9	kernel	2025-11-12
Oracle	ELSA-2025-19167	OL7	squid	2025-11-19
Red Hat	RHSA-2025:21034-01	EL10	bind	2025-11-18
Red Hat	RHSA-2025:19912-01	EL10	bind	2025-11-18
Red Hat	RHSA-2025:19835-01	EL8	bind	2025-11-18
Red Hat	RHSA-2025:21110-01	EL9	bind	2025-11-18
Red Hat	RHSA-2025:19951-01	EL9.6	bind	2025-11-18
Red Hat	RHSA-2025:21111-01	EL9	bind9.18	2025-11-18
Red Hat	RHSA-2025:19950-01	EL9	bind9.18	2025-11-18
Red Hat	RHSA-2025:21232-01	EL8	container-tools:rhel8	2025-11-13
Red Hat	RHSA-2025:21281-01	EL10	firefox	2025-11-18
Red Hat	RHSA-2025:21120-01	EL10.0	firefox	2025-11-18
Red Hat	RHSA-2025:21280-01	EL9	firefox	2025-11-18
Red Hat	RHSA-2025:21667-01	EL8.2	kernel	2025-11-19
Red Hat	RHSA-2025:15002-01	EL8.2	krb5	2025-11-13
Red Hat	RHSA-2025:15003-01	EL8.4	krb5	2025-11-13
Red Hat	RHSA-2025:15001-01	EL8.6	krb5	2025-11-13
Red Hat	RHSA-2025:15004-01	EL8.8	krb5	2025-11-13
Red Hat	RHSA-2025:15000-01	EL9.0	krb5	2025-11-13
Red Hat	RHSA-2025:13777-01	EL9.2	krb5	2025-11-13
Red Hat	RHSA-2025:13664-01	EL9.4	krb5	2025-11-13
Red Hat	RHSA-2025:21248-01	EL10	openssl	2025-11-18
Red Hat	RHSA-2025:21255-01	EL9	openssl	2025-11-13
Red Hat	RHSA-2025:21562-01	EL9.4	openssl	2025-11-18
Red Hat	RHSA-2025:21174-01	EL9.6	openssl	2025-11-13
Red Hat	RHSA-2025:21036-01	EL10	pcs	2025-11-13
Red Hat	RHSA-2025:19948-01	EL8.4	pcs	2025-11-13
Red Hat	RHSA-2025:20962-01	EL9	pcs	2025-11-13
Red Hat	RHSA-2025:21220-01	EL10	podman	2025-11-13
Red Hat	RHSA-2025:20957-01	EL9	runc	2025-11-13
Red Hat	RHSA-2025:19927-01	EL9	runc	2025-11-13
Slackware	SSA:2025-322-01		libarchive	2025-11-18
Slackware	SSA:2025-316-01		mozilla	2025-11-12
Slackware	SSA:2025-319-01		xpdf	2025-11-15
SUSE	SUSE-SU-2025:4121-1	SLE15	alloy	2025-11-17
SUSE	SUSE-SU-2025:4107-1	MP4.3 SLE15 oS15.4	bind	2025-11-14
SUSE	SUSE-SU-2025:4109-1	SLE15 SES7.1 oS15.3	bind	2025-11-14
SUSE	SUSE-SU-2025:4108-1	SLE15 SLE-m5.5 oS15.5	bind	2025-11-14
SUSE	SUSE-SU-2025:4110-1	SLE15 oS15.6	bind	2025-11-14
SUSE	SUSE-SU-2025:4096-1	MP4.3 SLE15 SES7.1 oS15.3 oS15.4 oS15.5 oS15.6	binutils	2025-11-14
SUSE	openSUSE-SU-2025:15725-1	TW	binutils	2025-11-12
SUSE	SUSE-SU-2025:4091-1	oS15.6	cargo-packaging, rust-bindgen	2025-11-13
SUSE	openSUSE-SU-2025:15736-1	TW	chromedriver	2025-11-15
SUSE	openSUSE-SU-2025:0430-1	osB15	chromium	2025-11-14
SUSE	openSUSE-SU-2025:15735-1	TW	firefox	2025-11-15
SUSE	SUSE-SU-2025:4125-1	SLE12	ghostscript	2025-11-18
SUSE	SUSE-SU-2025:4137-1	SLE15 oS15.4 oS15.6	gimp	2025-11-19
SUSE	openSUSE-SU-2025:15729-1	TW	go-sendxmpp	2025-11-13
SUSE	openSUSE-SU-2025:15730-1	TW	helm	2025-11-13
SUSE	openSUSE-SU-2025:15739-1	TW	itextpdf	2025-11-18
SUSE	SUSE-SU-2025:4111-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2025-11-17
SUSE	SUSE-SU-2025:4135-1	SLE-m5.2	kernel	2025-11-18
SUSE	SUSE-SU-2025:4132-1	SLE15	kernel	2025-11-18
SUSE	SUSE-SU-2025:4128-1	SLE15 oS15.6	kernel	2025-11-18
SUSE	SUSE-SU-2025:20996-1	SLE16 SLE-m6.2 oS16.0	kernel	2025-11-12
SUSE	SUSE-SU-2025:20994-1	SLE16 SLE-m6.2 oS16.0	kernel	2025-11-12
SUSE	SUSE-SU-2025:4090-1	MP4.3 SLE15 SES7.1	lasso	2025-11-13
SUSE	SUSE-SU-2025:4094-1	SLE12	lasso	2025-11-14
SUSE	SUSE-SU-2025:4115-1	SLE-m5.2 oS15.6	libxml2	2025-11-17
SUSE	SUSE-SU-2025:4116-1	SLE-m5.3 SLE-m5.4 oS15.4	libxml2	2025-11-17
SUSE	SUSE-SU-2025:4104-1	SLE12	libxml2	2025-11-14
SUSE	SUSE-SU-2025:4087-1	SLE15 oS15.6	netty, netty-tcnative	2025-11-12
SUSE	SUSE-SU-2025:4112-1	MP4.3 SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.3	openssh	2025-11-17
SUSE	SUSE-SU-2025:4097-1	SLE12	openssh	2025-11-14
SUSE	SUSE-SU-2025:4098-1	SLE12	openssh8.4	2025-11-14
SUSE	SUSE-SU-2025:4126-1	SLE15 SES7.1 oS15.6	openssl-1_0_0	2025-11-18
SUSE	SUSE-SU-2025:4080-1	SLE15 SLE-m5.1 SLE-m5.2 SES7.1 oS15.3	podman	2025-11-12
SUSE	SUSE-SU-2025:4079-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	podman	2025-11-12
SUSE	SUSE-SU-2025:4081-1	SLE15 SLE-m5.5 oS15.5 oS15.6	podman	2025-11-12
SUSE	SUSE-SU-2025:4100-1	SLE15 oS15.6	python-Django	2025-11-14
SUSE	openSUSE-SU-2025:15732-1	TW	python-Scrapy-doc	2025-11-13
SUSE	openSUSE-SU-2025:15731-1	TW	python311-Brotli	2025-11-13
SUSE	openSUSE-SU-2025:15727-1	TW	python311-pdfminer	2025-11-12
SUSE	SUSE-SU-2025:4099-1	SLE12	squid	2025-11-14
SUSE	openSUSE-SU-2025:15738-1	TW	thunderbird	2025-11-18
SUSE	SUSE-SU-2025:4103-1	SLE15 oS15.6	tomcat10	2025-11-14
SUSE	SUSE-SU-2025:4086-1	SLE15 oS15.6	tomcat11	2025-11-12
SUSE	SUSE-SU-2025:4134-1	SLE15 oS15.6	unbound	2025-11-18
SUSE	openSUSE-SU-2025:15733-1	TW	weblate	2025-11-13
Ubuntu	USN-7836-2	20.04	bind9	2025-11-12
Ubuntu	USN-7871-1	25.04 25.10	ffmpeg	2025-11-17
Ubuntu	USN-7870-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04 25.10	freeglut	2025-11-18
Ubuntu	USN-7872-1	22.04 24.04 25.04	lasso	2025-11-18
Ubuntu	USN-7835-6	22.04	linux-aws-6.8	2025-11-12
Ubuntu	USN-7861-3	22.04 24.04	linux-nvidia-6.8, linux-oracle, linux-oracle-6.8	2025-11-13
Ubuntu	USN-7862-3	22.04	linux-xilinx-zynqmp	2025-11-13

Full Story (comments: none)