Welcome to the LWN.net Weekly Edition for August 27, 2026

This edition contains the following feature content:

• An ongoing 3D-printer AGPL violation: what is being done to try to provide users of Bambu Lab 3D-printer software with alternatives.
• Considering the OpenMDW license: a license for distributing LLMs and related materials seems unlikely to gain OSI approval in its current form.
• How to be safe from quantum computing: a look at configuration changes and protocol updates needed to protect today's encrypted data from tomorrow's quantum computers.
• The beginning of the 7.3 merge window: some of the noteworthy changes coming to the next kernel release.
• Old-school calendaring at the command line with Remind: a look at a calendaring system older than Linux.
• A look at the Quickshell desktop-component toolkit: the project behind popular desktop shells for minimal window managers.

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)

An ongoing 3D-printer AGPL violation

At FOSSY 2026, several people from the Software Freedom Conservancy (SFC), which organizes the conference, gave a presentation about an ongoing violation of the Affero General Public License version 3 (AGPLv3). Bradley Kühn, Karen Sandler, and Denver Gingerich spoke about different aspects of the violation, which is in regard to 3D-printer software from Bambu Lab, and what is being done to try to provide users with alternatives. One aspect that is particularly interesting is that the circumvention that the company is employing is precisely what the AGPL was written to prevent.

Kühn began the session by noting that he has been an activist in the free and open-source software (FOSS) communities for over 30 years and that "this moment in history [...] has more activism opportunities than I have seen in my career". In the past, he and his colleagues have been triaging disasters of various sorts but over the past six to eight months they have been triaging opportunities instead. Sandler added that the opportunities being offered are difficult; "it's not like people are saying 'would you like this money or that money?'".

The opportunities he is describing are not really about money, Kühn said, but provide ways "for activists to get stuff done and to engage people". Over the past six months or so, SFC has successfully engaged with "an entire community of enthusiasts", which only had a passing familiarity with FOSS, on a multitude of freedom-centric topics: "free software, free culture, free creation". That is exciting, but he was getting ahead of himself because that is where the story ends, so he wanted to go back to the beginning.

Backstory

Some time ago, 3D printing was invented, which is something that he watched from afar; a breadboard fire when he was an undergraduate convinced him that he should be a software-only person. He is a fan of the 3D-printing culture, and enjoys the talks that come from it, but he does not participate. As part of the license-violation investigation, he and Gingerich did a crash course in the history of 3D-printing, though Gingerich already had much of the background.

Kühn related some of what he learned, including that the hobbyist 3D-printing field started out as a curiosity. People who wanted a 3D printer had to build one themselves, since there were no already assembled devices on the market. Some of those who built the early printers went on to found companies that now sell 3D printers, which is a key element in the development of the community. Like Linux, 3D printers started as a hobby and remained "a hobby for a long-enough period of time that the hobby culture could not be immediately eradicated by venture capitalists".

The "wonderful thing" about 3D printing is that the people developing the software needed to run the devices looked to the free-software community and "thought twice" before they started picking licenses for their code. An important piece of the tooling needed to use these devices is a program known as a "slicer", which turns a 3D model—some slicers also help build these models—into thin 2D slices that can be converted into the language that the printer hardware understands. He likens that language to assembly language, which is an oversimplification, but helps provide a conceptual framework for him.

A longtime free-software enthusiast, Alessandro Ranellucci, created a slicer, which he called "Slic3r". Kühn said that his only criticism of Ranellucci was his choice of the name, which makes it hard to distinguish between the program and the overall type of program in a talk, so Kühn used "slicer with three" to distinguish them. The two spoke over a video chat and Ranellucci said that he chose the AGPLv3 for Slic3r to try to avoid the mess with Bambu Lab: "I anticipated all this, because my biggest worry was that someone was going to do 'Slic3r as a service'".

While there are 3D printers that use other slicers, it is difficult to find one that is not best used with some fork of Slic3r, Kühn said. There are around 18 active forks, but the most well-known is PrusaSlicer. It came about because a friend of Ranellucci's, Josef Prusa, saw 3D printing as not only just a business opportunity, but "a free-software business opportunity". Prusa built a company based on providing customers with printer plans, free software, free firmware, and so on, Kühn said; that company was the dominant player in the market for a time.

At the same time, a parallel market in 3D printers for manufacturing was developing. These were printers that took up a whole room and cost hundreds of thousands of dollars. Meanwhile, though, the hobbyist printers that cost $500-3000 were "becoming really, really, really good", especially toward the top end of that range.

Enter Bambu

That was the state of the market in 2019 and pre-COVID 2020. During COVID, lots of people picked up hobbies, including 3D printing; that attracted a Chinese company, Bambu Lab, to the market. Kühn said that the company is rumored to have ties to the Chinese government, though that has not been confirmed. It decided to start from scratch and make 3D printers; by 2025, the company controlled 38-48% (depending on the analyst report) of the market for $500-3000 printers. In part, that is because the market for room-sized industrial printers is dying and that customers have realized that they can be replaced with fleets of much cheaper, better, and more reliable printers from companies like Bambu Lab; the company has been targeting that market, along with the hobbyist market, thus its success.

Bambu Lab needed a slicer, of course, so it started shipping a modified PrusaSlicer (as Bambu Studio), which it was able to get via the AGPLv3, but without shipping any source code or an offer to provide it. That continued up through 2022 or 2023, Kühn said, until the pressure from the 3D-printing community effectively forced Bambu Lab to make a source release, which was, as is almost always the case for a first release, not the actual corresponding source code.

"You've got to be amused by the ingenuity of copyleft violators", Kühn said; they often rely on mechanisms that an actual judge is not going to care about. In this case, Bambu Studio would pop up a request to download "a little more stuff" with the classic choices of "Yes" or "Ask me later"; users eventually figure out that some functionality in the slicer does not work until they click "Yes". The extras that are downloaded are two .so files built from C++ source. Those shared-library files are dynamically loaded into the slicer—as can plainly be seen from the dlopen() calls in the source code that was released.

Kühn said that Bambu Studio and all of its components would be considered a combined work under the regular GPLv3, but the company has a network-based component that runs up against the restrictions in the AGPLv3 as well. The dynamically loaded part of the slicer is a thin layer that calls out over the network to an extensive 3D application running on Bambu Lab servers; it passes a "key", which is just a specific User-Agent string, that allows access to the extra functionality on the servers. The company claims that the User-Agent, which is the same for all of the clients, is a DMCA anti-circumvention mechanism.

But, he said, that is exactly what the AGPLv3 is meant to prevent: "You can't put part of your Affero-GPLed application on your web server and keep it proprietary". A 3D-printing user from Poland, Paweł Jarczak, reverse-engineered the User-Agent string and network code, which resulted in a DMCA takedown notice from Bambu Lab. "GitHub, of course, honored it, because Microsoft." Jarczak is still maintaining the code in his slicer (OrcaSlicer), which is being mirrored on an SFC repository as part of its baltobu project that is aimed at working around the Bambu Lab AGPLv3 violations.

Gingerich noted that Bambu Lab is not only violating AGPLv3, but is also violating GPLv2 by not providing the source for a Buildroot-based Linux (and other copyleft components) used in the firmware of some 3D-printer models. He downloaded the 300MB firmware image from the Bambu Lab web site, but was unable to find the source or an offer to provide it.

He said that Bambu Lab comes from a silicon-valley-inspired culture that is being built in China, which includes large venture-capital-like investments into companies. Bambu Lab has deep pockets, which allowed it to leapfrog its competitors in various ways, market its products extensively through social media and the like, and to exert control over the message about its products on forums like Reddit. The company took some of the same shortcuts that silicon-valley companies have taken by "violating copyleft licenses on the way".

Gingerich thinks this situation provides "a very good opportunity" to "take back the control that we are owed by the licenses that they chose to use". Bambu Lab could have spent its investment on "reimplementing things from scratch", but it chose not to; there is a large body of high quality free and open-source software available that "takes a long time to replicate".

Bambu Lab has effectively taken the common "then, sue us" approach to these violations, which is certainly an option, Gingerich said. But various ways to remedy these kinds of problems have different timelines; getting the community involved in reverse-engineering and replacing the proprietary pieces will likely take a lot less time than a lawsuit. Kühn noted that companies in violation never actually say "sue us", instead they just stop responding.

Participation

Sandler said that one of the reasons these violations are so interesting is that they have brought more new people into the FOSS community than any other matter that SFC has worked on over the years. People who had never really heard of copyleft or FOSS are excited about it; now they "realize that these licenses grant rights and that we can do something with it". Normally, when the SFC is talking about these kinds of issues, she said, it is talking to the people in the room, or those who will view the recorded video of the session, which is "a narrow set of people and we struggle to explain what the potential is". But the 3D-printing community has really taken the ball and run with it; "multiple YouTubers were putting out deep explanations" and commenters at Reddit and elsewhere were "getting so excited and saying 'wow, this is what these licenses mean, we should use them more!'".

That left more than ten minutes for audience questions, the first of which was "what would make Bambu follow the AGPL?" Gingerich said that there are variety of approaches, including lawsuits like the SFC's versus Vizio (now owned by Walmart); since copyleft licenses are also contracts, that lawsuit is based on contract law. There is a contract between Vizio/Walmart and the software developers who created the GPLv2 and LGPLv2.1 code that was used in televisions; the SFC (and anyone who buys a Vizio TV) are "third-party beneficiaries" of that contract and the SFC is suing to get the rights that are required by it.

Enforcing contracts in this way is standard practice, Kühn said, but has not been used for the GPL family of contracts as far as they know. The more traditional route to enforcement is to sue as a copyright holder in the code, which is what the SFC has done in the past. There are other mechanisms, including using various trade agreements with their "intellectual property" clauses as a tool. While intellectual-property rules may be distasteful, that is in keeping with the original intent of copyleft: "to take any rule like that, flip it around, and use it to defend software freedom".

In conjunction with its work on 3D printing, the SFC ran a fundraiser that ended up far exceeding the lofty goal of $250,000 that was set, Kühn said; it was "a target that we thought we probably would never make". Sandler said: "we picked a number that we thought we could actually accomplish something significant with it", even though there was a good chance that it would not be reached. "We blew past it and most of our donations were teeny tiny donations", which was exciting. Kühn noted that the SFC is now able to hire a full-time litigation attorney; he encouraged attendees to ensure that the word got out.

Many people think that a GPL license is "magic pixie dust", Sandler said; by choosing the license, it will make people follow it and the problem is solved. That is obviously not the case, which was evident from the emphatic head shakes from attendees. "If nobody holds anybody's feet to the fire, if nobody says 'wait a minute, you're not actually doing this', no one ever will do it."

There are multiple ways to pursue enforcement, which requires some creativity, she said. The SFC is trying to "demonstrate the different ways that you can go about getting companies to do the right thing". She advocates that everyone ask for the complete and corresponding source code for all of the devices they purchase; it will demonstrate that there is consumer demand for those rights. An unhappy YouTube video or thread on Reddit if the source code is not released is also a form of enforcement, she said.

Another question was about whether litigation was an effective tool for enforcement. Gingerich noted that a source release from an enforcement action against Linksys was the first commit for the OpenWrt project. It leads to projects that "help us take control of our devices so they do what we want, and not what the companies that sell them want".

In addition, the house lawyers for companies regularly thank Sandler for lawsuits because it makes their jobs a lot easier, she said. If there are no consequences for violating the license, company lawyers have a hard time ensuring compliance. The business side of the company wants to know what the costs are for violating the license, "without lawsuits, there is no answer to that".

The final question was about fixing the root cause of license violations, which can be interpreted in lots of different ways. Kühn said that fixing societal corruption worldwide was a tall order; the same goes for fixing capitalism, Sandler added. The underlying problem is one of power imbalance, Gingerich said, which is something that FOSS and the larger right-to-repair movements are working against. Sandler closed by saying that the goal of these movements is to attack the root cause by bringing about a better world, with improvements in products, technology, and legislation; that requires getting actively involved and helping non-technical people to become invested in these issues as well. That seems like a rather tall order as well, of course.

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

Comments (29 posted)

Considering the OpenMDW license

The open-source world has been struggling for a few years now to understand how to approach large language models (LLMs) and the licensing applied to them. What constitutes "freedom" with respect to a black box filled with numerical weights? The process taken by the Open Source Initiative (OSI) in the development of its Open Source AI Definition was controversial at best, as was its output. Now, the Linux Foundation's Mike Dolan has brought a new license to the OSI for approval. It is called the OpenMDW ("Open Model, Data, and Weights"), and it aims to clarify licensing for the distribution of LLMs and related materials, but consensus is proving hard to find for this license as well.

The motivation behind this new license, Dolan explained, was that model distributions bundle together a number of different artifacts, including software, model weights, documentation, and more. Existing licenses are focused on software and were not intended for other types of artifacts; they also tend not to address the question of the output of models at all. The OpenMDW is an attempt to make it easier for distributors of open models to place everything under a single license. This 2025 blog post describes the motivations behind an earlier version of the license in more detail.

At its core, the OpenMDW is a permissive license, similar to the MIT license. There are a few differences, though. It has a clause saying explicitly that the license does not impose any sort of restrictions on any output created by the model. It casts a wider net than typical free-software licenses in that it grants use to "all copyright, patent, database, and trade secret rights" represented by the model distribution. What the granted rights actually cover, though, is somewhat fuzzy; the all-caps disclaimer section makes it clear that the distributor provides no guarantees in that regard. Indeed, the onus is put onto the user to determine whether they can, in fact, use the model at all:

YOU ARE SOLELY RESPONSIBLE FOR (1) CLEARING RIGHTS OF OTHER PERSONS THAT MAY APPLY TO THE MODEL MATERIALS OR ANY USE THEREOF, INCLUDING WITHOUT LIMITATION ANY PERSON'S COPYRIGHTS OR OTHER RIGHTS INCLUDED OR EMBODIED IN THE MODEL MATERIALS; (2) OBTAINING ANY NECESSARY CONSENTS, PERMISSIONS OR OTHER RIGHTS REQUIRED FOR ANY USE OF THE MODEL MATERIALS; OR (3) PERFORMING ANY DUE DILIGENCE OR UNDERTAKING ANY OTHER INVESTIGATIONS INTO THE MODEL MATERIALS OR ANYTHING INCORPORATED OR EMBODIED THEREIN.

Pamela Chestek questioned this text, describing that clearing as "an impossibility generally, and particularly if there is not even any disclosure of what the training materials are". She also said that this text could be read as a requirement imposed by the licensor — that if somebody is sued for a copyright violation involving the use of this model, they could, in addition to that trouble, be accused of having violated the license that allowed them to use the model in the first place.

The part of this license that has drawn the most attention, though, is this termination clause:

If you file, maintain, or voluntarily participate in a lawsuit against any person or entity asserting that the Model Materials directly or indirectly infringe any patent or copyright, then all rights and grants made to you hereunder are terminated, unless that lawsuit was in response to a corresponding lawsuit first brought against you.

Richard Fontana was concerned about the breadth of this clause, which covers both patent and copyright rights. Termination, he said, could affect far more than the specific material that is under dispute:

Not only does the license extend termination to copyright litigation, it also broadens the scope of termination by covering seemingly unrelated materials. For example, suppose I believe that an OpenMDW-1.1-licensed model infringes my copyrights. I sue the model licensor, but now my copyright and patent rights to some Python code distributed (in some sense) along with the model are terminated.

It is not uncommon for there to be multiple distributions of model weights intended for use by the same software base. If a copyright holder files a suit relating to a specific set of weights, they could lose access to all other models and the software used to run them as well. Fontana added that this termination of the license for unrelated materials could perhaps constitute a violation of section 9 of the Open Source Definition, which prohibits restrictions on unrelated software. In general, he expressed concerns that the "Model Materials" term, which is meant to represent the materials provided under the agreement, is not well defined.

Rob Landley wondered what would happen if a third party forks an OpenMDW-licensed project and incorporates some proprietary code into it; if the owner of that code then sues, would they lose access to the original project? Kevin Fleming, instead, pointed out a different potential problem: since it is (generally) impossible to know which data was used to train a model, the only way to determine whether it contains copyrighted material is by exercising the model itself. If a copyright holder sues over infringement, they will lose access to the model, which they need to produce the evidence to back up their suit. Simon Phipps said, simply, that "a license revoking Freedom 0 upon a copyright claim cannot assure software freedom".

Dolan responded that the termination clause is there to give symmetry to the license; it should not be possible to argue that a distribution is infringing while simultaneously enjoying the usage rights that distribution provides. But, he said, the legal position for model publishers is different from that of most software publishers, and that makes the addition of copyright to the termination clause necessary:

Models are built from large bodies of existing works, and that is where the model publisher's legal exposure arises. For those model publishers, the realistic assertion they face is that the licensed materials themselves infringe, and that infringement claim likely runs under copyright, not patent law. A patent-only provision in this context would replicate Apache-2.0's form while abandoning its function - there would not be symmetry.

Eric Schultz answered that the termination phrase constitutes "an amnesty for, depending on how courts rule, large scale copyright infringement by model creators". Fontana suggested restricting the termination to just the model weights at issue in this case. Chestek said that the license is not symmetric, because the producer of the model might know whether they have copied copyrighted materials, but the recipient has to give up any copyright claims without knowing, in advance, if their copyrights have been infringed.

The conversation has wound down, but without a clear outcome. It would seem that the OSI is not prepared to bless this license in its current form, but which changes would render it more acceptable have not really been specified, much less accepted by the proponents of the license.

In the end, the OpenMDW license seems to be aimed at reducing the risks associated with distributing an open (for some value of "open") model. Distributors would adopt this license in the hope of minimizing their chances of being sued for the violation of copyright or patent rights inherent in the model's training or seen explicitly in its output. A normal free-software license does not admonish the users of the covered software to ensure that said software is, itself, free of copyright problems. Use of the OpenMDW license may minimize the risk for distributors, but it also makes it clear that the use of LLMs may yet prove to be risky indeed.

Comments (6 posted)

How to be safe from quantum computing

Practical quantum computers have been ten years away for the last several decades. Now, however, it's beginning to look as though they will be possible in just a few years. Recent research with obfuscated results demonstrated much lower memory requirements to factor ECDSA keys on a quantum computer, with work by other researchers in the open more than halving memory use compared to the state of the art in 2023. At the same time, computer manufacturers are boasting quantum processors that retain viable superpositions over longer periods. Given how slowly software updates filter out to stable systems, it's worth looking at what configuration changes and protocol updates are needed to be safe from quantum computers now.

What is the threat?

Quantum computers are not faster than classical computers in general (although they can invert general black-box functions more quickly, which is important to some cryptographic applications). Rather, there are specific problems, such as integer factorization, that are believed to be difficult on classical computers that quantum computers can solve more efficiently. Unfortunately, much of our modern cryptographic infrastructure relies on the hardness of these problems.

Modern cryptography is generally divided into two areas: symmetric-key and non-symmetric-key cryptography. The former relies on all involved parties having a shared secret, and is not believed to be vulnerable to analysis by a quantum computer. The problem is obtaining a shared secret in the first place; users generally want to be able to connect to many different web sites, to exchange email with many different people, etc. Establishing a shared secret with each of them would be difficult.

This is where non-symmetric-key cryptography (also called public-key cryptography) comes in. These are cryptographic protocols that work without any shared secrets; instead, participants have a public key, which is known to the whole world, and a private key, which is known only to themselves. Encryption can be done with one of the keys, and then decryption is only possible with the other. Cryptographic signatures work by encrypting a known value with the private key, proving that whoever made the signature must have had the key. The security of these cryptosystems inherently depends on there being problems that are hard to solve with just the public key, but which become easy to solve with access to an additional piece of secret information.

The original public-key cryptosystem was RSA, which relies on the difficulty of factoring large numbers — a task that the scientific community theoretically knows how to do quickly on a quantum computer. Later, RSA was partially displaced by elliptic-curve cryptography, which relies on a closely related problem called the discrete log problem, but which uses much smaller keys.

Currently, the best publicly available quantum processor offers 1,121 physical qubits. IBM's published quantum-computing timeline promises that its Kookaburra processor, with 1,386 physical qubits, will be finished by the end of 2026. Even if the company is over-promising, the last few months have seen the best known quantum circuit for factoring ECDSA keys fall from 1,425 logical qubits to 1,154 logical qubits. But there is a difference between physical and logical qubits. Even the most well-isolated quantum computers are affected by noise from their environments, which adds error to the value of the computer's qubits that must be corrected or compensated for. The best known quantum error-correction techniques need about 500 physical qubits to emulate one logical qubit with reasonable fidelity; that number will go down with both additional algorithmic breakthroughs and better physical chips.

Inspired by this trend, for many years cryptographers have been working on other public-key cryptosystems based on problems that are not known to have an efficient solution on quantum computers. Recently, they've settled on and standardized a handful of cryptosystems that are believed to be robust enough for general use.

The challenge facing the open-source community, then, is deploying these new cryptosystems in all of the places that use public-key encryption and signing. Of these two tasks, encryption is more urgent: things being encrypted today may be attacked tomorrow, but signatures validated today can be trusted, because any quantum forgeries will occur in the future. Both use cases do need to be addressed eventually, however, and public-key cryptography comes up in a surprising number of places.

One slight wrinkle is that the newly invented quantum-resistant cryptosystems do not yet have a long track record of use. Cryptographers believe that they are secure, but there could turn out to be some flaw enabling classical or quantum computers to break them. While there is probably no harm in moving directly to post-quantum cryptography, the conservative approach is to use a hybrid scheme: encrypt things with both a well-known elliptic-curve cryptosystem and a newer post-quantum cryptosystem. As long as at least one of those encryption schemes remains secure, the whole construction is secure. Therefore, the encryption scheme that web browsers, OpenPGP implementations, and other encryption software are moving toward is a combination of ML-KEM-768 (the NIST-standardized post-quantum encryption scheme) and X25519 (an elliptic-curve cryptosystem in wide use today). Various government agencies have pushed for allowing the use of non-hybrid encryption schemes, but for now most software seems to be defaulting to X25519MLKEM768.

Web browsing

The largest use of public-key cryptography in the modern world is probably web browsing. Luckily, all major browsers now support using post-quantum cryptography to encrypt TLS connections. It has been enabled by default since Firefox 132 (released in October 2024), Google Chrome 131 (released November 2024), and Safari 26 (released in September 2025). All three support the X25519MLKEM768 key-exchange mechanism.

More difficult is rolling out the use of these key-exchange mechanisms to web servers. Most web servers, such as Apache HTTP Server and NGINX, delegate cipher management to OpenSSL, which has supported post-quantum key-exchange mechanisms since version 3.5.0, released in April 2025. Users stuck on earlier versions of OpenSSL can add support for newer ciphers using the oqs-provider library from the Open Quantum Safe project. Web servers that rely on OpenSSL typically have a way to send configuration options to OpenSSL's SSL_CONF_cmd() function; in the absence of such an override, OpenSSL will default to the settings given in the openssl.cnf configuration file.

On the Red Hat family of distributions and on openSUSE, that configuration file is generated by the crypto-policies mechanism. Users add policies to /etc/crypto-policies and then regenerate the OpenSSL configuration file using update-crypto-policies. This will also generate updated configurations for other encryption libraries such as LibreSSL, and for some software that handles its own encryption formats such as OpenSSH. Releases after Fedora 43 and Red Hat Enterprise Linux 10.1 should default to preferring post-quantum cryptography. Older releases will require setting a backported default policy or manually editing the Groups directive in the appropriate policy module:

    # The policy may be named differently depending on distribution and version
    update-crypto-policies --set DEFAULT:PQ

Debian, Ubuntu, Arch Linux, and others have the user edit openssl.cnf directly. Debian and Ubuntu both have ports of crypto-policies, but they aren't enabled by default. Users of alternate encryption libraries on these distributions may need to update their configurations as well. None of the distributions currently default to preferring post-quantum cryptography in the configuration file, but installations with a new enough version of OpenSSL may end up using OpenSSL's own defaults, which do prefer it.

Some web servers, such as Caddy, use an embedded library rather than relying on the distribution's OpenSSL library. In Caddy's case, post-quantum cryptography is enabled by default whenever it is built using Go 1.24 or newer.

Overall, the safest approach to enable support for post-quantum cryptography on one's web server is to explicitly set the supported Groups given to SSL_CONF_cmd() to include "X25519MLKEM768". That only affects the individual web server, however, and may fall out of date if better post-quantum cryptosystems are found. Setting policy on a system-wide level covers other uses of OpenSSL, but has the same update problem. Relying on OpenSSL's own defaults will always result in one of the most recent ciphers, but it is easy for a changed default configuration from one's distribution to silently override.

OpenPGP

While web browsing is probably the most common activity that uses encryption, digital signatures are arguably more important to the security of modern Linux systems. Packages are typically accompanied by OpenPGP signatures to guarantee that they really do come from the distribution's package repository; individual Git commits or tags may also be signed to indicate that they come from a trusted individual. Given that many keys have a lifetime of years, it may be wise to begin moving to post-quantum signatures well in advance of any possible forgery.

Unfortunately, the OpenPGP ecosystem has been split in two since 2023. The GNU privacy guard (GPG), which is widely used by Linux distributions, started following a specification called LibrePGP, while several other tools continued to follow the IETF-standardized OpenPGP. The two standards disagree on how to implement post-quantum cryptography, which makes verifying signatures made with one set of software using the other tool slightly painful.

OpenPGP's approach is given in RFC 9980 ("Post-Quantum Cryptography in OpenPGP"). It adds seven new algorithms, four of which are hybrid algorithms. For encryption, it allows either ML-KEM-768 paired with X25519, matching the recommended default for web browsers, or ML-KEM-1024 paired with X448, which has slightly larger keys and signatures but may provide better security. For signing, the same underlying algorithms are used, but they are given different names and parameter choices that are optimized for signatures. Either ML-DSA-65 (corresponding to the security level of ML-KEM-768) and Ed25519 or ML-DSA-87 (corresponding to the security level of ML-KEM-1024) and Ed448 can be used.

The RFC requires these keys to be encoded in the new v6 key format specified in RFC 9580 ("OpenPGP"), which GPG does not support. There is one carve-out permitted by RFC 9980: implementations usually skip PGP subkeys that have unrecognized algorithms, so it allows creating v4 OpenPGP keys with post-quantum subkeys. Version 4 keys are compatible with GPG, so this may be the most prudent option for interoperability, if GPG ever adds support for the relevant signing algorithms.

GPG only supports using post-quantum keys for encryption; there are no separate signing key algorithms. When used to create such an encryption key, it uses the same underlying encryption algorithm (ML-KEM and an elliptic curve of choice), but stores the key and binds it to the user's identity information in an incompatible way. Specifically, ML-KEM defines a way to ensure that two devices believe they are using the same protocol in order to understand each other's keys by mixing a static set of protocol information into the key-derivation function. GPG uses a different set of static information than the IETF standards specify. Sequoia and other OpenPGP implementations cannot understand GPG's native post-quantum keys and vice versa.

Some other encryption software, such as RNP, the OpenPGP engine that powers Thunderbird's email encryption, uses GPG's LibrePGP key format, but makes an exception for understanding post-quantum v4 subkeys. To make the situation even more confusing, Sequoia provides a "GPG chameleon" which implements the GPG command-line interface, so users running gpg may actually be talking to Sequoia.

Practically, the simplest workaround is to create two separate PGP keys, one using classical signing algorithms and one using the RFC 9980 signing algorithms, and sign everything with both of them. This is the approach that Red Hat has been using for package signing, and it does work, at the cost of requiring signers to maintain two separate PGP identities. Theoretically, a v4 PGP key with a post-quantum subkey could be used, but, due to the limitations of the format, only for encryption and not for signing.

Users who want to make sure that their signatures are quantum-resistant should consider switching to Sequoia (possibly using the chameleon, to keep the interface the same), generating a v4 classical signing key (or reusing an existing key), generating a v6 post-quantum signing key, using both keys to endorse each other, and signing everything important with them both. This is certainly not ideal; we can hope that a better solution emerges before it becomes truly urgent.

For now, verifying this kind of dual-signature is straightforward: as long as either signature is valid, it can probably be trusted. But once it becomes possible to forge some RSA and elliptic-curve signatures with a quantum computer, consumers of signatures will have to either verify only the post-quantum signature, or use some kind of certificate transparency mechanism to make sure that the classical signature was made before such a quantum computer became available.

The only real solution

There is, of course, one option that offers complete protection against any kind of cryptographic attack, no matter how powerful: give up and go live in the woods. For those of us who do not have that option, we will just need to settle for hoping that configuring OpenSSL and our OpenPGP software of choice appropriately is sufficient, and keeping an eye out for the tipping point when quantum attacks become possible.

Comments (29 posted)

The beginning of the 7.3 merge window

As of this writing, 2,346 non-merge changesets have been pulled into the mainline repository for the 7.3 kernel release. That, clearly, is a mere down payment on the flood that is to come. Even so, those early pulls brought in some noteworthy changes, including (but not limited to) a significant reworking of how group scheduling works on multiprocessor systems.

The most interesting changes pulled in the early part of the 7.3 merge window include:

Architecture-specific

• The Alpha architecture is now supported by the nolibc library.
• Support for a number of 32-bit Arm CPUs has been deprecated; see this merge message for the details. These systems will remain supported for at least the 7.3 release (which is expected to be a long-term-support release), but may be removed thereafter.
• Rust support has been added for PowerPC systems.
• The x86 "SMP alternatives" code has been removed. This feature would, when booting the kernel on a uniprocessor system, patch out the locking instructions needed on multiprocessor systems. As the relevance of uniprocessor systems has decreased, the cost of maintaining this feature has increasingly been seen as exceeding its benefit.

Core kernel

• The kernel's binfmt_misc mechanism, which allows the configuration of interpreters for executable files, has been significantly extended. There are now BPF hooks that can determine which interpreter to use at run time, allowing for hermetic binaries and other interesting applications.
• There have been some subtle but significant changes to how CPU time is allocated when group scheduling is being used. In current kernels, a task's weight (essentially the portion of CPU time it gets relative to other tasks running on the same CPU) is scaled by how much of that task's control group is running on that CPU. If CPU 0 is running one task in a group that has four equal-weight tasks, then that one task's weight will be scaled by 1/4. That scaling is intended to maintain fairness when tasks are unequally distributed across CPUs, but it can, with large systems, lead to tiny scaling factors. That, in turn, distorts the competition for CPU resources between tasks, and can stress the limits of the integer values used to represent scaling factors. See this commit for a detailed description of this algorithm and its problems.

  Scheduler maintainer Peter Zijlstra has put a fair amount of work into rethinking this scaling, resulting in the addition of a new tuning knob allowing the administrator to choose between several new scaling modes. This knob, called cgroup_mode, currently lives within debugfs; it is not clear whether it will stay there or whether it will eventually be useful enough to move into sysfs. The pre-7.3 behavior can be had by setting this knob to smp.

  The new up (uniprocessor) mode disables the scaling, as if a uniprocessor system were in use; "this is not a very good policy because it gets the SMP weight distribution wrong". The max mode assumes that all tasks are maximally concurrent, and adjusts the scale factor by the number of CPUs available to each task. That addresses some of the numerical problems, at the cost of creating artificially high weights in low-contention situations. The concur mode addresses that problem by adjusting by the lesser of the number of available CPUs and the number of runnable tasks in the group. This mode, Zijlstra said, behaves like smp with low contention, but approaches max as the number of runnable tasks reaches the number of CPUs. Finally, the tasks mode adjusts only by the number of runnable tasks: "This is an entirely valid and workable option, it is however wildly different from the traditional meaning."

  The default value for this new knob is set to concur, meaning that 7.3 will schedule control groups differently than previous kernels. The changelog says: "Since things are configurable, change the default and hope this serves more people than it hurts, esp. in the longer run." The final change in this series is a move to a single run queue for control groups; this is a large internal reimplementation that, it is hoped, will reduce the scheduler's overhead and address some latency problems.

• There is a new sysctl knob, called syscall_user_dispatch, controlling whether the system-call user dispatch feature (which allows, on x86 systems, one process to intercept system calls made by another) is enabled; the default is to enable the feature.

Filesystems and block I/O

• Support for the Extent File System (EFS), an early filesystem used on SGI systems, has been removed. There has been no significant maintenance of this filesystem for decades, and it is believed to be entirely unused. Also removed is support for the FreeVxFS filesystem, which was used by SCO UnixWare systems.
• The new "failfs" filesystem will fail any operation that is attempted within it. From the changelog:

  This lets tasks shed their filesystem state completely. A process with its root directory or working directory in failfs must anchor every path lookup at an explicit file descriptor or is doomed to fail any lookup. Absolute paths, absolute symlinks, and AT_FDCWD-relative lookups simply fail.

  A process located within a failfs root can only open files relative to an already-open file descriptor. See Documentation/filesystems/failfs.rst for more information.

• The fchdir() system call accepts a new special file-descriptor value, FD_FAILFS_ROOT, that causes the process's working directory to be changed to the failfs root.
• The new fchroot() system call is a version of chroot() that accepts a file descriptor representing the target directory. If that file descriptor is FD_FAILFS_ROOT, the process will be moved to a failfs root.
• The overlayfs filesystem now supports id-mapped mounts; see this changelog for more information.
• The kernel has better support for mounting multiple filesystems from a single block device — something that the EROFS filesystem already does.

Hardware support

• Hardware monitoring: Apple SoC power-state managers.
• Miscellaneous: Qualcomm Peripheral Authentication Service TEE interfaces.

Networking

• The new bpf_sock_read_xattr() kfunc allows a BPF program to read user.* extended attributes from a socket inode. There is no documentation; see this changelog for a bit more information.

Internal kernel changes

• The iomap layer, which handles the mapping between files on disk and their representation in memory, has been extensively reworked, causing this recent iomap article to be somewhat obsolete. Rather than providing iomap_begin() and iopmap_end() callbacks, a filesystem provides a single iomap_next() to iterate through a mapping. Alas, these changes are painstakingly undocumented, leaving the limited in-kernel documentation obsolete as well.
• Kernel threads now live in their own nullfs filesystem rather than sharing filesystem state with user space; see this article for more information.
• The kernel's internal cryptographic library has gained support for a number of AES encryption modes. See this merge message and the libcrypto documentation for more information.
• There has been a steady set of improvements to Rust support in the kernel, including a better abstraction for module ownership, a module for lossless integer conversions, obfuscated logging of pointer values to prevent address leaks, some pin-init improvements, and more. See this merge message for an overview. Beyond that, Rust support for synchronize_rcu(), memory barriers, enabling and disabling interrupts, and interrupt-disabled spinlocks has been added.

There are still 12,640 non-merge changesets sitting in linux-next, almost all of which can be expected to flood into the mainline before the closing of the merge window on August 30. Expect an update on the other changes in 7.3 shortly after that date.

Comments (16 posted)

Old-school calendaring at the command line with Remind

Remind is a command-line calendar and alarm program, with an optional Tk-based graphical interface, for Linux and Unix-like operating systems. It has its own scripting language that allows users to create reminders that are difficult (if not impossible) to specify in other calendaring programs. It is wholly unsuitable for use in corporate environments that require calendar sharing and exchanging meeting invitations; however, it may be precisely the calendaring tool for users who prefer the command line and fast, flexible tools that can help keep track of messy schedules.

Mesozoic calendaring

According to The Book of Remind by Remind's author, Dianne Skoll, the first version was created in late 1989: "the Mesozoic era of computing". In 1990, she gained access to Usenet and decided to release the source code for Remind on comp.sources.misc for all to enjoy. Skoll has had what she calls an "unhealthy obsession with calendar software" that has led her to keep working on Remind ever since, except for a short break from 2005 to 2007.

Remind is actually a collection of several programs released under the GPLv2: the main remind command-line utility, the TkRemind (tkremind) graphical front-end, and helper utilities such as Rem2HTML and Rem2PDF that create printable calendars from Remind output. All of the applications are written in C with minimal dependencies. TkRemind requires Tcl/Tk and the standard Tcl library (tcllib). The Rem2HTML and Rem2PDF utilities require a couple of Perl modules.

The project is, essentially, a one-person show; according to the Git history, which includes pre-Git commits back to 1996, Skoll has accepted only 13 commits from other authors. The official repository is hosted on a Forgejo instance (a username and password, both "notabot", are required due to AI scrapers), with mirrors on Codeberg and Debian's Salsa.

Remind is available in the package repositories of most major Linux distributions, though Arch Linux's package is missing the tcllib dependency needed for TkRemind. Users who want to use TkRemind, Rem2HTML, or Rem2PDF on Arch will need to look to the Arch User Repository (AUR) or compile directly from source.

Remind scripts

As befits a utility from the Mesozoic, remind reads a text file containing a reminders script and sends reminders to standard output. The name of the file is unimportant, but TkRemind defaults to ~/.reminders, so that is the convention that I use. Remind uses a date-specification language that is fairly intuitive for simple events, but also allows users to set reminders that would be out of the question for desktop calendar applications like Evolution or Thunderbird Calendar.

When remind is run, it evaluates the script according to the current time and issues reminders that match a command's trigger date (see the trigger computation section of the man page for more on that). Here is a simple example that will set a reminder to send a TPS report to the boss every Friday, and a reminder that displays on August 21 about dinner plans.

    REM Friday MSG Send Mr. Spacely the weekly TPS report.
    REM 21 Aug 2026 AT 17:00 MSG Dinner at Blue Mountain Pizza in %1.

This is mostly self-explanatory: a reminder command begins with REM, and some expression of when it should occur. Remind has other types of commands, some of which we'll cover shortly. The next part of the command is the date specification. A day of the week, without any other information, will cause remind to issue a reminder every week on that day. A specific date, like "21 Aug 2026" will issue a reminder just on that day. Note that Remind is reasonably liberal in what it accepts as date input—it interprets "Aug 21", "21 Aug", "August 21 2026", and "2026-08-26" as the same date if run on August 21, 2026. Obviously, if one is specifying dates far enough in the future, it is a good idea to include the year as a matter of habit.

The text that follows MSG is the message that will be displayed. The "%1" in this example is a substitution filter that will be replaced with a countdown from "now"; that is, the message will contain a specific countdown of when the event will occur from the moment that Remind is run. The output from the example above would look something like this:

    $ remind .reminders
    Reminders for Friday, 21st August, 2026 (today):

    Send Mr. Spacely the weekly TPS report.

    Dinner at Blue Mountain Pizza in 6 hours and 41 minutes from now.

Of course, if Friday is a holiday or vacation day, then it will be necessary to send the TPS report earlier, later, or skip it entirely. Remind makes it possible to account for this with the OMIT command coupled with keywords such as AFTER, BEFORE, and SKIP. For instance, this example indicates that the TPS report should be skipped if it lands on a date that has been omitted, such as December 25—which just happens to land on a Friday this year.

    OMIT 25 December
    REM Friday SKIP MSG Send Mr. Spacely the weekly TPS report.

Note that a standalone OMIT command is considered globally; that is, it is considered for all REM entries with a SKIP keyword.

Remind can do more than emit messages; for instance, its RUN command can be used to run shell commands as well. This entry would run a backup script ("~/bin/backup.sh") every Friday, but only once:

    REM Friday ONCE RUN ~/bin/backup.sh

Note that Remind checks the last access date of the reminder script (e.g. "~/.reminders") to determine the last time it was run. That means that if a user edits the file later in the day, Remind will assume it hasn't been run that day. Using remind -r will avoid re-running any RUN commands.

Remind is intended as a calendaring program that reminds users about events, and is not designed as a task manager. It does, however, have a TODO keyword that can be used to provide a reminder of a task on the day it's due as well as before (and after) its due date. For example:

    REM TODO ++7 COMPLETE-THROUGH 24 Aug 2026 MAX-OVERDUE 3 MSG Big report due %b.

The "++7" tells Remind to start triggering the reminder seven days before the due date here. Note that "++7" will include omitted dates; to exclude omitted dates, use a single plus sign (e.g. "+7") instead. That entry will trigger a reminder for seven days prior to the due date and three days after. If the MAX-OVERDUE bit is not included, then it will trigger the reminder every day after the task is due until the entry is deleted. The %b is replaced with the actual number of days between the current date and the reminder's trigger date.

Many times it's desirable to have an event that recurs regularly until a certain date. For example, maybe there is an art class that meets outdoors and runs on Thursdays from June to September. Remind has an UNTIL keyword that allows the user to add that to their reminders until the last day of the class, like so:

    REM Jun 3 2026 *7 UNTIL Sep 1 2026 MSG Art class in the park.

These examples only scratch the surface of the Remind language and syntax. Like other programming languages, Remind's has variables, data types, operators, as well as built-in and user-defined functions. For instance, it has built-in functions for Easter, Hebrew calendar dates, the moon's phases, sunrise, sunset, and more. Adding the example below, taken from the Remind wiki (requires the "notabot" username and password), will show the sunrise and sunset times each day:

    SET $LongDeg 71
    SET $LongMin 10
    SET $LongSec 30
    SET $LatDeg 42
    SET $LatMin 20
    SET $LatSec 27
    MSG Sunrise at [sunrise(trigdate())], Sunset at [sunset(trigdate())], \
    next full moon at [moontime(2)] on [moondate(2)]%

Saved as moon.rem that example would produce output something like this:

    $ remind moon.rem
    Reminders for Friday, 21st August, 2026 (today):

    Sunrise at 06:53, Sunset at 20:10, next full moon at 00:19 on 2026-08-28

The script sets the variables for the user's location, which are used by the built-in functions to calculate the times for the next sunrise, sunset, and full moon. The trigdate() function returns the computed trigger date—in this case, August 21.

The Remind language is covered comprehensively in the remind man page and there are a number of examples in Skoll's book. Suffice it to say that it is easy to create reminders for the simple one-off and recurring events, as well as being possible to handle events that have exceptions due to holidays, are triggered by other events, or happen only once in a blue moon.

Remind has a few different modes of operation; agenda mode is the standard mode of operation. It runs the Remind script and prints the reminders that are triggered for that time and day. Users may also wish to generate a calendar to see a whole month at a time: remind -c filename will display a calendar in the terminal using ASCII characters, while the -cu option will display the calendar using Unicode box-drawing characters which look a little nicer.

It is also possible to generate a calendar that covers an arbitrary number of weeks by adding the +N option, where "N" equals the number of weeks. For example, remind -c+2 filename will display a two-week calendar. Remind can also produce JSON output using the -ppp option, which may be desirable if a user wants a standard format to use with another program. For example, users can run remind -ppp filename | rem2pdf > calendar.PDF, which will pipe JSON output to rem2pdf for conversion to a PDF calendar.

Look for the helpers

Remind is probably a program that will appeal most to people who enjoy working at the command line and editing plain-text files. However, TkRemind does provide a usable graphical interface for those who prefer the point-and-click method. The "Add Reminder..." feature, shown below, lets users create reminders with a fair amount of flexibility.

Users don't need to choose between the command-line utility and TkRemind, but entries created with TkRemind should not be edited manually. TkRemind adds a TAG entry to the reminders it creates to indicate that they should not be edited in other programs to avoid unpredictable results. The TAG keyword is used to add additional information to a reminder; when remind is run with a -p option, that tag is passed to the helper program (such as TkRemind) which can make use of the information. Otherwise, remind does not act on information in a TAG.

Over the years, there have been a number of third-party "helper" programs written to work with Remind as well, some of which are listed on the project's web site. This includes various scripts to convert Remind output to iCalendar format (or vice versa), tools to synchronize Remind with a CalDAV server, an Emacs major mode (remind-calendar.el), a web-based frontend written in PHP, and more.

In addition to Skoll's book and the remind man page there is also a remind-fans mailing list for users to discuss the use of Remind and ask questions, and a #remind IRC channel on the Open and Free Technology Community (OFTC) network. Remind is, perhaps, not for everyone, but it has its appeal for users who prefer flexibility and expressiveness over convenience.

Comments (16 posted)

A look at the Quickshell desktop-component toolkit

Quickshell is a toolkit for building desktop components, such as toolbars or menus. It uses QML, which is a declarative language for designing GUI applications. Quickshell helps developers create graphical tools for common desktop use cases with a focus on ease of development. It offers a convenient method for writing user interfaces and has been adopted by a number of projects, such as caelestia-shell and DankMaterialShell, that provide desktop environments for minimal window managers like Sway and niri.

A high-level toolkit

Quickshell arose from a need for easier methods to build interfaces for desktop components, such as a system tray or management interface for audio devices. Other toolkits can achieve similar results but require a significant up-front investment to gain familiarity with their development environments and libraries. As we will see below, it can be used to easily create utilities, such as a desktop launcher or toolbar, that are useful for a desktop environment.

The project's creator and lead developer "outfoxxed" tried existing solutions like Elkowar's Wacky Widgets (eww), another desktop widget system, but ran into challenges that prompted them to look elsewhere.

Their preference for Qt over GTK also led outfoxxed toward a custom solution that eventually became Quickshell. "Some time in December 2023 I was testing Qt Quick for viability in another project that never happened, and I noticed that it was really approachable since the language has features like automatic reactive bindings". That refers to property binding, which allows QML to propagate changing values through parts of its structure. For example, the text of a button does not need special treatment to reflect updates if its string value incorporates another value that changes in response to an event being triggered. The bindings QML establishes between properties handles updates by tracking dependencies that change over time and updating them as needed.

Qt and GTK are popular for writing desktop components on Linux. However, using them means writing lower-level code and involves compilation steps that incur delays during iterative development. Quickshell bridges the gap between desktop APIs and the Qt graphical toolkit. It also adds the ability to iterate rapidly when building desktop interfaces. With just Quickshell installed, users can create their own graphical interfaces with any of the types listed in its documentation, such as PopupWindow or SystemTray, available for use directly in QML documents, which are stored as .qml files. Although it's well-suited for minimalist desktops, it is also useful for creating desktop widgets and other utilities to be used with more full-fledged desktop environments like GNOME and KDE Plasma as well.

Additionally, while APIs for services like Pipewire are generally available on most Linux distributions, each API requires familiarity with those individual services to properly use them. Types like Pipewire provided by Quickshell make the process of working with these services much easier.

Quickshell had its first release, version 0.1, in June 2024. The most recent, version 0.3, was released in June 2026 with new API features for networking, polkit integration, as well as many other enhancements and bug fixes. It is packaged for many Linux distributions, though it is not available in Debian 13, but is in testing. Debian packages are also available on the Open Build Service. It is provided under the LGPLv3 and hosted on on GitHub, which is the primary channel for user contributions and issue tracking, with a mirror hosted on an independent Forgejo server.

Outfoxxed is the primary committer and reviewer, responsible for the bulk of development. However, community contributions like wired-networking support have helped to significantly improve the project. The project's contribution policy neither bans nor endorses the use of LLM-assisted coding but does require that changes are owned by human developers and forbids the use of completely automated tooling to contribute code.

A shell ecosystem

Minimalist compositors and window managers intentionally provide little more than the core capabilities needed to display and manage windows; users are left to their own devices to choose other components to build the desktop they want. Projects such as Waybar (which provides standalone toolbars) or Rofi (an application launcher) can close the gap. There are many other similar projects that provide specific features to window managers or compositors, but assembling a complete desktop environment from small applications takes some effort.

Popular Quickshell-based projects, such as caelestia-shell and DankMaterialShell, offer a middle ground. They do not provide feature parity with desktop environments, such as GNOME and Plasma, but they provide many of the features users might want from a desktop when using bare-bones compositors such as Sway and niri.

Desktop shells built with Quickshell are usually configurable with user-friendly graphical interfaces rather than text-based configuration files. Interfaces built with Quickshell can be styled via QML types that add effects like animations and styles. The DankMaterialShell theme gallery has many examples of how one might style Quickshell. DankMaterialShell also has support for plugins, which lets users add third-party widgets (or create their own).

Some of Quickshell's features depend upon the window manager or compositor in use. For example, using background transparency blurring in Quickshell while on Wayland requires a compositor that supports the ext-background-effect Wayland protocol. Support for modern Wayland compositors is usually consistent across projects that rely on foundational libraries like wlroots (Sway) and Smithay (such as niri and COSMIC). In the case of niri, for example, support for ext-background-effect was added on the 26.04 release.

A trove of types

QML is used to express the structure and function of interface elements that are managed by the Qt framework. Quickshell is configured via QML files that declare objects derived from the upstream QML types. These types are high-level abstractions that can be instantiated to create elements like buttons or windows.

The syntax of QML can be thought of as a layer of abstraction above using Qt directly. Elements are declared rather than constructed in an imperative style. For example, while Qt widgets like layouts and labels might be created like this in Python:

    from PyQt6.QtWidgets import (QGridLayout, QLabel)
    layout = QGridLayout()
    label = QLabel("Using Qt 6 in Python.")
    layout.addWidget(label)

The equivalent QML instead creates the desired structure declaratively:

    import QtQuick.Controls
    import QtQuick.Layouts
    GridLayout {
        Label {
            text: "Using Qt 6 with QML."
        }
    }

To support interactive elements like buttons, events are bound to scripts written in JavaScript that are compiled internally by the QML engine.

Quickshell extends the available QtQuick types with its own types that provide additional capabilities. (QtQuick is the standard library of types available for use with QML.) Many of the bundled Quickshell types serve as abstractions over common APIs and other desktop interfaces.

For example, Quickshell provides the Process type that is generally useful for running shell commands and capturing their output. However, the UPower type grants more convenient access to host information: rather than parsing files in /sys/class/power_supply to discover a battery's charge level, GUI elements can rely on the UPowerDevice.percentage property for a device.

Quickshell types like Bluetooth, Networking, and Sockets let developers work with high-level properties to easily make use of system state. For example, text content or the icon path of an object can react when the connected property of a Network type changes.

There are some tradeoffs in using Quickshell versus building natively with Qt or GTK. While QML may be embedded in different languages like Python or C++, QML scripting is limited to JavaScript (although developers can extend QML via some techniques with C++). GTK or Qt may be better suited for building interfaces with specific languages, or with more complex backend logic, where a greater degree of control is available.

QML and declarative interfaces

To illustrate a concrete example of a GUI built with Quickshell, the following minimal QML imports types from the QtQuick library and creates a Text object with its text property set to a static string value:

    import QtQuick
    
    Text {
        text: "Hello from Quickshell!"
    }

Quickshell will use the QML file ~/.config/quickshell/shell.qml by default when running the quickshell command, or specific QML files may be passed to quickshell with the -p/--path flag. Changes to the text property of the Text object will be reflected immediately when saving the shell.qml file. The resulting interface shown here is running on a default niri desktop configuration.

That is probably not very useful, by itself, however. The next example shows how to change shell.qml to bind events to JavaScript expressions and make an interface interactive. It builds a FloatingWindow with a stacked row layout comprised of a Text object and a Button. Clicking the button increments the customData variable tracking the number of clicks and updates the text property in response to the changing value.

    import QtQuick
    import QtQuick.Controls
    import QtQuick.Layouts
    import Quickshell
    
    FloatingWindow {
        property var customData: 0
        ColumnLayout {
            Text {
                text: `Clicks: ${customData}`
            }
            Button {
                text: "Increment"
                onClicked: customData += 1
            }
        }
    }

This example uses several types from the QtQuick imports in addition to the FloatingWindow type from the Quickshell namespace. Writing to the file is sufficient to prompt Quickshell to rebuild the interface and create a functional interactive window. Clicking on the Button element labeled "Increment" will dynamically update the Text object in the Quickshell window.

As a final demonstration of Quickshell's capabilities, the following QML uses DesktopEntries to retrieve Freedesktop.org desktop application specification files and construct a scrollable grid of buttons to launch corresponding entries, closing the launcher after selection.

The FloatingWindow also uses several Quickshell helper functions like Quickshell.iconPath to resolve icon paths and Quickshell.execDetached to run the desktop entry's executable in the background. The .execDetached function expects a list of arguments, passed here as an array with the desktop entry's execString as the singular element.

The GridView type works by accepting a collection of items passed to its model property (in this case, an array called DesktopEntries.applications) and instantiating a new object for every element in that collection. The delegate property controls how to consume each element of the collection: in this example, a new RoundButton object is created with the modelData variable available to retrieve other values like modelData.icon for the icon path of the desktop entry. The addition of a ToolTip provides application names as hover text when the mouse cursor is placed over the icon. Calls to functions like Qt.quit use the always-imported Qt namespace.

    import QtQuick
    import QtQuick.Controls
    import Quickshell
    import Quickshell.Widgets
    
    FloatingWindow  {
        title: "LWN Launcher"
    
        ScrollView {
            anchors.fill: parent
    
            GridView {
                id: grid
                cellWidth: 48
                cellHeight: 48
    
                model: DesktopEntries.applications
    
                delegate: RoundButton {
                    radius: 0
                    implicitWidth: grid.cellWidth
                    implicitHeight: grid.cellWidth
    
                    hoverEnabled: true
                    ToolTip.text: modelData.name
                    ToolTip.visible: hovered
    
                    contentItem: IconImage {
                        source: Quickshell.iconPath(modelData.icon)
                    }
    
                    onClicked: {
                        Quickshell.execDetached([modelData.execString]);
                        Qt.quit()
                    }
                }
            }
        }
    }

The end result is a simple grid of icon buttons that displays all installed desktop applications with Freedesktop entries. Importantly, the Quickshell widget is portable: most desktop applications install Freedesktop.org entries, and there are no window manager or compositor-specific elements to the QML. The overall result should be similar whether started from niri, Sway, Plasma, or any other standard desktop environment. There are countless ways to further customize this GUI or enrich it with additional features.

Conclusion

My own experience with Quickshell has been in combination with niri on NixOS. Although I originally wrote my own toolbars, launcher, and other elements, DankMaterialShell has now become my default desktop shell. Quickshell remains useful to write focused utilities that require GUIs like menus for scripts or silly proof-of-concepts. However, DankMaterialShell offers a degree of polish that might be hard to otherwise achieve on my own. As with many young projects, the main drawback tends to be the rapid pace of changes that occasionally necessitate manual intervention when plugins break or versions drift, but anecdotally, stability seems to be improving rapidly.

Both Quickshell and its related desktop-shell projects boast particularly well-written and comprehensive documentation for further reading. In addition to the documentation already linked, Quickshell provides an introduction to writing QML. The DankMaterialShell documentation includes useful guides for authoring plugins as well as how to manage and update an existing installation.

Quickshell is relatively new on the Linux desktop scene, but its quick adoption seems to be making an impact across Linux distributions and desktop environments.

Comments (18 posted)

Supply chain attack on arrayref (Rust blog)

The Rust blog reports on a malicious crate, called proc-macro1, that was uploaded to the crates.io repository.

Furthermore, we discovered that the popular arrayref crate had recently been republished and made to depend on this crate, with the most recent versions yanked. We have removed the malicious version and unyanked the maliciously-yanked versions. Other crates by that author (internment, append-only-vec) were also affected so we have done the same for those, and locked the account as a precaution. We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised, and we are attempting to contact them.

Comments (3 posted)

Security quote of the week

PyPI should be considered a supply chain risk until the PSF is able to hire more engineering staff. There is a very large amount of the software industry that sits on top of our services. Feature development, a rising volume of security reports, and day to day maintenance are currently being carried by one and a half full-time employees and one full-time employee on PyPI support requests.

— Jacob Coffee, director of engineering at the Python Software Foundation

Comments (1 posted)

Kernel release status

The 7.3 merge window is still open. It can be expected to close on August 30, 2026.

Stable updates: 7.1.10, 6.18.46, 6.12.105, 6.6.153, 6.1.184, 5.15.217, and 5.10.266 were released on August 23.

The relatively small 7.2.1, 7.1.11, 6.18.47, 6.12.106, 6.6.154, 6.1.185, 5.15.218, and 5.10.267 updates are all in the review process; they are due on August 27.

Comments (none posted)

Mourning Steve French

From Jeremy Allison we have the sad news of the passing of Steve French. He was the maintainer of the kernel's SMB filesystem code for many years, having only dropped that role due to health issues in the last week. "I've known Steve for over 20 years. He was a legend in the community, and a really good friend. He will be greatly missed. Farewell Steve." He will indeed be missed.

Comments (8 posted)

mklinux-v7.0-mk2 released

For people who would like to experiment with the multi-kernel Linux concept, Cong Wang has announced the release of mklinux v7.0-mk2.

mklinux lets one machine run several independent Linux kernels at the same time on bare metal, without a hypervisor. A host kernel owns a pool of CPUs, memory and PCI devices, carves that pool into instances, and boots a spawn kernel into each instance through kexec_file_load(). Every spawn kernel runs natively on its own CPUs, its own physical memory and its own devices. Nothing is emulated and nothing is trapped; the only thing shared is what you choose to share.

Note that this is not the old MkLinux, which was a port to PowerPC Macintosh systems.

Comments (2 posted)

Quotes of the week

I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust...

— Jakub Kicinski

So for years we suffered through git log full of single-line commit messages with no explanation whatsoever.

Now we get a git log full of useless noise.

I'm not sure whether we won anything on that front.

— Christian Brauner

Comments (3 posted)

Armbian 26.8 released

Version 26.8 of the Armbian distribution for Arm hardware has been released.

Most releases are a long list of small improvements. This one had three larger pieces landing at roughly the same time, and all three touch parts of Armbian that people use directly rather than parts they only read about in changelogs.

The installer was rewritten. Armbian Imager reached 2.0. And our CI moved out of the repository it had outgrown into one built for the job. None of these were planned to coincide; they simply reached the point where postponing them again would have cost more than doing them.

The installer rewrite is the one I expect people to notice first. It now ships as an armbian-config module, which means it is unit-tested, the same way the rest of armbian-config is tested, rather than living as a script that everyone was slightly afraid to touch. It can target SPI and MTD, treats eMMC and NVMe as separate flows instead of pretending they are the same thing, can flash a bootloader on its own, and — this one is overdue — reports when a bootloader write fails instead of printing "Done." and leaving you to find out at the next boot.

See the release notes for a full list of changes.

Comments (none posted)

Vanilla OS 3 released

Vanilla OS 3, an immutable desktop Linux distribution, has been released. Notable changes in this release include support for Arm64, introduction of a Vanilla OS SDK, a rewrite of the Apx package manager using the new SDK, and much more. LWN covered Vanilla OS 2 in 2024.

Comments (1 posted)

Distributions quote of the week

So, does monstrous hardware solve long RPM build times? Only marginally, and at an astronomical cost.

The reality is that sheer hardware scale is fundamentally bottlenecked by the software architecture. Neither rpmbuild itself nor the maintainer code inside %build sections can efficiently map to extreme, massive parallelism. You hit Amdahl's Law incredibly fast.

A final funny observation: Knowing that even on this 224-core monster the builds would take hours, I fired them up fully intending to go watch a movie on Netflix. Instead, I found myself completely mesmerized by btop and the output of ps axf. Watching process trees expand and collapse across 224 cores turned out to be far more entertaining than a Hollywood blockbuster.

— Miroslav Suchý

Comments (none posted)

Emacs 31.1 released

Version 31.1 of the Emacs editor has been released. There is a long list of changes including the removal of the Emacs dumper, a new user Lisp directory feature, a "Send to..." menu item in context-menu-mode, and many other changes; see the NEWS file for more information. Mickey Petersen, author of Mastering Emacs, also has a rundown of some of the quality-of-life features appearing in this release.

Full Story (comments: 4)

KDE Gear 26.08 released

Version 26.08 of the KDE Gear collection of applications has been released. Notable changes in this release include improvements in the signing features of Okular, improved file-grouping features in the Dolphin file manager, and a number of enhancements to the Kdenlive video editor. See the changelog for a full list of updates, enhancements, and bug fixes.

Comments (none posted)

LibreOffice 26.8 released

Version 26.8 of the LibreOffice suite has been released.

LibreOffice 26.8 concentrates on three areas: the typographic quality of what the suite produces, the range of writing systems it handles correctly, and the fidelity with which documents survive exchange with other office suites.

The largest single body of work in this release addresses bidirectional and complex text. Writer now detects paragraph direction automatically when documents or plain text are opened or pasted. Line wrapping places end-of-line spaces according to the direction of the paragraph rather than that of the adjacent characters. Object resize handles behave correctly in right-to-left and vertical CJK documents. Bidirectional control characters are now visible alongside other formatting marks. In Calc, typing right-to-left text into an empty cell sets the direction of that cell automatically.

See the release notes for a full list of changes.

Comments (4 posted)

RPM 6.1.0 released

Version 6.1.0 of the RPM Package Manager has been released. Notable changes include the ability to provide modifiers to RPM macros at definition time, improved build and verification error handling, support for signing files with PKCS11 tokens using rpmsign, as well as the addition of several new man pages. The 6.1.0 release also debuts a new release model inspired by the Linux kernel's.

Comments (1 posted)

Development quote of the week

We need to have a set of foundational tools that are "clean" in the sense that they are built upon a community of people that understand how they are built.

Maybe that's naive or even impossible. The Linux kernel and GCC, in particular, are massive projects that have long grown past the scale of a single person's understanding. But the theory was that a community of humans can understand collectively.

Now we seem to be throwing up our hands and giving up on that community. That LLMs will just fix the problem, whatever it is. But we're all just one rug pull away from being completely incapable of managing those projects. The argument there is that we'll just switch to local models, but no one is actually doing that. All I see is people use local models as a corner case (for privacy) or as in theory, but in reality, everyone uses the centralized frontier models right now. We just can't fall back.

We're in the same situation we were, a decade or two ago, when Microsoft decided it would kill free office alternatives by making Office free for non-profits. It worked: thousands, if not millions of schools, community groups and individuals stopped looking for alternatives (including free software but also "piracy") for Office and embraced what seemed like a generous offer.

Now Microsoft pulled the plug and Over 170,000 Nonprofits Lost All Their Data.

I'm afraid the rug pull on LLMs will be much worse: never mind that Linus won't be able to use his tireless helper to fix obscure kernel bugs; we're looking at a collapse of the economy so large that we are already talking about bailing out the companies responsible.

— Antoine Beaupré

Comments (none posted)

CFP Deadlines: August 27, 2026 to October 26, 2026

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

Deadline	Event Dates	Event	Location
August 31	October 2 October 4	GNU Tools Cauldron	Prague, Czechia
August 31	October 3 October 4	Linux Days 2026	Prague, Czechia
September 6	October 6	Real-time Linux User Forum	Prague, Czechia
September 6	January 20 January 22	Everything Open	Brisbane, Australia
September 18	September 19	Software Freedom Day NJ	Montclair, NJ, US
October 1	November 7 November 8	OpenFest 2026	Sofia, Bulgaria
October 1	November 12 November 13	Ubuntu Summit 26.10

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

Events: August 27, 2026 to October 26, 2026

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

Date(s)	Event	Location
August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland
August 30 September 5	FOSS4G Hiroshima 2026	Hiroshima, Japan
September 8 September 10	RustConf 2026	Montreal, Canada
September 17 September 18	Git Merge	Lisbon, Portugal
September 19	Software Freedom Day NJ	Montclair, NJ, US
September 19 September 20	Nextcloud Community Conference 2026	Berlin, Germany
September 19 September 24	Akademy 2026	Graz, Austria
September 22 September 24	Kernel Recipes	Paris, France
September 22 September 24	Reproducible Builds Summit	Gothenburg, Sweden
September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
September 28 September 30	X.Org Developers Conference	Toronto, Canada
September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
September 30 October 1	All Systems Go! 2026	Berlin, Germany
October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
October 2 October 4	GNU Tools Cauldron	Prague, Czechia
October 3 October 4	openSUSE.Asia Summit 2026	Yogyakarta, Indonesia
October 3 October 4	Linux Days 2026	Prague, Czechia
October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
October 6	Yocto Project Developer Day 2026	Prague, Czechia
October 6	Real-time Linux User Forum	Prague, Czechia
October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
October 8	Linux Security Summit Europe	Prague, Czechia
October 14 October 17	PyCon South Africa	Cape Town, South Africa
October 16 October 18	VideoLAN Developers' Days	Rome, Italy
October 18 October 20	All Things Open	Raleigh, NC, US
October 20 October 23	PostgreSQL Conference Europe	Valencia, Spain
October 20 October 23	The Matrix Conference	Malmö, Sweden

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

Alert summary August 20, 2026 to August 26, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:58555	8	NetworkManager	2026-08-25
AlmaLinux	ALSA-2026:58572	9	NetworkManager	2026-08-25
AlmaLinux	ALSA-2026:57148	10	ansible-core	2026-08-21
AlmaLinux	ALSA-2026:57149	9	ansible-core	2026-08-20
AlmaLinux	ALSA-2026:55442	9	bind9.18	2026-08-19
AlmaLinux	ALSA-2026:57451	8	cups-filters	2026-08-21
AlmaLinux	ALSA-2026:58560	9	cups-filters	2026-08-25
AlmaLinux	ALSA-2026:57462	8	curl	2026-08-21
AlmaLinux	ALSA-2026:58898	8	firefox	2026-08-26
AlmaLinux	ALSA-2026:57015	10	glib2	2026-08-20
AlmaLinux	ALSA-2026:56521	8	gstreamer1-plugins-bad-free	2026-08-19
AlmaLinux	ALSA-2026:59097	10	gstreamer1-plugins-base	2026-08-25
AlmaLinux	ALSA-2026:59487	8	gstreamer1-plugins-base	2026-08-26
AlmaLinux	ALSA-2026:56966	8	gstreamer1-plugins-good	2026-08-20
AlmaLinux	ALSA-2026:59179	8	gstreamer1-plugins-good	2026-08-25
AlmaLinux	ALSA-2026:55775	8	java-1.8.0-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55775	9	java-1.8.0-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55781	8	java-17-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55781	9	java-17-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55787	10	java-21-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55787	8	java-21-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55787	9	java-21-openjdk	2026-08-21
AlmaLinux	ALSA-2026:55798	9	java-25-openjdk	2026-08-24
AlmaLinux	ALSA-2026:57597	10	kbd	2026-08-21
AlmaLinux	ALSA-2026:57610	9	kbd	2026-08-21
AlmaLinux	ALSA-2026:57251	10	kernel	2026-08-25
AlmaLinux	ALSA-2026:57253	8	kernel	2026-08-21
AlmaLinux	ALSA-2026:59821	8	kernel	2026-08-26
AlmaLinux	ALSA-2026:57254	8	kernel-rt	2026-08-20
AlmaLinux	ALSA-2026:59737	8	kernel-rt	2026-08-26
AlmaLinux	ALSA-2026:56965	10	libcupsfilters	2026-08-20
AlmaLinux	ALSA-2026:57596	10	mrtg	2026-08-24
AlmaLinux	ALSA-2026:57600	9	mrtg	2026-08-25
AlmaLinux	ALSA-2026:56007	10	mysql8.4	2026-08-19
AlmaLinux	ALSA-2026:56936	8	mysql:8.4	2026-08-20
AlmaLinux	ALSA-2026:59220	10	nginx	2026-08-25
AlmaLinux	ALSA-2026:59216	8	nginx:1.24	2026-08-25
AlmaLinux	ALSA-2026:58819	10	nodejs24	2026-08-25
AlmaLinux	ALSA-2026:55617	10	pcp	2026-08-19
AlmaLinux	ALSA-2026:55560	8	pcp	2026-08-19
AlmaLinux	ALSA-2026:55740	9	pcp	2026-08-20
AlmaLinux	ALSA-2026:56971	10	perl-Date-Manip	2026-08-20
AlmaLinux	ALSA-2026:57562	8	perl-Date-Manip	2026-08-21
AlmaLinux	ALSA-2026:56970	9	perl-Date-Manip	2026-08-25
AlmaLinux	ALSA-2026:56969	10	php8.4	2026-08-20
AlmaLinux	ALSA-2026:47750	8	php:7.4	2026-08-19
AlmaLinux	ALSA-2026:47749	8	php:8.2	2026-08-19
AlmaLinux	ALSA-2026:57574	8	php:8.2	2026-08-21
AlmaLinux	ALSA-2026:40416	9	php:8.2	2026-08-19
AlmaLinux	ALSA-2026:48197	9	php:8.3	2026-08-19
AlmaLinux	ALSA-2026:57539	9	php:8.3	2026-08-21
AlmaLinux	ALSA-2026:59243	10	python-pyasn1	2026-08-25
AlmaLinux	ALSA-2026:59241	8	python-pyasn1	2026-08-25
AlmaLinux	ALSA-2026:59242	9	python-pyasn1	2026-08-25
AlmaLinux	ALSA-2026:58561	10	python-urwid	2026-08-25
AlmaLinux	ALSA-2026:58562	8	python-urwid	2026-08-25
AlmaLinux	ALSA-2026:58952	9	python-urwid	2026-08-25
AlmaLinux	ALSA-2026:56219	8	python3	2026-08-19
AlmaLinux	ALSA-2026:58902	10	python3.12	2026-08-25
AlmaLinux	ALSA-2026:58971	8	python3.12	2026-08-25
AlmaLinux	ALSA-2026:59009	9	python3.12	2026-08-25
AlmaLinux	ALSA-2026:58928	10	python3.14	2026-08-25
AlmaLinux	ALSA-2026:58901	9	python3.14	2026-08-25
AlmaLinux	ALSA-2026:58571	10	qemu-kvm	2026-08-25
AlmaLinux	ALSA-2026:58938	8	sqlite	2026-08-26
AlmaLinux	ALSA-2026:57126	10	yggdrasil	2026-08-20
Debian	DLA-4749-1	LTS	chromium	2026-08-21
Debian	DSA-6455-1	stable	chromium	2026-08-20
Debian	DLA-4751-1	LTS	designate	2026-08-23
Debian	DSA-6452-1	stable	designate	2026-08-19
Debian	DSA-6464-1	stable	erlang	2026-08-25
Debian	DLA-4750-1	LTS	firefox-esr	2026-08-21
Debian	DSA-6451-1	stable	firefox-esr	2026-08-19
Debian	DSA-6467-1	stable	freecad	2026-08-26
Debian	DSA-6458-1	stable	gst-plugins-bad1.0	2026-08-21
Debian	DSA-6466-1	stable	kernel	2026-08-25
Debian	DSA-6453-1	stable	libgit2	2026-08-20
Debian	DSA-6459-1	stable	libnet-dns-perl	2026-08-22
Debian	DLA-4755-1	LTS	libvncserver	2026-08-25
Debian	DLA-4753-1	LTS	nvidia-graphics-drivers	2026-08-24
Debian	DLA-4752-1	LTS	nvidia-graphics-drivers	2026-08-24
Debian	DSA-6457-1	stable	openjdk-21	2026-08-21
Debian	DSA-6460-1	stable	openjdk-25	2026-08-23
Debian	DSA-6465-1	stable	openssl	2026-08-25
Debian	DLA-4747-1	LTS	python-httplib2	2026-08-20
Debian	DLA-4748-1	LTS	python-httplib2	2026-08-20
Debian	DSA-6454-1	stable	sabnzbdplus	2026-08-20
Debian	DSA-6456-1	stable	spip	2026-08-21
Debian	DLA-4746-1	LTS	swift	2026-08-19
Debian	DLA-4754-1	LTS	thunderbird	2026-08-25
Debian	DSA-6461-1	stable	thunderbird	2026-08-23
Debian	DSA-6463-1	stable	webkit2gtk	2026-08-24
Debian	DSA-6462-1	stable	zfs-linux	2026-08-24
Fedora	FEDORA-2026-44f6d8f2e7	F43	AusweisApp2	2026-08-23
Fedora	FEDORA-2026-2fff59246b	F44	AusweisApp2	2026-08-23
Fedora	FEDORA-2026-fe4c3064c5	F43	GitPython	2026-08-24
Fedora	FEDORA-2026-1ba2df871e	F43	apr-util	2026-08-26
Fedora	FEDORA-2026-1bbec06c4d	F44	bluez	2026-08-22
Fedora	FEDORA-2026-c10ed2f3b7	F43	calibre	2026-08-22
Fedora	FEDORA-2026-9f2b45e4c1	F44	calibre	2026-08-25
Fedora	FEDORA-2026-ebffec502b	F43	ceph	2026-08-22
Fedora	FEDORA-2026-7de7d03796	F44	ceph	2026-08-22
Fedora	FEDORA-2026-129176284e	F43	chromium	2026-08-26
Fedora	FEDORA-2026-295354c8a1	F44	chromium	2026-08-22
Fedora	FEDORA-2026-7cee1b8755	F44	chromium	2026-08-25
Fedora	FEDORA-2026-99a0f106c9	F43	dokuwiki	2026-08-21
Fedora	FEDORA-2026-f899239e0c	F44	dokuwiki	2026-08-21
Fedora	FEDORA-2026-cda155613e	F43	domoticz	2026-08-20
Fedora	FEDORA-2026-91c099294a	F43	dotnet10.0	2026-08-21
Fedora	FEDORA-2026-8b4cb2340a	F44	dotnet10.0	2026-08-21
Fedora	FEDORA-2026-0db5bf0aae	F43	dotnet8.0	2026-08-21
Fedora	FEDORA-2026-1397d83d94	F44	dotnet8.0	2026-08-21
Fedora	FEDORA-2026-9c8770dffb	F43	dotnet9.0	2026-08-21
Fedora	FEDORA-2026-7cfd54a4c1	F44	dotnet9.0	2026-08-21
Fedora	FEDORA-2026-170e9d62c6	F43	firefox	2026-08-20
Fedora	FEDORA-2026-fc11919789	F44	firefox	2026-08-20
Fedora	FEDORA-2026-903d904933	F44	freeipa	2026-08-25
Fedora	FEDORA-2026-c898a0f547	F43	i2c-display	2026-08-21
Fedora	FEDORA-2026-9b62042c7b	F44	i2c-display	2026-08-21
Fedora	FEDORA-2026-40b2544dda	F43	java-21-openjdk	2026-08-25
Fedora	FEDORA-2026-40b2544dda	F43	java-21-openjdk-portable	2026-08-25
Fedora	FEDORA-2026-760df8d7e8	F43	java-25-openjdk	2026-08-25
Fedora	FEDORA-2026-ff0646db03	F44	java-25-openjdk	2026-08-25
Fedora	FEDORA-2026-760df8d7e8	F43	java-latest-openjdk	2026-08-25
Fedora	FEDORA-2026-ff0646db03	F44	java-latest-openjdk	2026-08-25
Fedora	FEDORA-2026-39186e6ecd	F44	jfrog-cli	2026-08-25
Fedora	FEDORA-2026-1eb1157853	F43	kernel	2026-08-22
Fedora	FEDORA-2026-6d18f005f1	F43	kernel	2026-08-25
Fedora	FEDORA-2026-e57251bf72	F44	kernel	2026-08-22
Fedora	FEDORA-2026-73acdf12db	F44	kernel	2026-08-25
Fedora	FEDORA-2026-60e31281d5	F43	libgit2	2026-08-20
Fedora	FEDORA-2026-5dace9d06e	F43	libxls	2026-08-25
Fedora	FEDORA-2026-73af37bdd0	F44	libxls	2026-08-25
Fedora	FEDORA-2026-fc9fdfd3fd	F43	lyx	2026-08-21
Fedora	FEDORA-2026-ef5c3f9941	F44	lyx	2026-08-20
Fedora	FEDORA-2026-625cbe86c8	F43	nextcloud	2026-08-25
Fedora	FEDORA-2026-a1368a72b4	F44	nextcloud	2026-08-25
Fedora	FEDORA-2026-7ab20715e6	F43	nnn	2026-08-26
Fedora	FEDORA-2026-d5ab08d6bf	F44	nnn	2026-08-26
Fedora	FEDORA-2026-11d8a5a213	F43	ntpsec	2026-08-20
Fedora	FEDORA-2026-80887c367d	F44	ntpsec	2026-08-20
Fedora	FEDORA-2026-752aa3ff05	F44	openssh	2026-08-21
Fedora	FEDORA-2026-70dd9b4fc0	F43	pack	2026-08-22
Fedora	FEDORA-2026-14ebd38fea	F44	pack	2026-08-22
Fedora	FEDORA-2026-9d65f38b15	F43	perl-DBI	2026-08-26
Fedora	FEDORA-2026-57dcf299cc	F44	perl-DBI	2026-08-21
Fedora	FEDORA-2026-09941e744b	F43	perl-URI	2026-08-25
Fedora	FEDORA-2026-32b0d26c4c	F44	perl-URI	2026-08-23
Fedora	FEDORA-2026-67f1cac6df	F43	php-phpseclib3	2026-08-21
Fedora	FEDORA-2026-d2d58edf7d	F44	php-phpseclib3	2026-08-21
Fedora	FEDORA-2026-7d816931eb	F43	python-alembic	2026-08-21
Fedora	FEDORA-2026-6f7b906353	F44	python-alembic	2026-08-21
Fedora	FEDORA-2026-7d816931eb	F43	python-asyncmy	2026-08-21
Fedora	FEDORA-2026-6f7b906353	F44	python-asyncmy	2026-08-21
Fedora	FEDORA-2026-7d816931eb	F43	python-sqlalchemy	2026-08-21
Fedora	FEDORA-2026-6f7b906353	F44	python-sqlalchemy	2026-08-21
Fedora	FEDORA-2026-81ad01b22a	F43	python-tablib	2026-08-26
Fedora	FEDORA-2026-eaa6ecd43e	F44	python-tablib	2026-08-26
Fedora	FEDORA-2026-a64a31b855	F43	python3.10	2026-08-26
Fedora	FEDORA-2026-7ef4d2b23d	F44	python3.10	2026-08-26
Fedora	FEDORA-2026-22170bd5c0	F43	python3.11	2026-08-26
Fedora	FEDORA-2026-4d5b2df275	F44	python3.11	2026-08-26
Fedora	FEDORA-2026-7de2b1cfc5	F43	python3.12	2026-08-26
Fedora	FEDORA-2026-b39628a3c3	F43	python3.13	2026-08-21
Fedora	FEDORA-2026-d2906e4778	F44	python3.13	2026-08-21
Fedora	FEDORA-2026-914a40b4fd	F43	roundcubemail	2026-08-20
Fedora	FEDORA-2026-2aa96a9ce5	F44	roundcubemail	2026-08-20
Fedora	FEDORA-2026-bfae8723e2	F44	rsync	2026-08-22
Fedora	FEDORA-2026-903d904933	F44	samba	2026-08-25
Fedora	FEDORA-2026-70891f9a3e	F43	sympa	2026-08-26
Fedora	FEDORA-2026-eca56df39d	F44	sympa	2026-08-26
Fedora	FEDORA-2026-096ad5e804	F43	tcpreplay	2026-08-24
Fedora	FEDORA-2026-836c3dec74	F44	tcpreplay	2026-08-24
Fedora	FEDORA-2026-de4e0fac25	F43	trafficserver	2026-08-21
Fedora	FEDORA-2026-b2d993884d	F44	trafficserver	2026-08-21
Fedora	FEDORA-2026-adc1870e77	F43	wireshark	2026-08-21
Fedora	FEDORA-2026-5034844482	F44	wireshark	2026-08-20
Fedora	FEDORA-2026-61704c09ea	F43	wordpress	2026-08-21
Fedora	FEDORA-2026-dc0ff85b8b	F44	wordpress	2026-08-21
Gentoo	202608-24		DTrace	2026-08-26
Gentoo	202608-18		Emacs	2026-08-20
Gentoo	202608-21		GNU Emacs	2026-08-24
Gentoo	202608-27		GNU screen	2026-08-26
Gentoo	202608-23		Incus	2026-08-25
Gentoo	202608-25		UnrealIRCd	2026-08-26
Gentoo	202608-26		Vinyl Cache	2026-08-26
Gentoo	202608-20		acl, attr	2026-08-20
Gentoo	202608-17		libssh2	2026-08-20
Gentoo	202608-22		needrestart	2026-08-24
Gentoo	202608-19		quickjs-ng	2026-08-20
Mageia	MGASA-2026-0336	10	kernel	2026-08-25
Mageia	MGASA-2026-0337	10	kernel-linus	2026-08-25
Oracle	ELSA-2026-55857	OL9	.NET 10.0	2026-08-20
Oracle	ELSA-2026-55856	OL9	.NET 9.0	2026-08-20
Oracle	ELSA-2026-36205	OL7	389-ds-base	2026-08-26
Oracle	ELSA-2026-58555	OL8	NetworkManager	2026-08-24
Oracle	ELSA-2026-58572	OL9	NetworkManager	2026-08-24
Oracle	ELSA-2026-57148	OL10	ansible-core	2026-08-21
Oracle	ELSA-2026-57149	OL9	ansible-core	2026-08-24
Oracle	ELSA-2026-59380	OL10	attr	2026-08-26
Oracle	ELSA-2026-56133	OL8	attr	2026-08-20
Oracle	ELSA-2026-55442	OL9	bind9.18	2026-08-20
Oracle	ELSA-2026-57451	OL8	cups-filters	2026-08-24
Oracle	ELSA-2026-58560	OL9	cups-filters	2026-08-24
Oracle	ELSA-2026-55450	OL10	curl	2026-08-20
Oracle	ELSA-2026-57462	OL8	curl	2026-08-24
Oracle	ELSA-2026-55439	OL9	curl	2026-08-20
Oracle	ELSA-2026-58899	OL10	firefox	2026-08-26
Oracle	ELSA-2026-58898	OL8	firefox	2026-08-26
Oracle	ELSA-2026-58897	OL9	firefox	2026-08-24
Oracle	ELSA-2026-38497	OL9	gegl04	2026-08-26
Oracle	ELSA-2026-57015	OL10	glib2	2026-08-20
Oracle	ELSA-2026-55440	OL9	glib2	2026-08-20
Oracle	ELSA-2026-58982	OL9	grafana	2026-08-26
Oracle	ELSA-2026-56521	OL8	gstreamer1-plugins-bad-free	2026-08-20
Oracle	ELSA-2026-59097	OL10	gstreamer1-plugins-base	2026-08-26
Oracle	ELSA-2026-59133	OL10	gstreamer1-plugins-good	2026-08-26
Oracle	ELSA-2026-56966	OL8	gstreamer1-plugins-good	2026-08-20
Oracle	ELSA-2026-59179	OL8	gstreamer1-plugins-good	2026-08-26
Oracle	ELSA-2026-59152	OL9	gstreamer1-plugins-good	2026-08-26
Oracle	ELSA-2026-59347	OL9	httpd	2026-08-26
Oracle	ELSA-2026-55775	OL8	java-1.8.0-openjdk	2026-08-21
Oracle	ELSA-2026-55775	OL9	java-1.8.0-openjdk	2026-08-21
Oracle	ELSA-2026-55781	OL8	java-17-openjdk	2026-08-21
Oracle	ELSA-2026-55781	OL9	java-17-openjdk	2026-08-21
Oracle	ELSA-2026-55787	OL10	java-21-openjdk	2026-08-21
Oracle	ELSA-2026-55787	OL8	java-21-openjdk	2026-08-21
Oracle	ELSA-2026-55787	OL9	java-21-openjdk	2026-08-21
Oracle	ELSA-2026-55798	OL10	java-25-openjdk	2026-08-21
Oracle	ELSA-2026-55798	OL9	java-25-openjdk	2026-08-21
Oracle	ELSA-2026-57597	OL10	kbd	2026-08-21
Oracle	ELSA-2026-57610	OL9	kbd	2026-08-21
Oracle	ELSA-2026-38492	OL10	kernel	2026-08-20
Oracle	ELSA-2026-57251	OL10	kernel	2026-08-21
Oracle	ELSA-2026-54246	OL8	kernel	2026-08-20
Oracle	ELSA-2026-55764	OL8	kernel	2026-08-24
Oracle	ELSA-2026-57253	OL8	kernel	2026-08-24
Oracle	ELSA-2026-57252	OL9	kernel	2026-08-21
Oracle	ELSA-2026-55446	OL8	libXfont2	2026-08-20
Oracle	ELSA-2026-56965	OL10	libcupsfilters	2026-08-24
Oracle	ELSA-2026-46386	OL7	libreoffice	2026-08-24
Oracle	ELSA-2026-59387	OL9	mod_http2	2026-08-26
Oracle	ELSA-2026-57596	OL10	mrtg	2026-08-24
Oracle	ELSA-2026-57600	OL9	mrtg	2026-08-24
Oracle	ELSA-2026-56007	OL10	mysql8.4	2026-08-20
Oracle	ELSA-2026-56936	OL8	mysql:8.4	2026-08-21
Oracle	ELSA-2026-56973	OL9	mysql:8.4	2026-08-21
Oracle	ELSA-2026-55804	OL8	nghttp2	2026-08-20
Oracle	ELSA-2026-59220	OL10	nginx	2026-08-26
Oracle	ELSA-2026-55601	OL9	nodejs:22	2026-08-20
Oracle	ELSA-2026-55603	OL9	nodejs:24	2026-08-20
Oracle	ELSA-2026-59379	OL10	pam	2026-08-26
Oracle	ELSA-2026-56131	OL8	pam	2026-08-20
Oracle	ELSA-2026-55560	OL8	pcp	2026-08-20
Oracle	ELSA-2026-55740	OL9	pcp	2026-08-20
Oracle	ELSA-2026-56971	OL10	perl-Date-Manip	2026-08-20
Oracle	ELSA-2026-57562	OL8	perl-Date-Manip	2026-08-21
Oracle	ELSA-2026-56970	OL9	perl-Date-Manip	2026-08-24
Oracle	ELSA-2026-48225	OL8	perl:5.32	2026-08-21
Oracle	ELSA-2026-56969	OL10	php8.4	2026-08-20
Oracle	ELSA-2026-57574	OL8	php:8.2	2026-08-24
Oracle	ELSA-2026-57539	OL9	php:8.3	2026-08-24
Oracle	ELSA-2026-59243	OL10	python-pyasn1	2026-08-26
Oracle	ELSA-2026-59241	OL8	python-pyasn1	2026-08-26
Oracle	ELSA-2026-59242	OL9	python-pyasn1	2026-08-26
Oracle	ELSA-2026-58561	OL10	python-urwid	2026-08-24
Oracle	ELSA-2026-58562	OL8	python-urwid	2026-08-26
Oracle	ELSA-2026-58952	OL9	python-urwid	2026-08-26
Oracle	ELSA-2026-56219	OL8	python3	2026-08-20
Oracle	ELSA-2026-58971	OL8	python3.12	2026-08-26
Oracle	ELSA-2026-59009	OL9	python3.12	2026-08-26
Oracle	ELSA-2026-58928	OL10	python3.14	2026-08-24
Oracle	ELSA-2026-58901	OL9	python3.14	2026-08-26
Oracle	ELSA-2026-58571	OL10	qemu-kvm	2026-08-24
Oracle	ELSA-2026-56130	OL8	sg3_utils	2026-08-20
Oracle	ELSA-2026-58927	OL10	sqlite	2026-08-24
Oracle	ELSA-2026-58938	OL8	sqlite	2026-08-26
Oracle	ELSA-2026-58936	OL9	sqlite	2026-08-26
Oracle	ELSA-2026-50109-0	OL7	sssd	2026-08-21
Oracle	ELSA-2026-50117-0	OL7	xorg-x11-server	2026-08-26
Oracle	ELSA-2026-57126	OL10	yggdrasil	2026-08-20
Red Hat	RHSA-2026:59372-01	EL10	assertj-core	2026-08-25
Red Hat	RHSA-2026:58956-01	EL9.2	assertj-core	2026-08-25
Red Hat	RHSA-2026:58957-01	EL9.4	assertj-core	2026-08-25
Red Hat	RHSA-2026:58949-01	EL9.6	assertj-core	2026-08-25
Red Hat	RHSA-2026:22315-01	EL8	compat-openssl10	2026-08-21
Red Hat	RHSA-2026:47096-01	EL8.4	compat-openssl10	2026-08-21
Red Hat	RHSA-2026:44480-01	EL8.6	compat-openssl10	2026-08-21
Red Hat	RHSA-2026:36217-01	EL8.8	compat-openssl10	2026-08-21
Red Hat	RHSA-2026:22313-01	EL9	compat-openssl11	2026-08-21
Red Hat	RHSA-2026:39012-01	EL9.2	compat-openssl11	2026-08-21
Red Hat	RHSA-2026:39009-01	EL9.4	compat-openssl11	2026-08-21
Red Hat	RHSA-2026:35869-01	EL9.6	compat-openssl11	2026-08-21
Red Hat	RHSA-2026:55450-01	EL10	curl	2026-08-24
Red Hat	RHSA-2026:57462-01	EL8	curl	2026-08-24
Red Hat	RHSA-2026:55439-01	EL9	curl	2026-08-24
Red Hat	RHSA-2026:19158-01	EL10	dnsmasq	2026-08-24
Red Hat	RHSA-2026:20589-01	EL8	dnsmasq	2026-08-24
Red Hat	RHSA-2026:19373-01	EL9	dnsmasq	2026-08-24
Red Hat	RHSA-2026:34508-01	EL9.6	dnsmasq	2026-08-24
Red Hat	RHSA-2026:49927-01	EL8	fence-agents	2026-08-21
Red Hat	RHSA-2026:51152-01	EL8.4	fence-agents	2026-08-21
Red Hat	RHSA-2026:51157-01	EL8.6	fence-agents	2026-08-21
Red Hat	RHSA-2026:51045-01	EL8.8	fence-agents	2026-08-21
Red Hat	RHSA-2026:20613-01	EL10	gnutls	2026-08-21
Red Hat	RHSA-2026:26409-01	EL10.0	gnutls	2026-08-21
Red Hat	RHSA-2026:43575-01	EL7	gnutls	2026-08-21
Red Hat	RHSA-2026:20611-01	EL8	gnutls	2026-08-21
Red Hat	RHSA-2026:20612-01	EL9	gnutls	2026-08-21
Red Hat	RHSA-2026:41921-01	EL9.2	gnutls	2026-08-21
Red Hat	RHSA-2026:32962-01	EL9.4	gnutls	2026-08-21
Red Hat	RHSA-2026:30004-01	EL9.6	gnutls	2026-08-21
Red Hat	RHSA-2026:59347-01	EL9	httpd	2026-08-25
Red Hat	RHSA-2026:57597-01	EL10	kbd	2026-08-24
Red Hat	RHSA-2026:57610-01	EL9	kbd	2026-08-24
Red Hat	RHSA-2026:44270-01	EL10	kernel	2026-08-21
Red Hat	RHSA-2026:36541-01	EL10	kernel	2026-08-24
Red Hat	RHSA-2026:52764-01	EL10.0	kernel	2026-08-21
Red Hat	RHSA-2026:53989-01	EL8.6	kernel	2026-08-21
Red Hat	RHSA-2026:36645-01	EL9	kernel	2026-08-24
Red Hat	RHSA-2026:56573-01	EL9.4	kernel	2026-08-21
Red Hat	RHSA-2026:41236-01	EL7	kernel-rt	2026-08-21
Red Hat	RHSA-2026:8492-01	EL10	libarchive	2026-08-21
Red Hat	RHSA-2026:8865-01	EL10.0	libarchive	2026-08-21
Red Hat	RHSA-2026:8517-01	EL7	libarchive	2026-08-21
Red Hat	RHSA-2026:8534-01	EL8	libarchive	2026-08-21
Red Hat	RHSA-2026:8521-01	EL8.2	libarchive	2026-08-21
Red Hat	RHSA-2026:9592-01	EL8.4	libarchive	2026-08-21
Red Hat	RHSA-2026:8908-01	EL8.6	libarchive	2026-08-21
Red Hat	RHSA-2026:9026-01	EL8.8	libarchive	2026-08-21
Red Hat	RHSA-2026:8510-01	EL9	libarchive	2026-08-21
Red Hat	RHSA-2026:8867-01	EL9.0	libarchive	2026-08-21
Red Hat	RHSA-2026:8864-01	EL9.2	libarchive	2026-08-21
Red Hat	RHSA-2026:8873-01	EL9.4	libarchive	2026-08-21
Red Hat	RHSA-2026:8866-01	EL9.6	libarchive	2026-08-21
Red Hat	RHSA-2026:19456-01	EL10.0	libcap	2026-08-24
Red Hat	RHSA-2026:24346-01	EL8.6	libcap	2026-08-24
Red Hat	RHSA-2026:22957-01	EL8.8	libcap	2026-08-24
Red Hat	RHSA-2026:21254-01	EL9.2	libcap	2026-08-24
Red Hat	RHSA-2026:46398-01	EL10	libreswan	2026-08-21
Red Hat	RHSA-2026:55449-01	EL10.0	libreswan	2026-08-24
Red Hat	RHSA-2026:46396-01	EL8	libreswan	2026-08-21
Red Hat	RHSA-2026:46397-01	EL9	libreswan	2026-08-21
Red Hat	RHSA-2026:57741-01	EL9.6	libreswan	2026-08-24
Red Hat	RHSA-2026:55762-01	EL8	multiple packages	2026-08-21
Red Hat	RHSA-2026:33125-01	EL8.4	multiple packages	2026-08-21
Red Hat	RHSA-2026:30849-01	EL8.6	multiple packages	2026-08-21
Red Hat	RHSA-2026:30850-01	EL8.8	multiple packages	2026-08-21
Red Hat	RHSA-2026:55761-01	EL8.8	multiple packages	2026-08-21
Red Hat	RHSA-2026:55837-01	EL9.2	multiple packages	2026-08-21
Red Hat	RHSA-2026:56224-01	EL9.4	multiple packages	2026-08-21
Red Hat	RHSA-2026:56225-01	EL9.6	multiple packages	2026-08-21
Red Hat	RHSA-2026:47757-01	EL10	openssh	2026-08-24
Red Hat	RHSA-2026:47756-01	EL9	openssh	2026-08-24
Red Hat	RHSA-2026:22314-01	EL10	openssl	2026-08-21
Red Hat	RHSA-2026:38503-01	EL8	openssl	2026-08-21
Red Hat	RHSA-2026:43513-01	EL8.4	openssl	2026-08-21
Red Hat	RHSA-2026:38804-01	EL8.6	openssl	2026-08-21
Red Hat	RHSA-2026:38805-01	EL8.8	openssl	2026-08-21
Red Hat	RHSA-2026:22312-01	EL9	openssl	2026-08-21
Red Hat	RHSA-2026:56959-01	EL9.4	osbuild-composer	2026-08-25
Red Hat	RHSA-2026:54481-01	EL10	python-idna	2026-08-21
Red Hat	RHSA-2026:54290-01	EL8	python-idna	2026-08-21
Red Hat	RHSA-2026:54484-01	EL9	python-idna	2026-08-21
Red Hat	RHSA-2026:39127-01	EL8	python-pillow	2026-08-21
Red Hat	RHSA-2026:48760-01	EL8.6	python-pillow	2026-08-21
Red Hat	RHSA-2026:48759-01	EL8.8	python-pillow	2026-08-21
Red Hat	RHSA-2026:39311-01	EL9	qemu-kvm	2026-08-21
Red Hat	RHSA-2026:47126-01	EL8	resource-agents	2026-08-21
Red Hat	RHSA-2026:47091-01	EL8.4	resource-agents	2026-08-21
Red Hat	RHSA-2026:47092-01	EL8.6	resource-agents	2026-08-21
Red Hat	RHSA-2026:47129-01	EL8.8	resource-agents	2026-08-21
Red Hat	RHSA-2026:57590-01	EL10	rh-podman-desktop	2026-08-21
Red Hat	RHSA-2026:26332-01	EL10	rsync	2026-08-24
Red Hat	RHSA-2026:26408-01	EL8	rsync	2026-08-24
Red Hat	RHSA-2026:26410-01	EL9	rsync	2026-08-24
Red Hat	RHSA-2026:37397-01	EL7	ruby	2026-08-21
Red Hat	RHSA-2026:22963-01	EL10	samba	2026-08-24
Red Hat	RHSA-2026:28055-01	EL10.0	samba	2026-08-24
Red Hat	RHSA-2026:28132-01	EL7	samba	2026-08-24
Red Hat	RHSA-2026:22644-01	EL8	samba	2026-08-24
Red Hat	RHSA-2026:28058-01	EL8.4	samba	2026-08-24
Red Hat	RHSA-2026:28057-01	EL8.6	samba	2026-08-24
Red Hat	RHSA-2026:28056-01	EL8.8	samba	2026-08-24
Red Hat	RHSA-2026:25049-01	EL9	samba	2026-08-24
Red Hat	RHSA-2026:28054-01	EL9.2	samba	2026-08-24
Red Hat	RHSA-2026:28053-01	EL9.4	samba	2026-08-24
Red Hat	RHSA-2026:25979-01	EL9.6	samba	2026-08-24
Red Hat	RHSA-2026:23231-01	EL10	unbound	2026-08-24
Red Hat	RHSA-2026:37282-01	EL8	unbound	2026-08-21
Red Hat	RHSA-2026:24365-01	EL8	unbound	2026-08-24
Red Hat	RHSA-2026:24369-01	EL9	unbound	2026-08-24
Red Hat	RHSA-2026:48650-01	EL10	vim	2026-08-24
Red Hat	RHSA-2026:38509-01	EL10	vim	2026-08-24
Red Hat	RHSA-2026:55431-01	EL10.0	vim	2026-08-21
Red Hat	RHSA-2026:30900-01	EL10.0	vim	2026-08-24
Red Hat	RHSA-2026:38510-01	EL8	vim	2026-08-21
Red Hat	RHSA-2026:48703-01	EL8	vim	2026-08-24
Red Hat	RHSA-2026:33453-01	EL8.4	vim	2026-08-24
Red Hat	RHSA-2026:34477-01	EL8.6	vim	2026-08-24
Red Hat	RHSA-2026:34476-01	EL8.8	vim	2026-08-24
Red Hat	RHSA-2026:38511-01	EL9	vim	2026-08-21
Red Hat	RHSA-2026:47982-01	EL9	vim	2026-08-24
Red Hat	RHSA-2026:28133-01	EL9.2	vim	2026-08-24
Red Hat	RHSA-2026:28049-01	EL9.4	vim	2026-08-24
Red Hat	RHSA-2026:28050-01	EL9.6	vim	2026-08-24
Slackware	SSA:2026-231-01		mozilla-firefox	2026-08-19
Slackware	SSA:2026-231-02		mozilla-thunderbird	2026-08-19
SUSE	SUSE-SU-2026:3678-1	SLE15	389-ds	2026-08-21
SUSE	SUSE-SU-2026:3687-1	SLE15 oS15.5	389-ds	2026-08-24
SUSE	SUSE-SU-2026:3686-1	SLE15 oS15.6	389-ds	2026-08-24
SUSE	SUSE-SU-2026:23234-1	SLE16.0	amazon-ecs-init	2026-08-25
SUSE	openSUSE-SU-2026:21611-1	oS16.0	apptainer	2026-08-22
SUSE	SUSE-SU-2026:23161-1	SLE-m6.1	avahi	2026-08-21
SUSE	openSUSE-SU-2026:21613-1	oS16.0	bugwarden	2026-08-22
SUSE	SUSE-SU-2026:3667-1	SLE15 oS15.4	buildah	2026-08-21
SUSE	SUSE-SU-2026:3784-1	SLE15 oS15.5	buildah	2026-08-25
SUSE	openSUSE-SU-2026:21624-1	oS16.0	chromium	2026-08-23
SUSE	openSUSE-SU-2026:21609-1	oS16.0	chromium	2026-08-22
SUSE	openSUSE-SU-2026:0293-1	osB15	chromium	2026-08-21
SUSE	openSUSE-SU-2026:0298-1	osB15	chromium	2026-08-24
SUSE	openSUSE-SU-2026:11562-1	TW	comfyui	2026-08-24
SUSE	SUSE-SU-2026:3654-1	SLE15	container-suseconnect	2026-08-20
SUSE	SUSE-SU-2026:3670-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	containerd	2026-08-21
SUSE	SUSE-SU-2026:3783-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	containerd	2026-08-25
SUSE	SUSE-SU-2026:3666-1	SLE15 oS15.4	cosign	2026-08-21
SUSE	openSUSE-SU-2026:0292-1	osB15	ctop	2026-08-20
SUSE	SUSE-SU-2026:3798-1	SLE15	curl	2026-08-25
SUSE	SUSE-SU-2026:3786-1	SLE15 oS15.4	distribution	2026-08-25
SUSE	SUSE-SU-2026:3668-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	docker	2026-08-21
SUSE	SUSE-SU-2026:23246-1	SLE-m6.0	dracut	2026-08-25
SUSE	SUSE-SU-2026:23195-1	SLE-m6.1	dracut	2026-08-24
SUSE	openSUSE-SU-2026:11559-1	TW	erlang	2026-08-24
SUSE	openSUSE-SU-2026:11560-1	TW	erlang27	2026-08-24
SUSE	SUSE-SU-2026:23232-1	SLE16.0	ffmpeg-7	2026-08-25
SUSE	SUSE-SU-2026:23222-1	SLE16.0	ffmpeg-7	2026-08-25
SUSE	openSUSE-SU-2026:11545-1	TW	ffmpeg-9-libavcodec-devel	2026-08-23
SUSE	SUSE-SU-2026:3683-1	SLE12	firefox	2026-08-24
SUSE	SUSE-SU-2026:3658-1	SLE15	firefox	2026-08-21
SUSE	openSUSE-SU-2026:11546-1	TW	firefox-esr	2026-08-23
SUSE	openSUSE-SU-2026:21594-1	oS16.0	firefox	2026-08-20
SUSE	openSUSE-SU-2026:21605-1	oS16.0	forgejo-cli	2026-08-20
SUSE	SUSE-SU-2026:23252-1	SLE-m6.0	fuse-overlayfs	2026-08-25
SUSE	SUSE-SU-2026:23224-1	SLE16.0	gd	2026-08-25
SUSE	SUSE-SU-2026:23213-1	SLE16.0	gd	2026-08-25
SUSE	SUSE-SU-2026:3688-1	SLE15 oS15.4	gimp	2026-08-24
SUSE	openSUSE-SU-2026:11547-1	TW	gimp	2026-08-23
SUSE	SUSE-SU-2026:3801-1	SLE15 oS15.6	git-lfs	2026-08-25
SUSE	openSUSE-SU-2026:21603-1	oS16.0	gitea-tea	2026-08-20
SUSE	openSUSE-SU-2026:21592-1	oS16.0	go1.25	2026-08-20
SUSE	SUSE-SU-2026:3800-1	SLE15	go1.25-openssl	2026-08-25
SUSE	openSUSE-SU-2026:21593-1	oS16.0	go1.26	2026-08-20
SUSE	SUSE-SU-2026:3799-1	SLE15	go1.26-openssl	2026-08-25
SUSE	openSUSE-SU-2026:11536-1	TW	go1.27	2026-08-21
SUSE	SUSE-SU-2026:23227-1	SLE16.0	govulncheck-vulndb	2026-08-25
SUSE	SUSE-SU-2026:23216-1	SLE16.0	govulncheck-vulndb	2026-08-25
SUSE	SUSE-SU-2026:3718-1	SLE15	grafana	2026-08-24
SUSE	openSUSE-SU-2026:11574-1	TW	hauler	2026-08-25
SUSE	SUSE-SU-2026:23162-1	SLE-m6.1	helm	2026-08-21
SUSE	SUSE-SU-2026:3661-1	SLE15 SLE5.5 SLE-m5.5	helm	2026-08-21
SUSE	SUSE-SU-2026:23233-1	SLE16.0	himmelblau	2026-08-25
SUSE	SUSE-SU-2026:23170-1	SLE-m6.1	ignition	2026-08-21
SUSE	SUSE-SU-2026:3790-1	SLE15	kernel	2026-08-25
SUSE	SUSE-SU-2026:23231-1	SLE16.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23221-1	SLE16.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23237-1	SLE16.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23241-1	SLE6.0 SLE-m6.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23240-1	SLE6.0 SLE-m6.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23244-1	SLE6.0 SLE-m6.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23238-1	SLE6.0 SLE-m6.0	kernel	2026-08-25
SUSE	SUSE-SU-2026:23183-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-08-24
SUSE	SUSE-SU-2026:23193-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-08-24
SUSE	SUSE-SU-2026:3660-1	SLE15 oS15.6	kubernetes	2026-08-21
SUSE	SUSE-SU-2026:3659-1	SLE15 oS15.6	kubernetes-old	2026-08-21
SUSE	openSUSE-SU-2026:21590-1	oS16.0	kubevirt1.8	2026-08-20
SUSE	SUSE-SU-2026:23173-1	SLE-m6.1	libarchive	2026-08-21
SUSE	openSUSE-SU-2026:11537-1	TW	libjxl-devel	2026-08-21
SUSE	SUSE-SU-2026:3796-1	SLE12	librest	2026-08-25
SUSE	SUSE-SU-2026:3795-1	SLE15 oS15.6	librest	2026-08-25
SUSE	SUSE-SU-2026:23168-1	SLE-m6.1	libssh	2026-08-21
SUSE	SUSE-SU-2026:23245-1	SLE-m6.0	libssh2_org	2026-08-25
SUSE	SUSE-SU-2026:23187-1	SLE-m6.1	libssh2_org	2026-08-24
SUSE	SUSE-SU-2026:23225-1	SLE16.0	libssh2_org	2026-08-25
SUSE	SUSE-SU-2026:23214-1	SLE16.0	libssh2_org	2026-08-25
SUSE	SUSE-SU-2026:23160-1	SLE-m6.1	multipath-tools	2026-08-21
SUSE	SUSE-SU-2026:3647-1	SLE15	open-iscsi	2026-08-19
SUSE	SUSE-SU-2026:23235-1	SLE16.0	open-iscsi	2026-08-25
SUSE	SUSE-SU-2026:23223-1	SLE16.0	open-iscsi	2026-08-25
SUSE	SUSE-SU-2026:23249-1	SLE-m6.0	openssh	2026-08-25
SUSE	SUSE-SU-2026:23172-1	SLE-m6.1	openssl-3	2026-08-21
SUSE	SUSE-SU-2026:23188-1	SLE-m6.1	openvswitch	2026-08-24
SUSE	SUSE-SU-2026:23210-1	SLE-m6.0	patch	2026-08-25
SUSE	SUSE-SU-2026:23174-1	SLE-m6.1	pcp	2026-08-21
SUSE	openSUSE-SU-2026:11564-1	TW	perl-Dancer2-Plugin-Auth-Extensible	2026-08-24
SUSE	SUSE-SU-2026:23229-1	SLE16.0	perl-Date-Manip	2026-08-25
SUSE	SUSE-SU-2026:23218-1	SLE16.0	perl-Date-Manip	2026-08-25
SUSE	openSUSE-SU-2026:11550-1	TW	perl-Net-CIDR-Set	2026-08-23
SUSE	openSUSE-SU-2026:11551-1	TW	perl-Net-OAuth	2026-08-23
SUSE	SUSE-SU-2026:23205-1	SLE-m6.0	podman	2026-08-25
SUSE	SUSE-SU-2026:3662-1	SLE15 SES7.1 oS15.3	podman	2026-08-21
SUSE	SUSE-SU-2026:3652-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	podman	2026-08-20
SUSE	SUSE-SU-2026:3671-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	podman	2026-08-21
SUSE	SUSE-SU-2026:3793-1	SLE12	postgresql14	2026-08-25
SUSE	openSUSE-SU-2026:11552-1	TW	postgresql14	2026-08-23
SUSE	openSUSE-SU-2026:11553-1	TW	postgresql15	2026-08-23
SUSE	SUSE-SU-2026:3794-1	SLE12	postgresql16	2026-08-25
SUSE	openSUSE-SU-2026:11555-1	TW	postgresql17	2026-08-24
SUSE	SUSE-SU-2026:23228-1	SLE16.0	python-Pillow	2026-08-25
SUSE	SUSE-SU-2026:23217-1	SLE16.0	python-Pillow	2026-08-25
SUSE	SUSE-SU-2026:23247-1	SLE-m6.0	python-cryptography	2026-08-25
SUSE	SUSE-SU-2026:23196-1	SLE-m6.1	python-cryptography	2026-08-24
SUSE	SUSE-SU-2026:23169-1	SLE-m6.1	python-msgpack	2026-08-21
SUSE	SUSE-SU-2026:23167-1	SLE-m6.1	python-pyasn1	2026-08-21
SUSE	openSUSE-SU-2026:21602-1	oS16.0	python-pytest-html	2026-08-20
SUSE	SUSE-SU-2026:3762-1	SLE15	python-sqlparse	2026-08-25
SUSE	openSUSE-SU-2026:21606-1	oS16.0	python-unearth	2026-08-20
SUSE	SUSE-SU-2026:23176-1	SLE-m6.1	python-urllib3	2026-08-21
SUSE	SUSE-SU-2026:3655-1	MP4.3 SLE15 oS15.4	python311	2026-08-20
SUSE	SUSE-SU-2026:23212-1	SLE-m6.0	python311	2026-08-25
SUSE	SUSE-SU-2026:23191-1	SLE-m6.1	python311	2026-08-24
SUSE	SUSE-SU-2026:3648-1	SLE15 oS15.6	python311	2026-08-19
SUSE	SUSE-SU-2026:23159-1	SLE-m6.2	python313	2026-08-21
SUSE	SUSE-SU-2026:3649-1	SLE15	python313	2026-08-19
SUSE	openSUSE-SU-2026:11556-1	TW	python313-hpack	2026-08-24
SUSE	openSUSE-SU-2026:21595-1	oS16.0	python313	2026-08-20
SUSE	openSUSE-SU-2026:11540-1	TW	python313-pytest-html	2026-08-21
SUSE	openSUSE-SU-2026:11542-1	TW	redis	2026-08-21
SUSE	SUSE-SU-2026:3792-1	SLE15	rmt-server	2026-08-25
SUSE	SUSE-SU-2026:3669-1	SLE15	rootlesskit	2026-08-21
SUSE	SUSE-SU-2026:3785-1	SLE15 oS15.6	rootlesskit	2026-08-25
SUSE	SUSE-SU-2026:23204-1	SLE-m6.0	rpm	2026-08-25
SUSE	SUSE-SU-2026:23200-1	SLE-m6.0	rpm	2026-08-25
SUSE	SUSE-SU-2026:23182-1	SLE-m6.1	rpm	2026-08-24
SUSE	SUSE-SU-2026:23192-1	SLE-m6.1	rpm	2026-08-24
SUSE	SUSE-SU-2026:23253-1	SLE-m6.0	rsync	2026-08-25
SUSE	SUSE-SU-2026:3657-1	SLE15 oS15.6	rsync	2026-08-21
SUSE	SUSE-SU-2026:23164-1	SLE-m6.1	runc	2026-08-21
SUSE	SUSE-SU-2026:3787-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1	runc	2026-08-25
SUSE	SUSE-SU-2026:3674-1	SLE15 oS15.6	sccache	2026-08-21
SUSE	SUSE-SU-2026:3791-1	SLE15	snpguest	2026-08-25
SUSE	SUSE-SU-2026:23251-1	SLE-m6.0	sssd	2026-08-25
SUSE	SUSE-SU-2026:23171-1	SLE-m6.1	sssd	2026-08-21
SUSE	SUSE-SU-2026:3797-1	SLE12	sssd	2026-08-25
SUSE	SUSE-SU-2026:23211-1	SLE-m6.0	suseconnect-ng	2026-08-25
SUSE	SUSE-SU-2026:23186-1	SLE-m6.1	suseconnect-ng	2026-08-24
SUSE	openSUSE-SU-2026:11558-1	TW	thunderbird	2026-08-24
SUSE	SUSE-SU-2026:23226-1	SLE16.0	unbound	2026-08-25
SUSE	SUSE-SU-2026:23215-1	SLE16.0	unbound	2026-08-25
SUSE	SUSE-SU-2026:23250-1	SLE-m6.0	util-linux	2026-08-25
SUSE	SUSE-SU-2026:3684-1	SLE15	util-linux	2026-08-24
SUSE	SUSE-SU-2026:3685-1	SLE15 oS15.6	util-linux	2026-08-24
SUSE	SUSE-SU-2026:23181-1	SLE-m6.1	vim	2026-08-24
SUSE	SUSE-SU-2026:23190-1	SLE-m6.1	vim	2026-08-24
SUSE	SUSE-SU-2026:3677-1	SLE12	vim	2026-08-21
SUSE	SUSE-SU-2026:3679-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	vim	2026-08-21
SUSE	SUSE-SU-2026:3680-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	vim	2026-08-21
SUSE	openSUSE-SU-2026:21615-1	oS16.0	weechat	2026-08-22
SUSE	SUSE-SU-2026:23163-1	SLE-m6.1	wget	2026-08-21
Ubuntu	USN-8655-1	20.04 22.04 24.04 26.04	async-http-client	2026-08-24
Ubuntu	USN-8648-1	22.04 24.04 26.04	bind9	2026-08-19
Ubuntu	USN-8650-1	18.04 20.04 22.04 24.04 26.04	capnproto	2026-08-19
Ubuntu	USN-8651-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	curl	2026-08-19
Ubuntu	USN-8670-2	18.04 20.04 22.04	curl	2026-08-25
Ubuntu	USN-8670-1	24.04	curl	2026-08-24
Ubuntu	USN-8671-1	16.04 18.04 20.04 22.04 24.04	ffmpeg	2026-08-24
Ubuntu	USN-8680-1	16.04 18.04 20.04 22.04 24.04	ffmpeg	2026-08-25
Ubuntu	USN-8649-1	24.04 26.04	libheif	2026-08-19
Ubuntu	USN-8639-1	14.04 16.04 18.04 20.04 22.04	libpng, libpng1.6	2026-08-19
Ubuntu	USN-8093-2	26.04	libssh	2026-08-19
Ubuntu	USN-8666-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-azure, linux-bluefield, linux-fips, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-oracle, linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp	2026-08-20
Ubuntu	USN-8659-1	24.04 26.04	linux, linux-aws, linux-aws-7.0, linux-ibm, linux-oem-7.0, linux-raspi, linux-realtime	2026-08-20
Ubuntu	USN-8658-1	20.04 22.04	linux, linux-aws, linux-aws-fips, linux-azure-fips, linux-gkeop, linux-ibm-5.15, linux-intel-iot-realtime, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-oracle, linux-oracle-5.15, linux-realtime, linux-xilinx-zynqmp	2026-08-20
Ubuntu	USN-8662-1	14.04 16.04	linux, linux-aws, linux-kvm, linux-lts-xenial	2026-08-20
Ubuntu	USN-8643-4	22.04 24.04	linux-aws-6.8, linux-azure-fde, linux-azure-fde-6.8, linux-azure-fips, linux-nvidia-tegra	2026-08-25
Ubuntu	USN-8630-4	22.04	linux-aws-6.8	2026-08-20
Ubuntu	USN-8658-3	22.04	linux-azure, linux-azure-fde, linux-nvidia-tegra-igx	2026-08-25
Ubuntu	USN-8659-3	26.04	linux-azure, linux-azure-fde	2026-08-25
Ubuntu	USN-8661-1	20.04 22.04	linux-azure-5.15, linux-gcp, linux-gcp-fips, linux-hwe-5.15, linux-lowlatency-hwe-5.15	2026-08-20
Ubuntu	USN-8666-2	18.04 20.04	linux-azure-5.4, linux-azure-fips	2026-08-25
Ubuntu	USN-8662-2	16.04	linux-fips	2026-08-21
Ubuntu	USN-8644-2	16.04 18.04	linux-gcp, linux-gcp-4.15, linux-gcp-fips	2026-08-20
Ubuntu	USN-8660-1	26.04	linux-gcp, linux-gke	2026-08-20
Ubuntu	USN-8668-1	20.04	linux-gcp-5.15	2026-08-21
Ubuntu	USN-8643-2	22.04 24.04	linux-gke, linux-lowlatency, linux-lowlatency-hwe-6.8	2026-08-20
Ubuntu	USN-8656-1	22.04	linux-hwe-6.8	2026-08-20
Ubuntu	USN-8659-2	24.04	linux-hwe-7.0	2026-08-21
Ubuntu	USN-8658-2	22.04	linux-ibm	2026-08-21
Ubuntu	USN-8667-1	20.04	linux-kvm	2026-08-21
Ubuntu	USN-8661-2	22.04	linux-lowlatency	2026-08-21
Ubuntu	USN-8643-3	22.04 24.04	linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency	2026-08-21
Ubuntu	USN-8663-1	24.04 26.04	linux-nvidia, linux-nvidia-7.0	2026-08-20
Ubuntu	USN-8669-1	24.04	linux-nvidia-6.17	2026-08-21
Ubuntu	USN-8664-1	26.04	linux-nvidia-bos	2026-08-20
Ubuntu	USN-8659-4	26.04	linux-oracle	2026-08-25
Ubuntu	USN-8665-1	24.04	linux-raspi, linux-raspi-realtime	2026-08-20
Ubuntu	USN-8630-5	24.04	linux-raspi, linux-raspi-realtime	2026-08-25
Ubuntu	USN-8654-1	16.04 18.04 20.04 22.04 24.04	netty	2026-08-20
Ubuntu	USN-8563-4	22.04 24.04 26.04	nginx	2026-08-19
Ubuntu	USN-8563-3	22.04 24.04 26.04	nginx	2026-08-19
Ubuntu	USN-8676-1	18.04 20.04 22.04 24.04 26.04	openjdk-17	2026-08-26
Ubuntu	USN-8677-1	20.04 22.04 24.04 26.04	openjdk-21	2026-08-26
Ubuntu	USN-8681-1	22.04 24.04 26.04	openjdk-25	2026-08-26
Ubuntu	USN-8673-1	16.04 18.04 20.04 22.04 24.04 26.04	openjdk-8	2026-08-26
Ubuntu	USN-8674-1	18.04 20.04 22.04 24.04 26.04	openjdk-lts	2026-08-26
Ubuntu	USN-8678-1	22.04 24.04 26.04	openssl	2026-08-25
Ubuntu	USN-8675-1	14.04 16.04 18.04 20.04 22.04	perl	2026-08-25
Ubuntu	USN-8653-1	22.04 24.04 26.04	postgresql-14, postgresql-16, postgresql-18	2026-08-20
Ubuntu	USN-8113-2	26.04	tiff	2026-08-19
Ubuntu	USN-8679-1	14.04 16.04 18.04 20.04 22.04 24.04	vim	2026-08-25
Ubuntu	USN-8657-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	vim	2026-08-21
Ubuntu	USN-8543-2	14.04 16.04 18.04 20.04 22.04 24.04 26.04	wget	2026-08-20

Full Story (comments: none)