Welcome to the LWN.net Weekly Edition for February 29, 2024

This edition contains the following feature content:

• The KDE desktop gets an overhaul with Plasma 6: the new KDE release contains many small improvements; Wayland becomes the default graphical session.
• A look at Nix and Guix: two unusual package managers permit defining Linux systems declaratively.
• Forgejo makes a full break from Gitea: the Forgejo project becomes a "hard" fork of Gitea.
• When ELF notes reveal too much: a section of the kernel's ELF binary has frustrated KASLR since its introduction.
• A RDRAND followup: CPU vendors clarify the behavior of RDRAND and RDSEED, prompting more discussion of their use in the kernel.
• Treating documentation as code: the "Tool the docs" FOSDEM 2024 devroom featured several tools and suggestions for improving documentation using lessons learned from source code.

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)

The KDE desktop gets an overhaul with Plasma 6

It's been nearly 10 years since KDE Plasma 5, which is the last major release of the desktop. On February 28 the project announced its "mega release" of KDE Plasma 6, KDE Frameworks 6, and KDE Gear 24.02 — all based on the Qt 6 development framework. This release focuses heavily on migrating to Wayland, and aspires to be a seamless upgrade for the user while improving performance, security, and support for newer hardware. For developers, a lot of work has gone into removing deprecated frameworks and decreasing dependencies to make it easier to write applications targeting KDE.

What's in Plasma 6

For the purpose of this article, we'll mostly look at Plasma and Frameworks, as Gear 24.02 contains too many applications like KMail, Kate, and the Kdenlive video editor that deserve more attention in their own right. I ran Fedora Kinoite's nightly releases with pre-release Plasma 6 packages, which has proved pleasantly stable and performant on an aging ThinkPad X280 with 16GB of RAM and a Core i7-8650U CPU.

The difference between Plasma 5 and 6 is apparent, but not pronounced. Users who are comfortable with Plasma 5 are unlikely to feel discomfited with Plasma 6, or have a hard time adapting to the changes sprinkled throughout the desktop. Plasma 6 has a number of changes to default settings. The big change, of course, is Wayland as the default graphical session.

Plasma 6 also has a smattering of smaller, less controversial changes. For example, prior to Plasma 6, the desktop defaulted to single-click to open a folder, launch a program, or open a file. Users coming from other operating systems or Linux desktop environments are often used to double-clicking to do these things. Now, KDE upstream has relented on using a single-click to open files and defaults to double-click instead. Distributions like Fedora, Kubuntu, and Manjaro had been changing the upstream default anyway, so KDE developer Nate Graham suggested disabling the feature. "Distros are closer to users and clearly the feedback they've been getting is that double-click is a better default...Let's admit it and switch to double-click by default ourselves".

Plasma 6 is also supposed to do away with the default of using the scroll wheel on the desktop to switch virtual desktops. However, this setting is still active in Fedora Kinoite as of this writing. Scrolling to switch virtual desktops has been the default for some time, but Graham argued in another proposal to disable the feature because it can easily surprise users with unexpected and unwanted behavior. Users who prefer the old behavior can toggle it back on in the "Mouse Actions" settings under "Desktop Folder Settings", so it's not going away entirely. Another change to scrolling behavior in this release is that clicking on a scrollbar moves the window to the location clicked, rather than one "page" at a time. This is meant to reduce the amount of fiddling with the scroll wheel to move up or down a long "distance", in order to be a better option for users with repetitive strain injuries (RSIs) — or for users who'd like to avoid RSIs in the first place.

Breeze is Plasma's default theme and it has been updated for Plasma 6, but it's a subtle change — sort of like repainting a room and changing the color from "flat white" to "eggshell white". It has some changes to spacing that make it feel a little less crowded, and it has fewer lines separating UI elements. The System Settings application has also been revamped. This may be more noticeable, as some of the settings have migrated to new locations. The nice thing about KDE is that so much is configurable, but finding configuration settings is still a challenge in Plasma 6. For example, the aforementioned setting to scroll virtual desktops is found in the Desktop Folder Settings application, but not in the System Settings application under the Virtual Desktop settings.

Dolphin, KDE's file manager, had its configuration settings redesigned to make them easier to navigate. The prior version of Dolphin included six tabs of settings for navigation, its context menu, startup behavior, view modes, behavior of the trash, and general settings. The redesign condenses this into four tabs, scooting the navigation options and startup options into the new interface tab. It also adds a fifth tab for user feedback, with options to contribute statistics and participate in surveys. These are, as one would expect from an open-source project that respects its users, set to share no data by default. Users who wish to participate, though, can choose just how much participation they're willing to engage in. This ranges from sharing just a few details like version of the application and operating system, to more telemetry like screen resolution, time Dolphin is used, how many network shares are available, and more.

The Dolphin interface changes are minor. Instead of showing recent files from today and yesterday, Dolphin now shows recent files and recent locations. Settings for file history are system-wide, and found in System Settings rather than Dolphin's settings — users can opt for keeping history "forever" or a period of months, or turn off history entirely. (Days or hours do not appear to be an option.) Users can also specify the applications allowed to access file history, rather than granting access to any application.

Plasma 6 on Wayland has some support for high dynamic range (HDR) and color management, depending on the application and if one has a supported monitor. Sadly, the monitors I have on hand are not supported. One thing that did work nicely, however, was setting the scaling for a laptop monitor and external monitor, independently. It was easy to set the external monitor to 100% scaling while the ThinkPad screen was set to 125% so that windows appeared to be the same size when moved from one monitor to the other.

The Plasma Search feature, which is part of KRunner and the Kickoff application launcher, has been refactored and is claimed to be much faster in this release. The release announcement claimed major speedups for searching local documents and for applications, while reducing CPU usage. It's hard to verify this, but KRunner did feel snappy when performing web and document searches. Spectacle, KDE's screenshot utility, now takes screenshots and recordings of the entire desktop, an application window, or just a selection of the screen. This promises to be a handy tool to create tutorials, or share a recording of application behavior when filing a bug.

KDE giveth, and KDE taketh away. As is common with major updates, some features and settings have been removed due to design changes or difficulty with underlying drivers or software. For example, GUI configuration for Synaptics touchpads and evdev input devices has been removed because the drivers have been superseded with libinput in Wayland. Unmaintained features like the Air theme, icon view for System Settings, and KHotkeys were all scuttled in this release. The ability to grab wallpapers from the Unsplash free stock image site was removed due to API changes and the QuickShare applet for file transfer was dropped because it never worked as intended.

Under the hood

Even though Plasma 6 may not feel like a major update, a lot of work has gone into KDE Frameworks 6 to make it possible. I asked KDE developer Carl Schwan by email about the developer-facing changes and plans for KDE 5 now that Plasma 6 has been released. Schwan said most of the work in Frameworks 6 was about reducing rather than adding features. Schwan pointed to removal of deprecated frameworks, like KHtml, the KJS javascript engine, and KHotkeys. The project has also worked to get rid of deprecated Qt APIs, such as QtCodecs, and to decrease dependencies between frameworks so external Qt applications can just use one or two KDE frameworks. Schwan also said that KDE has removed a lot of APIs "which were barely used or [...] have better alternatives either in another framework or in Qt itself". In particular, he noted that KDE's plugin system has moved from two APIs to a single API.

Schwan said that Qt 6 itself didn't have many API changes, but it did add an abstraction layer for graphics APIs like Metal, Vulkan, OpenGL, and DirectX "instead of only supporting OpenGL+Angle". In addition, Qt has switched to CMake, away from the qmake build system, which Schwan said helped a lot to improve developer tooling. Finally, Qt 6 brought a number of improvements to Qt Wayland, which Schwan said had been driven forward in part by KDE developers.

Support for KDE 5 and X11

Plasma 6 is likely to be a little bit rough around the edges for a while, and users might want to review known issues before deciding to upgrade. Obviously Plasma 6 won't be immediately available in most distributions, but users can refer to KDE's community wiki for instructions on how to test Plasma 6 right away. Users can choose to build from source, try the KDE neon testing edition, or try one of the other distribution-specific methods for Fedora, Gentoo, KaOS, NixOS, or openSUSE.

There is no rush to switch — KDE 5 is not quite out of the picture just yet. On February 12, on the Plasma development list, David Edmundson said he'd seen enough patches that should go into 5.27 to warrant another release. Justin Zobel agreed and noted that "many distros won't [adopt] it for some time. Major bugfixes and security fixes should definitely continue being applied until such time that most major distros have updated to 6". Valorie Zimmerman, from the Kubuntu project, said this is good news since the next long-term support (LTS) release for Kubuntu is coming in March and won't be based on Qt 6. On February 19, Jonathan Riddell reported the Plasma team planned to do a Plasma 5.27.11 release on March 6.

Even though many in the Fedora project are eager to drop X11 support, KDE upstream plans to continue including X11 support for users who depend on it in the short term. Users can expect to see support in Plasma 6 as well, but Schwan says there's "no fixed timeline" with various estimates ranging from two to five years before support is fully removed. He stressed that there will be "plenty of communication beforehand" and the project "certainly won't drop the support from one day to the other".

Overall, Plasma 6 looks to be a smooth upgrade for users, and KDE Frameworks 6 seems to be a solid foundation for the next few years of KDE development. It should be interesting to watch how Plasma evolves over the next few years.

Comments (12 posted)

A look at Nix and Guix

Nix and Guix are a pair of unusual package managers based on the idea of declarative configurations. Their associated Linux distributions — NixOS and the Guix System — take the idea further by allowing users to define a single centralized configuration describing the state of the entire system. Both have been previously mentioned on LWN, but not covered extensively. They offer different takes on the central idea of treating packages like immutable values.

In a normal Linux distribution, the set of packages, services, and configuration files installed on a system is built up over time using tools that do not inherently require knowledge of programming. This approach can be convenient, making it possible to simply install a missing package and then have access to it going forward. The downside of this approach is how difficult it makes reconstructing a new system with the same set of tools, services, and tweaks when it comes time to migrate to a new host. The majority of Linux distributions lack any kind of centralized record of why each package was installed or each configuration option was changed.

NixOS and Guix offer an alternative: specify your setup with a programmable configuration file, and then let the package manager arrange for the software available on the system to reflect that. These configurations can include comments, version control, and the ability to factor out common parts for different machines, making it much easier to keep track of why something was configured or installed.

The key idea

Nix is a "purely functional package manager". Unlike other package managers, Nix uses a general programming language of the same name for configuration, albeit one optimized for the task of describing packages. The Nix language takes inspiration from the ML family of languages, Haskell in particular. Like Haskell, Nix programs work with and produce immutable values through composing functions (the "functional" part) that don't have side-effects (the "pure" part). Evaluating a Nix program produces a set of build actions for the runtime of the package manager to take, but does not itself build or install anything. Nix is also lazy, calculating only the information about the produced values that actually ends up being required. This lets Nix programs skip performing computations for optional dependencies that don't end up being used.

Each Nix program describes a "derivation" — "a specification for running an executable on precisely defined input files to repeatably produce output files at uniquely determined file system paths." Derivations describe a specific build task to perform, including all of the necessary inputs to the build task in the form of required dependencies, build tools, source code, etc. Nix doesn't permit implicit dependencies between build tasks, requiring all prerequisites to be specified explicitly.

The benefit of using this model is that the full state of the system is specified in the same place, using the same language. The configuration not only includes the installed packages, but also the configuration files destined for /etc, the systemd service files, the filesystem mounts, users, kernel configuration options, drivers, etc. For example, here is a configuration module for running nginx, which builds nginx, sets up its configuration files, sets up a systemd service for nginx itself, and creates systemd timers for renewing HTTPS certificates with LetsEncrypt:

    # This whole file evaluates to a single function from a set of
    # arguments (config, lib, and pkgs are normally used, but there
    # can be more which are ignored, thus "...") to a set of configuration
    # values that themselves are used in calculating the build action for
    # the overall system.
    { config, lib, pkgs, ... }:

    {
      # ACME is the protocol that LetsEncrypt uses to give out certificates
      security.acme.acceptTerms = true;
      security.acme.defaults.email = "example@example.com";

      services.nginx = {
        enable = true;

        # Options can enable a bundle of related, more detailed settings
        recommendedTlsSettings = true;
        recommendedOptimisation = true;
        recommendedGzipSettings = true;
        recommendedProxySettings = true;
      };

      # nginx can serve multiple virtual hosts with their own configurations
      services.nginx.virtualHosts."www.example.com" = {
        http2 = true;
        enableACME = true;
        forceSSL = true;

        locations."/" = { root = "/var/www/example.com"; };
      };
    }

The code that actually implements these options is defined in nixpkgs, NixOS's package repository, in the same language as the rest of the configuration. Becoming truly proficient in Nix can take some time, but most configurations are relatively straightforward, and the NixOS manual provides examples of common setups. The options search or nix search command-line tool also let users search for configuration options and available packages.

Derivations are nearly all reproducible, with the same inputs generating the same outputs. Some packages still include randomness or information about the timing of the build, which foil reproducibility. Work is ongoing to patch these packages to reach the project's goal of fully reproducible builds. Combined with the fact that derivations record all of the inputs to the build process, this reproducibility allows the result of derivations to be cached. Nix keeps the cache of previously evaluated derivations under /nix/store/, indexed by the hash of the derivation's inputs.

Nixpkgs contains definitions for more than 80,000 packages. These packages are built, cached, and shared by Hydra, NixOS's build farm. So, despite the fact that a NixOS configuration describes how to obtain and build all of the selected software from scratch, if a user depends on the package definitions in nixpkgs, they are likely to be able to download a cached output for the derivation from Hydra. NixOS refers to itself as a mixed source/binary distribution because of this — users can build software from scratch (including tuning the build flags for their system, as can be done by Gentoo users), but most users just download binary versions of most of their packages, and know that they're getting the same result as having built from scratch.

Multiple versions

Another benefit of arranging for the system to be built in this way is the ability to depend on multiple versions of the same package. Because each derivation references its build inputs explicitly, there is no requirement that a single global version of a compiler or shared library exist that satisfies every dependent package's needs simultaneously. This makes it easier to keep older software with specific needs running, decreases the burden of updating every package in the ecosystem at once when there's a major update to a common dependency, and means that maintainers don't need to solve version conflicts. It is a bit of a double-edged sword, however, because it does mean that it is easy to depend on several versions of a package without meaning to, which can bloat the size of a NixOS installation.

Being able to keep multiple versions of packages actually extends to being able to keep multiple versions of the system's entire configuration. When re-building a system using Nix, the derivation of the previous configuration remains available, and can be switched to using the bootloader. Users can therefore upgrade fearlessly, because any problems introduced by trying a new configuration can be resolved by rebooting. By the same token, software that is only needed for a short time, such as to try out a new program or grab a seldom-used command-line tool, can be installed into a temporary environment without interfering with the overall system configuration.

It is difficult to overstate how useful this ability is in practice. It is often possible to put a Linux system into an unworkable state by doing something unusual. While a lot can be learned from troubleshooting these issues, it is inconvenient when what is needed is a functional system.

Referring to dependencies directly, the way NixOS does, causes problems with software not packaged for use on the distribution. Unlike a typical distribution, NixOS only uses /usr/bin for env, to permit running shell scripts that start with #!/usr/bin/env. Shell scripts or other programs that assume that system binaries will be available in /usr/bin or other standard locations usually need to be adapted to run on NixOS. There are some tools available to make a chroot environment that puts binaries in the expected places, however, so this is usually not much of a hassle.

Guix

The Nix approach to package management has its benefits, but the Nix language also has its quirks. Learning to use a new programming language on top of a new package-management philosophy may seem like a tall order. The Guix project is working to create a distribution that uses Nix-style package management, but using a more widely used, general, and consistent programming language: Scheme. Guix is a GNU project, and so it only packages free software (in contrast to Nix, which packages non-free software behind a configuration option). It also has many fewer contributors than Nix, and is somewhat younger as a project — Guix received its first commit in 2012, whereas Nix dates to 2003 — so the number of packages available in Guix is somewhat lower.

Despite this, Guix has made several interesting advances of its own, including fully bootstrappable builds. Guix is now capable of building itself almost entirely from source on x86_64, a major milestone for the project. Ekaitz Zárraga gave a talk at FOSDEM 2024 about extending that support to RISC-V. Guix also has some features that NixOS lacks, such as the ability to "graft" security updates onto a package. This lets a more up-to-date version of a runtime dependency of a package be substituted in (presumably to fix some security problem) without recompiling the dependent package. This permits rolling out security updates to fundamental libraries without waiting for the build farm to rebuild all of Guix's packages.

A section of a Guix configuration comparable to the Nix configuration given above would look like:

    ; Guix defines types and helper functions in their own Scheme modules
    (require (gnu services web)
             (gnu services certbot))

    ; This hook sends a signal to nginx to make it re-load its configuration,
    ; including the updated HTTPS certificates
    (define %nginx-deploy-hook
      (program-file
       "nginx-deploy-hook"
       #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read)))
           (kill pid SIGHUP))))

    (define %my-nginx-service
      (service nginx-service-type
         (nginx-configuration
           (server-blocks
             (list (nginx-server-configuration
                     (server-name '("www.example.com"))
                     (root "/srv/http/www.example.com")
                     (ssl-certificate
                       "/etc/letsencrypt/live/www.example.com/fullchain.pem")
                     (ssl-certificate-key
                       "/etc/letsencrypt/live/www.example.com/privkey.pem")))))))

    (define %my-certbot-service
      (service certbot-service-type
               (certbot-configuration
                (email "example@example.com")
                (certificates
                 (list
                  (certificate-configuration
                   (domains '("www.example.com"))
                   (deploy-hook %nginx-deploy-hook)))))))

This configuration has a few differences. For one thing, Guix uses GNU Shepherd as an init system, instead of systemd. For another, the code shown here is not a standalone file that is imported by the main configuration file. Instead, the user would need to import this file and then add %my-nginx-service and %my-certbot-service to the services list for their system configuration by hand.

Experimenting

Nix and Guix (the package managers) both work on other distributions. Some distributions, such as Ubuntu and Debian, provide packages for them. For users of other distributions, Nix provides installation instructions and uninstallation instructions. Guix only provides installation instructions, but maintainer Tobias Geerinckx-Rice helpfully notes that one can read the installer script to see what ought to be removed.

In either case, using the package managers on another distribution can be useful for creating temporary environments, even if they cannot provide whole-system configuration. Individual programming languages often provide a solution for temporary development environments (for example, Python's virtual environments). Many projects are now shipping a shell.nix file as a language-agnostic alternative, which can install dependencies not packaged by the language's package manager. Somewhat fewer ship a guix.scm file serving the same purpose, but several GNU projects do.

NixOS and Guix offer a compelling alternatives to traditional distributions by rethinking how package management can be done. Their design permits incredible flexibility, simplifying package management for distribution maintainers and giving users additional control over how their computers are configured, without sacrificing binary packaging. Despite this, it seems unlikely that either will replace traditional package managers, especially when other distributions are receiving some of the same benefits of reproducibility using other techniques.

Comments (23 posted)

Forgejo makes a full break from Gitea

The world of open-source "forges" is becoming a little more fragmented. The Forgejo project is a software-development platform that started as a "soft" fork of Gitea in late 2022. On February 16, Forgejo announced its intent to become a "hard fork" of Gitea to continue its stated objectives of community-controlled development and to "liberate software development from the shackles of proprietary tools". In a world where proprietary tools cast a long shadow over open-source development those are welcome words—if the project can deliver.

Gitea was (and is) a popular open-source Git hosting and collaboration platform. Gitea itself is a fork of Gogs that started in December 2016 due to frustration with the "single-maintainer management model of Gogs" and opted for a "more open and faster development model". Originally the project's governance, spelled out in an earlier version of its CONTRIBUTING.md file, specified the project would have three "owners" responsible for keeping development "healthy". The actual responsibilities and rights of the owners were vague, but they were to be elected yearly by Gitea's maintainers "who decide with a simple voting model which contributions get accepted and who will play the owner role".

That community of maintainers did not get a vote when Gitea's domain and trademarks were quietly transferred by two of Gitea's "owners" (Lunny Xiao and Matti Ranta) to a for-profit business called Gitea Ltd. The announcement said this was to meet the goal of "ensuring the long term success of the project" by allowing companies "unable to contribute back to open source via sponsorship or code contribution" to support Gitea in the form of paying Gitea Ltd directly. In addition, the company would "act as a steward" of the project, which would "of course remain open source, and a community project". To date, the company seems to have remained good to its word about Gitea itself remaining open source. It has launched a hosted cloud offering with features not available in the self-hosted version, but the self-hosted version of Gitea otherwise remains open-source. The "enhanced" enterprise version hinted at in the announcement, which one would expect to be open-core, has yet to appear.

Unsurprisingly, members of the Gitea community objected. They published an open letter on October 25, 2022 (with running updates afterward above the letter) and asked Gitea owners to, instead, form a non-profit that would hold the domain and trademarks. Once it was made clear that would not happen, the community announced it would create a soft fork of Gitea to "keep the Gitea community united". The Forgejo project was announced on December 15, 2022 under the auspices of Codeberg e.V., a non-profit based in Berlin, Germany that provides the Codeberg collaboration platform.

The name Forgejo, for those who wonder, is taken from the Esperanto word for forge, forĝejo. Having learned from earlier mistakes, the community arranged for the Forgejo domains to be held by Codeberg e.V., and the project has a detailed set of documents about various aspects of project governance, such as decision-making, branding, merging pull requests, its mission, teams, and how money is handled. While Gitea still uses GitHub for development, Forgejo has been developed on the Codeberg platform and is now the underlying software for Codeberg.

Why now?

Since its launch in December 2022, Forgejo has followed Gitea development as a set of commits on top of the Gitea development branch—doing work in feature branches and rebasing on top of Gitea periodically. In early January, Forgejo contributor Earl Warren started a discussion to change Forgejo's development workflow and "become independent and cherry-pick from the Gitea codebase until the divergences are too great and that becomes impossible". Warren argued that the existing workflow no longer made sense because Gitea "merges very large untested code (feature or refactor) that have been the cause of major regressions with high impact on users". He also argued that a simpler workflow would improve stability and make it easier for contributors with a single development branch versus multiple feature branches. Warren also claimed that Gitea had "turned Open Core" and took issue with its "security behavior" without elaborating.

Following the discussion, Warren put forward a proposal on January 14 to change Forgejo's workflow after its next major release or March 1, "whichever comes first". In that proposal he also argued that Forgejo has the funding, resources, and governance to operate independently, and that the change "would not hinder a cooperation that does not exist". While Forgejo had consumed Gitea's work, Warren wrote that Gitea contributors "never cherry-picked a commit from Forgejo". Warren, at least, has submitted a number of contributions to Gitea based on work from Forgejo.

What does it mean, exactly, to be a hard fork rather than a soft fork? In its February 16 announcement, the Forgejo project explained that being a soft fork meant Forgejo contains "all of Gitea, both good and bad", so users could move from Gitea to Forgejo as a drop-in replacement. Those days are not over, yet, but the end is in sight. Users planning to move from Gitea to Forgejo should do so "sooner rather than later" because "eventually, Forgejo will stop being a drop-in replacement". Forgejo does intend to remain compatible with the Gitea API, at least as it exists today. The announcement says that any changes to the API will be evaluated carefully, and that Forgejo will try to remain compatible with Gitea—though contributors may use their own judgment whether or not to implement new APIs. The announcement noted that parts of Forgejo have already diverged, such as documentation, localization, and the Forgejo Actions continuous-integration system.

What now?

Gitea Ltd hasn't addressed Forgejo's announcement directly. It did, however, put out a blog post (just ahead of the Forgejo "hard fork" announcement that was planned in the open) on February 14 for the Free Software Foundation Europe (FSFE)'s "I Love Free Software Day". That post noted several organizations "using Gitea to build Free or otherwise Open Source software", including FSFE, the Blender Foundation, openSUSE, and others.

Both projects seem to have enough momentum to carry forward, though it's fair to speculate whether there's enough interest by users, contributors, and customers to sustain both indefinitely. Gogs, for example, doesn't appear to have thrived since the Gitea fork. The Gogs repository on GitHub shows recent activity, but Gogs's last release was on February 25, 2023—almost a year ago as of this writing. The demo linked from its homepage errors out, and the newsletter link on the homepage leads to a 404 instead of current news about the project.

Given Forgejo's backing (and use) by Codeberg e.V., it seems likely to remain viable over the long haul. Codeberg, as a platform, has attracted a respectable following with more than 117,000 projects and 95,000 users. Respectable, but a tiny sample compared to GitHub's millions of projects and users. Unless there's a mass exodus from Gitea to Forgejo, it also seems that Gitea will continue at about the same pace. Gitea boasted that it had hit 40,000 stars on GitHub in January of this year, a metric that it claimed is demonstrative of Gitea's "significance in empowering developers worldwide" as well as "the trust and confidence the global developer community places in Gitea". There's more than a touch of irony in citing success on a platform you ostensibly seek to replace.

In theory, sites using the ForgeFed protocol could help displace proprietary alternatives by making it easier to collaborate between software forges. If it's ever actually implemented, that is. The ForgeFed protocol is an ActivityPub extension for allowing software forges to interact without users needing to create accounts on every forge. In a post about federation from early 2023, the Forgejo project paints a lovely picture of an open ecosystem that challenges GitHub:

[GitHub is] a textbook example of a walled garden. We want to create something similar [to GitHub], but in an open ecosystem where everything speaks the ForgeFed protocol, so you're never locked-in by which forge or code collaboration software that you use.

In practice, federation is probably years away from implementation or adoption. The post suggested that federation was likely to be included in the 1.19 release, and claimed that Forgejo intended to contribute federation upstream to Gitea. However, federation did not appear in 1.19 and the issue tracking federation implementation in Forgejo indicates much left to be done. The ForgeFed site lists only one project, called Vervis, with a working implementation, but that project does not seem ready for real-world usage just yet.

Gitea and Forgejo are trying to solve the same problem—providing a self-hosted open-source software development platform that can provide all the features developers need and want. Gitea has opted to abandon real community governance to try to sustain development by offering commercial support, with a willingness to work on top of proprietary platforms and entertain non-open offerings. Forgejo has opted for the other road, rejecting proprietary tools and trying to establish a community-led, non-profit approach to sustaining itself.

Both paths have many challenges and obstacles. Gitea and Forgejo are likely to be competing for the same users, contributors, and mind share. It will be interesting to look back in a year or three and see how successful they've been, and how much impact they've had in moving open-source developers away from proprietary platforms.

Comments (21 posted)

When ELF notes reveal too much

The Linux kernel uses a number of hardening techniques to try to protect itself against compromise; one of those is kernel address-space layout randomization (KASLR). But randomization is of little benefit if the kernel spills the beans on where its code has ended up. As it happens, the kernel has been doing exactly that — since 2007, in a behavior that predates the addition of KASLR. Some changes are in the works to close that hole, but it is illustrative of just how hard some secrets are to keep.

Exploits of the kernel (as with any other program) often rely on jumping into specific code in unexpected ways. Numerous techniques have been developed to prevent this from happening; control-flow integrity mechanisms, for example, exist to prevent execution from being diverted from the intended paths. Other techniques, though, try to make it difficult for an attacker to know where to redirect the control flow to, even if they find a bug that would allow that sort of compromise. KASLR is one of those techniques, built on the observation that, if an attacker does not know where the kernel has been placed in its address space, they cannot redirect control flow to a known location.

The idea behind KASLR is simple enough: at boot time, the actual location for the kernel in memory is chosen randomly. The offset chosen for each boot is different, so an attacker does not know, at the outset, where the kernel lives on any given target machine. If the kernel takes pains not to tell the attacker about its location, it creates an added barrier to successfully exploiting any vulnerability that might exist.

KASLR was first added to the kernel (for the x86 architecture) during the 3.14 development cycle in 2013. Randomizing the kernel's layout, though, has turned out to be the easy part of the job; the harder part is preventing the kernel from leaking information about its location and making the whole effort useless. There was, for example, a lot of kernel code that would happily encode kernel pointer values in printk() calls. After a fair amount of work, that problem was mostly resolved by fixing kernel code to use special formatting directives for pointers and refusing to output actual pointer values to the log unless kptr_restrict is set accordingly. Various other /proc and sysfs files were also redacted as needed. Over time, learning about the kernel's location on any given system has become harder; whether it is hard enough to effectively slow down a capable attacker is still a matter of dispute.

The problem is that there are a lot of information channels between the kernel and user space, and any one of them might turn out to be leaking information that reveals the kernel's location. Consider, for example, the relatively obscure sysfs file /sys/kernel/notes. This file is documented rather tersely as containing "the binary representation of the running vmlinux's .notes section". That section, part of the ELF file containing the kernel image, contains useful information about the image itself; any kernel code can add data to this section using the ELFNOTE() macro. Anything placed there can be read from /sys/kernel/notes, albeit in a binary format that goes rather against the usual "one value per file" sysfs rule.

The most common use for this file is to store a version of the kernel's version number, but there is at least one other. Guixiong Wei recently noticed that this file contained potentially sensitive information, including the location of the startup_xen symbol; that information is enough for an attacker to defeat KASLR. That is particularly problematic because this file is world-readable, so that information is made available to an unprivileged attacker. Wei posted a patch restricting readability to the root account, closing the hole somewhat. As of this writing, that patch has not found its way to the mainline, though that can be expected to happen in the near future.

Kees Cook, who got much of the KASLR work into the kernel (built on work by others that had been underway for a while), confirmed that the result was a KASLR exposure that had been in place since 2007, long before KASLR itself was added. He welcomed the permissions change, but also asked whether addresses in /sys/kernel/notes needed boot-time relocation at all; the answer from Xen developer Jürgen Groß was that Xen, at least, does not need that relocation to happen. In other words, the address that appears in /sys/kernel/notes does not need to be adjusted to reflect the randomized offset chosen at boot time. So we may see further changes to this sysfs file in the future, though it is always hard to know that such changes can be made without breaking some user-space program somewhere.

As this episode suggests, finding kernel code that leaks addresses to user space is a bit of a game of whack-a-mole, except in this case one of the moles has managed to remain standing for 11 years after its presence was made unwelcome. There is a tool that is meant to help in the detection of moles in need of whacking called leaking_addresses.pl; it looks at the system log and walks through /proc and /sys in search of kernel addresses that have escaped to user space. It missed /sys/kernel/notes, though, because it's looking for addresses expressed as human-readable strings; /sys/kernel/notes is a binary file, which is rather less amenable to the grep-like approach used by this tool. Addresses encoded into ASCII are relatively easy to recognize; in binary form, instead, they just look like data.

Most data, though, does not contain a value corresponding to the address of a kernel symbol. To find the exceptions (and catch addresses leaked in binary form), Cook has posted a patch to leaking_addresses.pl. It can read a file of kernel symbols, such as /proc/kallsyms, and look to see if the the addresses associated with those symbols appear in a binary file like /sys/kernel/notes. With this change, leaking_addresses.pl would have found this longstanding kernel-address disclosure; it should help to prevent others from being introduced in the future as well.

These changes will keep /sys/kernel/notes from wrecking KASLR on systems going forward. It seems almost certain that there are other moles in need of whacking, though. For most of the kernel's history, developers had no particular reason to conceal internal addresses; even now, preserving KASLR is not one of the top concerns for most developers. KASLR is a useful defense when combined with other techniques but, in a world where any developer in an inattentive moment can compromise it, KASLR cannot stand alone.

Comments (13 posted)

A RDRAND followup

In a recent episode, "Pitchforks for RDSEED", we learned that there was some uncertainty around whether hardware-based random-number generators on x86 CPUs could fail. Since the consequences of failure in some situations (confidential-computing applications in particular) can be catastrophic, there was some concern about this prospect and what to do about it. Since then, the situation has come a bit more into focus, and there would appear to be an agreed-upon plan for changes to be made to the kernel.

At the end of the last article, it was noted that there were ongoing discussions within the CPU vendors about whether the RDRAND and RDSEED instructions could fail to generate a properly random number. Proceeding without a thorough understanding of the hardware is, after all, a way to obtain the wrong kind of random outcomes. On February 14, Elena Reshetova came back with a summary of Intel's position on the matter:

The RdRand in a non-defective device is designed to be faster than the bus, so when a core accesses the output from the DRNG, it will always get a random number. As a result, it is hard to envision a scenario where the RdRand, on a fully functional device, will underflow.

In other words, RDRAND can be expected to always succeed. The lower-level RDSEED instruction, instead, consumes entropy more directly and, as participants in the discussion had already shown, can fail if stressed too hard.

Confidential-computing applications, at the core of their security model, require random data that is not under the control of the host system (or anybody else). Only a random-number generator built into the CPU itself will fill the bill; anything else may be subject to external manipulation. There seems to be universal agreement, though, that the data from RDRAND is good enough even for confidential computing, and thus there is no need to use RDSEED. So these applications should be safe on Intel systems — safe from a random-number compromise anyway.

Jason Donenfeld, the maintainer of the kernel's random-number generator, responded with a brief patch series making a couple of changes. One is to immediately issue a warning if an attempt to use RDRAND fails, on the assumption that, as described above, any such failure is indicative of a hardware problem. That patch also eliminated the loop that would retry the operation ten times, since even one failure suggests that the hardware is broken and retrying is unlikely to fix it. There was just one little problem with that change, as was pointed out by Tom Lendacky: the claim about the robustness of RDRAND applies to current CPUs. Older processors might behave differently, and there may be cases where the retry loop is indicated. So that patch appears to have been dropped for now.

The other patch, applied to the confidential-computing support code, attempts to seed the kernel's random-number generator with 256 bits of RDRAND output at boot time. Should that attempt fail, the result will be an immediate system panic. Any such failure would indicate that a confidential-computing virtual machine lacks a reliable source of randomness and, thus, will be unable to achieve the intended level of confidentiality. In such cases, it is better to just stop immediately rather than run in a potentially compromised mode.

That latter patch has been reposted with a few tweaks, and has obtained Reviewed-by tags from a number of relevant developers. So it looks likely to be the end of this particular story — until, as always seems to be the case, somebody finds something else to worry about in the random-number generator.

Comments (3 posted)

Treating documentation as code

At FOSDEM 2024, the "Tool the docs" devroom hosted several talks about free and open-source tools for writing, managing, testing, and rendering documentation. The central concept was to treat documentation as code, which makes it possible to incorporate various tools into documentation workflows in order to maintain high quality.

One software-development best practice is to have a continuous-integration (CI) setup for a project. By automatically running a formatter, linter, and tests on every code change committed to the project's repository, developers can maintain uniform code quality. In her talk "Open Source DocOps", Lorna Jane Mitchell made an argument for applying the same approach to documentation projects.

This DocOps approach, short for "documentation operations", derives from a well-known definition of DevOps, which calls it "a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams". Instead of applying these things to software development, DocOps applies them to documentation. Mitchell characterized DocOps as "allowing documentation to be created, maintained, and published collaboratively and in an efficient manner."

Treating docs as code

DocOps builds on Docs-as-code, an approach that stipulates that documentation should be written in the same manner as code. Mitchell stressed the importance of tools and techniques borrowed from software development:

Using Git is key for many documentation workflows, and writing your documentation in a text-based markup language that is then converted into HTML or other formats simplifies integrating documentation into source control.

Additional key aspects of Docs-as-code include automated tests using continuous integration and the ability to run the same tests with local tools. "If you need to push your documentation changes to Git to see whether the tests succeed, that can't be right", Mitchell said. The process should be both fast and frictionless.

Illustrating that last point, Mitchell emphasized that all documentation writers should be able to see a preview of their changes immediately. She showed the example of an OpenAPI description of an API in Visual Studio Code. The documentation's YAML source file was positioned on the left, accompanied by a live preview of the generated documentation on the right. "Writers need to have this immediate feedback when working on documentation."

Another indispensable tool is a link checker. Many docs contain links to web sites, which can break when those sites change their internal structure or go offline. A link checker automatically visits all links within the documentation and verifies whether they're still valid. There are two approaches to do this: either it checks links in the source format or it checks them in the generated HTML files. "Either approach is valid", Mitchell said, "I like to check links in Markdown files with mlc, but you can also run an HTML link checker after the build process." She is referring to the MIT-licensed Markup Link Checker.

However, Mitchell warned not to apply link checking indiscriminately. If a continuous-integration pipeline has strict link checks and aborts the documentation build process on every broken link, this could lead to some unexpected problems when a web site experiences temporary downtime: "Don't let someone else's downtime block your build or release." She suggested some strategies that could assist in this situation. For example, restrict the scope of the link checks: "Perhaps only check internal links, or only check links in changed source files." To still be able to find all of the broken links, Mitchell recommended scheduling a comprehensive link check on a weekly basis.

Validation, formatting, and prose linting

Just like a programming language, a markup language has a syntax that should be followed. But markup mistakes in the documentation's source files can yield non-obvious results, even upon reviewing the live preview. Thus, any documentation workflow needs some validation. For Markdown, Mitchell recommended David Anson's MIT-licensed markdownlint (various other tools with the same name exist). "Markdownlint is quite configurable. And for reStructuredText, the Sphinx documentation generator includes a linter." Redocly, Mitchell's employer, has developed an MIT-licensed linter for OpenAPI documentation, Redocly CLI.

Linting a source file to ensure syntax validity is one thing, but even in valid files there's a wide range of possible ways to write something. A formatter can help in maintaining a consistent style across the source files. "A formatter adjusts things like newlines, spacing, indentation, line length, and a consistent syntax for bullet lists and tables", Mitchell explained. "Using consistent markup makes it considerably easier to spot problems in your source files."

Of course, there are concerns beyond just the markup language, as the natural language used in the text obviously also makes a difference. Other tools assist in quality assurance of the text, such as Vale. With Vale, documentation writers can catch common mistakes in their writing, such as repeated words and misspellings, but it can do a lot more than that. Mitchell noted that "Vale is especially useful for checking for the consistent use of the correct case and spelling of product names". An LWN article about Vale is coming soon.

Regardless of the tools a project uses for its documentation, Mitchell underscored that they should be seamlessly integrated within the team's processes: "Incorporate them into your workflows, and make sure to use the same tools and configuration everywhere, across all users." To maintain documentation quality, she recommended applying the tools to every pull request, ensuring that the workflow never misses any check. "Furthermore, build previews on any pull request to assist reviewers", she added.

Opening a pull request is a big feedback loop, though. Mitchell reiterated that documentation writers also need small feedback loops. "They need to have all tools available locally, ideally fully integrated into their IDE." Of course, a local setup requires the user to install the tools. Consequently, Mitchell warned, the setup of all documentation tools should be clearly written down for onboarding new writers.

Useful tools for documentation

After Mitchell's introductory talk set the stage, several other talks delved into specific tools useful for documentation writers. Jack Baldry, a software engineer at Grafana Labs, explained how his company uses Vale to enforce a consistent style across Grafana's documentation:

If you're using a style guide for your documentation, memorizing each one of those rules can be quite a challenge. Vale assists you by flagging any rule violations it detects and providing a clear explanation.

The company's Writers' Toolkit has implemented rules for Vale that show a message whenever a writer uses terms such as "modal" instead of "dialog box", opts for future tense rather than present tense, or writes "alert manager" instead of the correct "Alertmanager".

Documentation not only consists of text, but often also uses diagrams or other pictures. Frank Vanbever, an electrical engineer working at embedded systems company Mind, described how Gaphor allows documentation writers to create diagrams:

The natural way to explain a complex system has always been walking toward a whiteboard and starting to draw boxes and arrows. Gaphor allows writers to replicate this process in their documentation."

The Apache 2-licensed software implements the UML, SysML, RAAML, and C4 modeling languages, allowing documentation writers to use block diagrams, state machines, software architecture diagrams, and other visualizations of software.

Gaphor can also be integrated with the Sphinx documentation generator, enabling the documentation build system to automatically update diagrams in documentation when the source model is changed. Furthermore, the tool has a Python API, which permits model testing with pytest and makes interactive exploration possible with a web-based development environment such as JupyterLab.

The final tool introduced in the devroom was Anton Zhiyanov's Apache 2-licensed codapi. Percona's Peter Zaitsev demonstrated how to make tutorials and how-to guides interactive by adding embeddable code playgrounds using codapi. While traditional documentation merely shows some example code and its result, with codapi the code snippet becomes a dynamic, runnable entity. As soon as the reader clicks on the Run button, the code runs and updates the output in the HTML page. Readers can even edit the code snippet and rerun it to explore the differences.

Codapi has two implementations: one completely browser-based and one with a Docker container on the backend. The first implementation uses WebAssembly to run Python, PHP, Ruby, Lua, or SQLite code in a sandboxed execution environment, completely in-browser. The other implementation connects to a Docker container on a server, which can run other language environments.

Conclusion

Mitchell's presentation underscored the advantages of applying various best practices from software development to documentation workflows. Additionally, "Tool the docs" provided documentation writers with a comprehensive overview of various available FOSS tools in this domain. Hopefully, this will help convince software projects to add these tools into their workflows. Every project stands to benefit from consistent, high-quality documentation.

Comments (3 posted)

Stenberg: DISPUTED, not REJECTED

The Curl project has previously had problems with CVEs issued for things that are not security issues. On February 21, Daniel Stenberg wrote about the Curl project's most recent issue with the CVE system, saying:

I keep insisting that the CVE system is broken and that the database of existing CVEs hosted by MITRE (and imported into lots of other databases) is full of questionable content and plenty of downright lies. A primary explanation for us being in this ugly situation is that it is simply next to impossible to get rid of invalid CVEs.

Comments (115 posted)

Kernel release status

The current development kernel is 6.8-rc6, released on February 25. According to Linus:

Last week I said that I was hoping things would calm down a bit. Technically things did calm down a bit, and rc6 is smaller than rc5 was. But not by a huge amount, and honestly, while there's nothing really alarming here, there's more here than I would really like at this point in the release.

So this may end up being one of those releases that get an rc8. We'll see.

Stable updates: 6.7.6, 6.6.18, 6.1.79, 5.15.149, 5.10.210, 5.4.269, and 4.19.307 were all released on February 23.

The 6.7.7, 6.6.19, 6.1.80, 5.15.150, 5.10.211, 5.4.270, and 4.19.308 updates are all in the review process; they are due on February 29.

Comments (none posted)

The bpftop tool

Netflix has announced the release of a tool called bpftop to help with the performance optimization of BPF programs in the kernel:

bpftop provides a dynamic real-time view of running eBPF programs. It displays the average execution runtime, events per second, and estimated total CPU % for each program. This tool minimizes overhead by enabling performance statistics only while it is active.

Comments (6 posted)

Quotes of the week

Static checkers insist that the mpi_alloc() allocation can fail so add a check to prevent a NULL dereference. Small allocations like this can't actually fail in current kernels, but adding a check is very simple and makes the static checkers happy.

The Linux kernel CVE team has assigned CVE-2023-52472 to this issue.

— Greg Kroah-Hartman

• Code Changes: Introduces a new mlx5ctl misc driver for the mlx5 ConnectX family of devices, allowing userspace to execute debug RPCs and access device capabilities directly, bypassing the kernel's netdev interface.
• Code Quality: The patches seem well-structured and follow kernel coding conventions. The series includes detailed explanations and justifications for the changes.

— ChatGPT via Konstantin Ryabitsev. See also this discussion

MichalH: was hopin' the new CVE process would be cooler, ya know? like, more important CVEs and stuff. 🤞

GregKH: hey peeps, so like, going where you shouldn't in memory is bad, right? we can't guess how everyone uses the kernel, so marking these fixes with CVEs is smart 🧐

— Konstantin Ryabitsev goes completely nuts with it

Comments (1 posted)

Tails 6.0 released

Tails 6.0 is now available. Based on Debian, Tails is a portable operating system designed to run from a USB stick and help users avoid surveillance and censorship. This release updates most Tails applications, and includes important security and usability improvements.

One major new feature in 6.0 is to provide warnings to users about errors when reading or writing to persistent storage. This release now ignores USB devices plugged in while the screen is locked, and removes some file and disk-wiping features from the Files application that are "not reliable enough" on USB sticks and SSDs to continue offering to users.

Users of Tails prior to 6.0~rc1 will need to do a manual upgrade to retain persistent storage. New users can download Tails for USB, or as an ISO to create a DVD or run Tails in a virtual machine.

Comments (none posted)

Distributions quote of the week

Given the recent spread of the "AI" bubble, I think we really need to look into formally addressing the related concerns. In my opinion, at this point the only reasonable course of action would be to safely ban "AI"-backed contribution entirely. In other words, explicitly forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to create ebuilds, code, documentation, messages, bug reports and so on for use in Gentoo.

— Michał Górny

Comments (none posted)

Git 2.44.0 released

Version 2.44.0 of the Git source-code management system has been released. There is a long list of changes, including the git replay command for faster, server-side rebasing, a number of command-line completion improvements, and more.

Comments (18 posted)

Incus 0.6 released

Version 0.6 of Incus, a fork of LXD, has been released. This release includes a number of changes, including a new storage driver called lvmcluster, improvements for Open Virtual Network (OVN) users, improvements to migration tooling, a number of new security features, and storage bucket backup and re-import. See the release announcement for detailed release notes and complete list of changes. The announcement notes that a Long Term Support (LTS) release of Incus is planned in a few months "to coincide with the LTS releases of LXC and LXCFS".

Comments (none posted)

Development quote of the week

The best part about being an open source maintainer is the copious amounts of free advice you get from people who know better than you what your project should do.

— Daniel Stenberg

Comments (none posted)

The Open Collective Foundation is shutting down

The Open Collective Foundation is an organization created to provide legal and financial services for non-profit projects, many of which are associated with free software. Projects hosted there are now beginning to report that the Open Collective Foundation will be shutting down at the end of the year, with an unwinding process over that time.

Unfortunately, over the past year, we have learned that Open Collective Foundation's business model is not sustainable with the number of complex services we have offered and the fees we pay to the Open Collective Inc. tech platform.

In late 2023, we made the decision to pause accepting new collectives in order to create space for us to address the issues. Unfortunately, it became clear that it would not be financially feasible to make the necessary corrections, and we determined that OCF is not viable.

Some more information can be found in the Dissolution FAQ. Note that the Open Collective Foundation is distinct from Open Source Collective, which has hastened to point out that it remains in operation as before, and both are distinct from the Open Collective platform.

Comments (5 posted)

CFP Deadlines: February 29, 2024 to April 29, 2024

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

Deadline	Event Dates	Event	Location
March 1	May 13 May 15	LSFMM+BPF	Salt Lake City, US
March 1	April 20	Augsburger Linux-Infotag	Augsburg, Germany
March 1	June 7 June 9	SouthEast Linux Fest	Charlotte, NC, US
March 10	June 13 June 15	DevConf.CZ	Brno, Czech Republic
March 22	October 27 October 29	All Things Open	Raleigh, NC, US
March 23	May 14 May 17	Linaro Connect	Madrid, Spain
March 23	May 23 May 24	Lund Linux Conference 2024	Lund, Sweden
March 29	April 26 April 28	Unix Friends and User Campus Kamp 2024	Furtwangen, Germany
March 31	June 18 June 19	stackconf 2024	Berlin, Germany
March 31	June 5 June 6	Icinga Summit 2024	Berlin, Germany
April 13	August 31 September 2	UbuCon Asia 2024	Jaipur, India
April 15	June 27 June 29	openSUSE Conference 2024	Nuremberg, Germany
April 22	July 15 July 19	Netdev 0x18	Silicon Valley, CA, US

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

Events: February 29, 2024 to April 29, 2024

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

Date(s)	Event	Location
February 27 February 29	22nd USENIX Conference on File and Storage Technologies	Santa Clara, CA, US
March 3 March 9	MiniDebCamp Hamburg	Hamburg, Germany
March 7 March 8	Open Source Day 2024	Florence, Italy
March 14 March 17	SCALE 21x	Pasadena, CA, US
March 16 March 17	Chemnitz Linux Days 2024	Chemnitz, Germany
April 6	Central PA Open Source Conference	Lancaster, PA, USA
April 8 April 10	FOSSASIA Summit	Hanoi, Vietnam
April 12	PostgreSQL Conference Germany	Munich, Germany
April 12 April 13	Texas Linux Fest	Austin, Texas, US
April 14 April 15	foss-north 2024	Gothenburg, Sweden
April 16 April 18	sambaXP 2024	Online
April 16 April 18	Everything Open	Gladstone, Australia
April 16 April 18	Open Source Summit North America	Seattle, US
April 18 April 19	Linux Security Summit North America	Seattle, WA, US
April 20	Augsburger Linux-Infotag	Augsburg, Germany
April 25 April 26	Eco Compute 2024 - Engineering Conference on Sustainability in Hardware & Software	Munich, Germany
April 26 April 28	Unix Friends and User Campus Kamp 2024	Furtwangen, Germany
April 26 April 28	Penguicon 2024	Ann Arbor, Michigan, US
April 26 April 28	Linux Fest Northwest	Bellingham, WA, US

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

Alert summary February 22, 2024 to February 28, 2024

Dist.	ID	Release	Package	Date
CentOS	CESA-2024:0857	C7	python-pillow	2024-02-21
Debian	DSA-5629-1	stable	chromium	2024-02-23
Debian	DLA-3741-1	LTS	engrampa	2024-02-26
Debian	DSA-5627-1	stable	firefox-esr	2024-02-21
Debian	DLA-3740-1	LTS	gnutls28	2024-02-26
Debian	DLA-3737-1	LTS	imagemagick	2024-02-22
Debian	DSA-5628-1	stable	imagemagick	2024-02-22
Debian	DLA-3738-1	LTS	iwd	2024-02-22
Debian	DSA-5631-1	stable	iwd	2024-02-25
Debian	DSA-5633-1	stable	knot-resolver	2024-02-27
Debian	DLA-3742-1	LTS	libgit2	2024-02-27
Debian	DLA-3739-1	LTS	libjwt	2024-02-25
Debian	DSA-5630-1	stable	thunderbird	2024-02-23
Debian	DLA-3743-1	LTS	wpa	2024-02-27
Fedora	FEDORA-2024-6a879cfa63	F38	chromium	2024-02-25
Fedora	FEDORA-2024-4adf990562	F39	chromium	2024-02-23
Fedora	FEDORA-2024-ef56ea86fc	F39	chromium	2024-02-28
Fedora	FEDORA-2024-8a2c093df5	F38	expat	2024-02-24
Fedora	FEDORA-2024-bc8ea2c2cb	F39	firefox	2024-02-23
Fedora	FEDORA-2024-987089eca2	F38	kernel	2024-02-22
Fedora	FEDORA-2024-71f0f16533	F38	kernel	2024-02-28
Fedora	FEDORA-2024-88847bc77a	F39	kernel	2024-02-22
Fedora	FEDORA-2024-d16d94b00d	F39	kernel	2024-02-28
Fedora	FEDORA-2024-8b67e47e43	F38	libxls	2024-02-27
Fedora	FEDORA-2024-e74783429c	F39	libxls	2024-02-27
Fedora	FEDORA-2024-c7f1c839ac	F38	mbedtls	2024-02-22
Fedora	FEDORA-2024-b8656bc059	F38	mingw-expat	2024-02-25
Fedora	FEDORA-2024-fbe1f0c1aa	F39	mingw-expat	2024-02-25
Fedora	FEDORA-2024-f4d51715fe	F38	mingw-openexr	2024-02-25
Fedora	FEDORA-2024-7fc5bae919	F39	mingw-openexr	2024-02-25
Fedora	FEDORA-2024-94e0390e4e	F38	mingw-python3	2024-02-25
Fedora	FEDORA-2024-8df4ac93d7	F39	mingw-python3	2024-02-25
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qt3d	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtactiveqt	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtbase	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtcharts	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtdeclarative	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtgraphicaleffects	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtimageformats	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtlocation	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtmultimedia	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtquickcontrols	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtquickcontrols2	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtscript	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtsensors	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtserialport	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtsvg	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qttools	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qttranslations	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtwebchannel	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtwebsockets	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtwinextras	2024-02-24
Fedora	FEDORA-2024-a8cdce27ac	F39	mingw-qt5-qtxmlpatterns	2024-02-24
Fedora	FEDORA-2024-4e36df9dfd	F38	pdns-recursor	2024-02-23
Fedora	FEDORA-2024-b0f9656a76	F39	pdns-recursor	2024-02-23
Fedora	FEDORA-2024-fa14bfd3b5	F38	perl-Spreadsheet-ParseXLSX	2024-02-27
Fedora	FEDORA-2024-5f136f5d10	F39	perl-Spreadsheet-ParseXLSX	2024-02-27
Fedora	FEDORA-2024-993d3a78dd	F38	rust-asyncgit	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-bat	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-cargo-c	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-eza	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-git-absorb	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-git-delta	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-git2	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-gitui	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-libgit2-sys	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-lsd	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-pore	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-pretty-git-prompt	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-shadow-rs	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-silver	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-tokei	2024-02-22
Fedora	FEDORA-2024-993d3a78dd	F38	rust-vergen	2024-02-22
Fedora	FEDORA-2024-5361211b10	F38	thunderbird	2024-02-28
Fedora	FEDORA-2024-81863a1613	F39	thunderbird	2024-02-26
Fedora	FEDORA-2024-a95bdde55b	F39	wpa_supplicant	2024-02-27
Fedora	FEDORA-2024-5ecc250449	F38	yarnpkg	2024-02-28
Fedora	FEDORA-2024-28fc0c2ef4	F39	yarnpkg	2024-02-28
Gentoo	202402-31		GNU Aspell	2024-02-26
Gentoo	202402-30		Glances	2024-02-26
Gentoo	202402-29		LibreOffice	2024-02-21
Gentoo	202402-33		PyYAML	2024-02-26
Gentoo	202402-32		btrbk	2024-02-26
Mageia	MGASA-2024-0051	9	c-ares	2024-02-28
Mageia	MGASA-2024-0048	9	clamav	2024-02-24
Mageia	MGASA-2024-0046	9	nodejs and yarnpkg	2024-02-22
Mageia	MGASA-2024-0049	9	packages	2024-02-27
Mageia	MGASA-2024-0050	9	thunderbird	2024-02-27
Mageia	MGASA-2024-0047	9	xen, qemu and libvirt	2024-02-24
Oracle	ELSA-2024-0976	OL7	firefox	2024-02-27
Oracle	ELSA-2024-0976	OL7	firefox	2024-02-27
Oracle	ELSA-2024-0955	OL8	firefox	2024-02-27
Oracle	ELSA-2024-0952	OL9	firefox	2024-02-26
Oracle	ELSA-2024-0346	OL7	kernel	2024-02-27
Oracle	ELSA-2024-0967	OL8	opensc	2024-02-27
Oracle	ELSA-2024-0966	OL9	opensc	2024-02-27
Oracle	ELSA-2024-0951	OL9	postgresql	2024-02-23
Oracle	ELSA-2024-0975	OL8	postgresql:13	2024-02-27
Oracle	ELSA-2024-0973	OL8	postgresql:15	2024-02-27
Oracle	ELSA-2024-0950	OL9	postgresql:15	2024-02-27
Oracle	ELSA-2024-0957	OL7	thunderbird	2024-02-27
Oracle	ELSA-2024-0957	OL7	thunderbird	2024-02-27
Red Hat	RHSA-2024:1004-01	EL8.2	edk2	2024-02-27
Red Hat	RHSA-2024:1013-01	EL8.4	edk2	2024-02-28
Red Hat	RHSA-2024:0976-01	EL7	firefox	2024-02-26
Red Hat	RHSA-2024:0955-01	EL8	firefox	2024-02-26
Red Hat	RHSA-2024:0972-01	EL8.2	firefox	2024-02-26
Red Hat	RHSA-2024:0971-01	EL8.4	firefox	2024-02-26
Red Hat	RHSA-2024:0970-01	EL8.6	firefox	2024-02-26
Red Hat	RHSA-2024:0969-01	EL8.8	firefox	2024-02-26
Red Hat	RHSA-2024:0952-01	EL9	firefox	2024-02-22
Red Hat	RHSA-2024:0968-01	EL9.0	firefox	2024-02-26
Red Hat	RHSA-2024:0983-01	EL9.2	firefox	2024-02-27
Red Hat	RHSA-2024:1007-01	EL8.4	gimp:2.8	2024-02-27
Red Hat	RHSA-2024:0980-01	EL7.6	kernel	2024-02-27
Red Hat	RHSA-2024:0999-01	EL7.7	kernel	2024-02-27
Red Hat	RHSA-2024:0937-01	EL8.6	kpatch-patch	2024-02-22
Red Hat	RHSA-2024:0978-01	EL7.6	linux-firmware	2024-02-26
Red Hat	RHSA-2024:0979-01	EL7.7	linux-firmware	2024-02-27
Red Hat	RHSA-2024:0967-01	EL8	opensc	2024-02-26
Red Hat	RHSA-2024:0966-01	EL9	opensc	2024-02-26
Red Hat	RHSA-2024:0951-01	EL9	postgresql	2024-02-22
Red Hat	RHSA-2024:0956-01	EL8	postgresql:10	2024-02-26
Red Hat	RHSA-2024:0974-01	EL8	postgresql:12	2024-02-26
Red Hat	RHSA-2024:0975-01	EL8	postgresql:13	2024-02-26
Red Hat	RHSA-2024:0973-01	EL8	postgresql:15	2024-02-26
Red Hat	RHSA-2024:0950-01	EL9	postgresql:15	2024-02-22
Red Hat	RHSA-2024:0957-01	EL7	thunderbird	2024-02-26
Red Hat	RHSA-2024:0964-01	EL8	thunderbird	2024-02-26
Red Hat	RHSA-2024:0958-01	EL8.2	thunderbird	2024-02-26
Red Hat	RHSA-2024:0959-01	EL8.4	thunderbird	2024-02-26
Red Hat	RHSA-2024:0960-01	EL8.6	thunderbird	2024-02-26
Red Hat	RHSA-2024:0961-01	EL8.8	thunderbird	2024-02-26
Red Hat	RHSA-2024:0963-01	EL9	thunderbird	2024-02-26
Red Hat	RHSA-2024:0962-01	EL9.0	thunderbird	2024-02-26
Red Hat	RHSA-2024:0984-01	EL9.2	thunderbird	2024-02-26
Red Hat	RHSA-2024:0965-01	EL8	unbound	2024-02-26
Red Hat	RHSA-2024:0982-01	EL8.8	unbound	2024-02-27
Red Hat	RHSA-2024:0977-01	EL9	unbound	2024-02-26
Red Hat	RHSA-2024:0981-01	EL9.2	unbound	2024-02-26
Slackware	SSA:2024-052-01		mozilla	2024-02-21
Slackware	SSA:2024-057-01		openjpeg	2024-02-26
SUSE	SUSE-SU-2023:3474-1	MP4.2 SLE15 oS15.5	SUSE Manager 4.2	2024-02-27
SUSE	SUSE-SU-2023:0592-1	MP4.2 SLE12	SUSE Manager 4.2.11	2024-02-27
SUSE	SUSE-SU-2023:2181-1	MGR4.2 MP4.2 MP4.3 SLE15 oS15.3 oS15.4 oS15.5	SUSE Manager 4.3	2024-02-27
SUSE	SUSE-SU-2023:1830-1	MP4.3	SUSE Manager 4.3	2024-02-27
SUSE	SUSE-SU-2023:1831-1	MP4.2 MP4.3 SLE15 SES7 SES7.1 oS15.4	SUSE Manager Server 4.2	2024-02-27
SUSE	SUSE-SU-2023:2594-1	MP4.2 SLE15 oS15.3 oS15.5	SUSE Manager Server 4.2	2024-02-27
SUSE	SUSE-SU-2023:2954-1	MP4.2 MP4.3 SLE15 SES7.1 oS15.3 oS15.4	bind	2024-02-27
SUSE	SUSE-SU-2024:0590-1	MP4.3 SLE15 oS15.4	bind	2024-02-22
SUSE	SUSE-SU-2023:2613-1	MP4.2 SLE15 SES7.1 oS15.3	bluez	2024-02-27
SUSE	SUSE-SU-2023:2600-1	MP4.3 SLE15 SES7 SES7.1	container-suseconnect	2024-02-27
SUSE	SUSE-SU-2023:2760-2	SLE15 oS15.4 oS15.5	dnsdist	2024-02-27
SUSE	SUSE-SU-2024:0586-1	MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.5 osM5.3 osM5.4	docker	2024-02-22
SUSE	SUSE-SU-2024:0587-1	SLE12	docker	2024-02-22
SUSE	SUSE-SU-2024:0607-1	SLE15 SES7.1 oS15.5	firefox	2024-02-23
SUSE	SUSE-SU-2024:0648-1	SLE12	freerdp	2024-02-28
SUSE	SUSE-SU-2024:0649-1	SLE15 SLE-m5.5 oS15.4 oS15.5	freerdp	2024-02-28
SUSE	SUSE-SU-2023:3661-1	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7 oS15.4 osM5.3 osM5.4	gcc12	2024-02-27
SUSE	SUSE-SU-2023:3662-1	SLE12	gcc7	2024-02-27
SUSE	SUSE-SU-2023:0174-1	MP4.2 SLE15 SLE-m5.1 SLE-m5.2 SES7 SES7.1 oS15.4	glib2	2024-02-27
SUSE	SUSE-SU-2024:0638-1	SLE15 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5 osM5.4	gnutls	2024-02-27
SUSE	SUSE-SU-2023:2598-1	MP4.2 MP4.3 SLE15 SLE-m5.5 oS15.4 oS15.5	golang-github-prometheus-prometheus	2024-02-27
SUSE	SUSE-SU-2023:2826-1	MP4.2 SLE15 SES7.1 oS15.3	installation-images	2024-02-27
SUSE	SUSE-SU-2024:0605-1	SLE12	java-1_8_0-ibm	2024-02-23
SUSE	SUSE-SU-2024:0619-1	SLE15 SES7.1 oS15.5	java-1_8_0-ibm	2024-02-26
SUSE	SUSE-SU-2023:0774-1	MP4.3 SLE15 oS15.4	kernel	2024-02-27
SUSE	SUSE-SU-2023:2646-1	SLE15 oS15.5	kernel	2024-02-27
SUSE	SUSE-SU-2023:4624-1	SLE15 SLE-m5.5 oS15.5	kubevirt, virt-api-container, virt-controller-container, virt-exportproxy-container, virt-exportserver-container, virt-handler-container, virt-launcher-container, virt-libguestfs-t	2024-02-27
SUSE	SUSE-SU-2023:2824-1	SLE15 oS15.5	libqt5-qtbase	2024-02-27
SUSE	SUSE-SU-2023:2967-1	SLE12	libqt5-qtsvg	2024-02-27
SUSE	SUSE-SU-2024:0613-1	SLE-m5.3 SLE-m5.4 oS15.4 osM5.3 osM5.4	libxml2	2024-02-26
SUSE	SUSE-SU-2024:0597-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5 osM5.3 osM5.4	mozilla-nss	2024-02-22
SUSE	SUSE-SU-2024:0644-1	SLE12	nodejs18	2024-02-28
SUSE	SUSE-SU-2024:0643-1	SLE15 oS15.5	nodejs20	2024-02-28
SUSE	SUSE-SU-2024:0596-1	MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.3 oS15.5 osM5.3 osM5.4	openssh	2024-02-22
SUSE	SUSE-SU-2024:0604-1	SLE12	openssh	2024-02-23
SUSE	SUSE-SU-2024:0603-1	SLE15	openssh	2024-02-23
SUSE	SUSE-SU-2023:2633-1	MP4.3 SLE15 SES7 SES7.1 oS15.4 oS15.5	openssl-1_0_0	2024-02-27
SUSE	SUSE-SU-2023:2634-1	SLE12	openssl	2024-02-27
SUSE	SUSE-SU-2024:0592-1	SLE15 oS15.4 oS15.5	php-composer2	2024-02-22
SUSE	SUSE-SU-2023:2941-1	MP4.2 MP4.3 SLE15 oS15.4	poppler	2024-02-27
SUSE	SUSE-SU-2023:2897-1	MP4.0 MP4.1 MP4.2 MP4.3 SLE15 oS15.4 oS15.5	python-azure-core, python-azure-storage-blob	2024-02-27
SUSE	SUSE-SU-2023:1838-1	MP4.0 MP4.1 MP4.2 MP4.3 SLE15 oS15.4	python-crcmod, python-cryptography, python-cryptography- vectors	2024-02-27
SUSE	SUSE-SU-2023:2932-1	MP4.3 SLE15 oS15.4 oS15.5	python-pip	2024-02-27
SUSE	SUSE-SU-2023:2933-1	SLE12	python-pip	2024-02-27
SUSE	SUSE-SU-2024:0585-1	MP4.1 SLE15	python-pycryptodome	2024-02-22
SUSE	SUSE-SU-2024:0601-1	SLE15 oS15.5	python-pycryptodome	2024-02-23
SUSE	SUSE-SU-2023:2638-1	SLE12	python-requests	2024-02-27
SUSE	SUSE-SU-2024:0591-1	MP4.1 MP4.2 MP4.3 SLE15 oS15.5	python-uamqp	2024-02-22
SUSE	SUSE-SU-2024:0581-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3 oS15.5 osM5.3 osM5.4	python3	2024-02-21
SUSE	SUSE-SU-2023:2883-1	SLE12	python3-requests	2024-02-27
SUSE	SUSE-SU-2024:0595-1	SLE15 oS15.4 oS15.5	python310	2024-02-23
SUSE	SUSE-SU-2023:2937-1	MP4.3 SLE15 oS15.4 oS15.5	python311	2024-02-27
SUSE	SUSE-SU-2023:2641-1	SLE15 oS15.3 oS15.4 oS15.5	python39	2024-02-27
SUSE	SUSE-SU-2024:0589-1	SLE15 SLE-m5.5	qemu	2024-02-22
SUSE	SUSE-SU-2023:2823-1	MP4.2 MP4.3 SLE15 SES7.1 oS15.3 oS15.4 oS15.5	rabbitmq-c	2024-02-27
SUSE	SUSE-SU-2023:2585-1	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7 SES7.1 oS15.4 oS15.5 osM5.3 osM5.4	salt and python-pyzmq	2024-02-27
SUSE	SUSE-SU-2023:2930-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4 osM5.3 osM5.4	samba	2024-02-27
SUSE	SUSE-SU-2023:2929-1	SLE15 oS15.5	samba	2024-02-27
SUSE	SUSE-SU-2023:2637-1	SLE15 SES7.1 oS15.3	sccache	2024-02-27
SUSE	SUSE-SU-2023:1863-1	OS9 SLE12	shim	2024-02-27
SUSE	SUSE-SU-2023:0488-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4 osM5.3	the Linux-RT Kernel	2024-02-27
SUSE	SUSE-SU-2023:2612-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5	thunderbird	2024-02-27
SUSE	SUSE-SU-2024:0608-1	SLE15 SLE-m5.5 oS15.5	thunderbird	2024-02-23
SUSE	SUSE-SU-2024:0593-1	SLE12	tiff	2024-02-22
SUSE	SUSE-SU-2024:0594-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.5 osM5.3 osM5.4	tiff	2024-02-22
SUSE	SUSE-SU-2023:1864-1	SLE12	wayland	2024-02-27
Ubuntu	USN-6655-1	20.04 22.04	binutils	2024-02-26
Ubuntu	USN-6657-1	20.04 22.04 23.10	dnsmasq	2024-02-26
Ubuntu	USN-6649-1	20.04	firefox	2024-02-22
Ubuntu	USN-6664-1	16.04 18.04 20.04 22.04 23.10	less	2024-02-27
Ubuntu	USN-6659-1	16.04 18.04 20.04 22.04	libde265	2024-02-26
Ubuntu	USN-6658-1	20.04 22.04 23.10	libxml2	2024-02-26
Ubuntu	USN-6648-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-bluefield, linux-gcp, linux-gkeop, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp	2024-02-21
Ubuntu	USN-6651-1	22.04 23.10	linux, linux-aws, linux-gcp, linux-hwe-6.5, linux-laptop, linux-oracle, linux-raspi, linux-starfive	2024-02-26
Ubuntu	USN-6653-1	20.04 22.04	linux, linux-azure, linux-azure-5.15, linux-azure-fde, linux-gcp, linux-gcp-5.15, linux-gkeop, linux-gkeop-5.15, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi	2024-02-26
Ubuntu	USN-6652-1	23.10	linux-azure	2024-02-26
Ubuntu	USN-6650-1	22.04	linux-oem-6.1	2024-02-26
Ubuntu	USN-6661-1	18.04 20.04 22.04 23.10	openjdk-17	2024-02-27
Ubuntu	USN-6662-1	20.04 22.04 23.10	openjdk-21	2024-02-27
Ubuntu	USN-6660-1	18.04 20.04 22.04 23.10	openjdk-lts	2024-02-27
Ubuntu	USN-6663-1	18.04 20.04 22.04 23.10	openssl	2024-02-27
Ubuntu	USN-6305-2	16.04 18.04 20.04	php7.0, php7.2, php7.4	2024-02-27
Ubuntu	USN-6656-1	20.04 22.04 23.10	postgresql-12, postgresql-14, postgresql-15	2024-02-26
Ubuntu	USN-6654-1	16.04 18.04 20.04 22.04 23.10	roundcube	2024-02-26
Ubuntu	USN-6644-2	22.04	tiff	2024-02-27

Full Story (comments: none)