Welcome to the LWN.net Weekly Edition for August 28, 2025

This edition contains the following feature content:

• The need to reliably preserve our community history: Groklaw's domain falls into the wrong hands.
• Linux's missing CRL infrastructure: how can Linux programs share a certificate revocation list?
• The tangled web of XSLT browser support: major web browsers look poised to dump XSLT support.
• The "impossibly small" Microdot web framework: Miguel Grinberg's EuroPython talk about a web framework for CPython and MicroPython.
• Bringing restartable sequences out of the niche: fixing a little-used kernel feature may require a user-visible ABI change—will anyone notice?
• Shadow-stack control in clone3(): giving user space more control over allocation of shadow stacks for new threads.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

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

Comments (none posted)

The need to reliably preserve our community history

The Internet is a wonderful thing; it allows anybody to look up information of interest. Included in all of that is the history of the free-software development community; how we got to where we are says a lot about why things are the way they are and what might come next. So the takeover of Groklaw rings a loud alarm; we have been reminded that history stored on the Internet is an ephemeral thing and cannot be expected to remain available forever.

Some of our younger readers may not remember what an important resource Groklaw was during a crucial time in our history. Pamela Jones and those who helped her chronicled the ups and downs of the SCO lawsuit, keeping us all informed of what was going on, digging up information that was useful for the defense, and teaching us all a great deal about how the US legal process works. Groklaw did not stop there, though; it was an irreplaceable source of information on software patents, standards, licensing, and more. It was truly one of the key community resources for many years.

The site was important enough that LWN's history contains over 800 articles and comments with links to almost 700 pages on Groklaw.

Unfortunately, Groklaw has now been taken over by somebody whose priorities differ strongly from those of the site's founder. As of this writing, Groklaw has become a platform for the promotion of crypto products. The text of some original articles remains (though decorated with crypto ads) while other articles have been replaced entirely. An important part of the free-software community's history (and that of the commercial realm around it) has been compromised.

The usual policy at LWN is to not attempt to keep up with link rot. Our history runs back to 1998; if we tried to keep up with all of things we have linked to over those years, we would never have the time to do anything else. But finding ourselves to be hosting hundreds of once-important links that now lead to a crypto scammer's site presents a bit of a special case. We have thus, over the last week, replaced every Groklaw link we could with an equivalent link into the Internet Archive. In the end, there were only a half-dozen links that were not archived.

This episode is an important reminder of what can happen to any Internet resource that we depend on. Web sites will only persist for as long as somebody is willing to care (and pay) for them. Certain governments are currently doing their best to disappear inconvenient information from the net — information that others depend on heavily. An era where everything is digital is an era where important history can disappear at any time and, increasingly, it does.

In this case, the Internet Archive has come to the rescue, proving its value once again. But the Internet Archive is a single point of failure, and one that is under attack at that; it, too, could disappear someday. It is not, by itself, a convincing solution to this problem.

What is a convincing solution is unclear at best. With tools like Git, our community has gotten part of the way there; it is hard to imagine a scenario where we would lose the kernel source or its (Git-era) development history. At least, in any such scenario, building a new kernel would likely appear relatively low on the to-do lists of any survivors. Widespread copying of important data is clearly needed, but we cannot easily do that with the Internet as a whole.

Until we figure this out, we will run an increasing risk of ending up in a situation where the only way to learn something about our history is to ask somebody's generative-AI system and hope that it fabricates something that is remotely plausible. That is not quite the world that we were hoping to build. Our species is currently faced with a number of urgent problems; preserving our history is surely one of them.

Comments (22 posted)

Linux's missing CRL infrastructure

In July 2024, Let's Encrypt, the nonprofit TLS certificate authority (CA), announced that it would be ending support for the online certificate status protocol (OCSP), which is used to determine when a server's signing certificate has been revoked. This prevents a compromised key from being used to impersonate a web server. The organization cited privacy concerns, and recommended that people rely on certificate revocation lists (CRLs) instead. On August 6, Let's Encrypt followed through and disabled its OCSP service. This poses a problem for Linux systems that must now rely on CRLs because, unlike on other operating systems, there is no standardized way for Linux programs to share a CRL cache.

CRLs are, as the name might suggest, another solution to the problem of certificate revocation. If a web server loses control of its signing certificate, the administrator is supposed to report this fact to the web site's certificate authority, which will publish a revocation for it. Clients periodically download lists of these revocations from the certificate authorities that they know about; if an attacker tries to use a key that has been revoked in order to impersonate a web site, the client can notice that the key is present in the list and refuse to connect. If the certificate revocation system were ever to stop working, an attacker with stolen credentials could perform a man-in-the-middle attack in order to impersonate a web site or eavesdrop on the user's communications with it.

This system worked well enough in 1999, but as the internet grew, the number of certificate revocations grew along with it. In 2002, RFC 6960 was standardized, creating the online certificate status protocol. Clients using OCSP send a request directly to the certificate authority to validate the certificate of each site they wish to contact. This had the benefit of freeing every client from having to store the CRL of every certificate authority they trusted, but it had a number of drawbacks.

Firstly, using OCSP means waiting to establish an entire second TCP connection to the certificate authority's potentially busy server before completing the TLS handshake with a web site. Perhaps more seriously, it also exposes which web sites a client is visiting to one or more certificate authorities. The original OCSP protocol did not even mandate that requests and responses should be encrypted, so the information about which web sites a client was visiting were potentially visible to everyone who could eavesdrop on data on the wire somewhere along the path.

Those problems were partially solved by the introduction of "OCSP stapling", an extension whereby the server makes its own OCSP request to the certificate authority, and then includes the response (which is signed by the certificate authority, and therefore can't be tampered with) in its opening TLS handshake. The response can be cached by the server for a short time, reducing the load on the certificate authority.

This led to OCSP recapitulating the way certificates work in the first place. A server makes a request to a certificate authority for timestamped cryptographic proof that it is who it claims, with the proof expiring after a certain time, and then presents this proof to clients that connect to it. But since OCSP is not universally supported, the absence of a stapled OCSP response could be as the server intends, or it could be a sign that the connection is being tampered with. Similarly, if a certificate authority doesn't respond to an OCSP request, it could be that its server is down, or it could be that an attacker is blocking the response. Because of the spotty support and extra complexity, in practice some clients began to ignore OCSP timeouts from certificate authorities — which, in the face of an attacker who can interfere with packets on the network, is equivalent to giving up on OCSP entirely.

This is part of what made browser vendors and other interested parties start pushing for certificates with shorter expiration dates: if servers could make requests to OCSP servers automatically, why not do the same for certificates themselves? Short-lived certificates, with lifetimes measured in days, don't really gain anything from OCSP, and don't spend as much time taking up space in a CRL if they are compromised.

In 2023, the CA/browser forum decided to make OCSP optional, and CRLs required once more. The major browsers now use CRLs preferentially, although Firefox will fall back to OCSP if a certificate is not included in its CRL and an OCSP server is available. In 2015, Mozilla began publishing a consolidated CRL that combines the CRLs from various certificate authorities, so that each browser would only need to download and process a single file. It also includes a list of known-good certificates, to avoid the overhead of OCSP for many web sites. Chrome does the same with its own list. Both macOS and Windows also have an OS-wide shared CRL downloading mechanism.

On Linux, outside the browser, there is no such shared mechanism. In practice, many programs just don't support certificate revocation. OpenSSL and other cryptographic libraries include the tools needed to verify certificates against a CRL or an OCSP response, but many programs don't use them. Curl has support for enabling OCSP as well, but it's not enabled by default. Individual programs probably shouldn't be responsible for deciding which CRLs to fetch and keeping them up to date in any case. The Let's Encrypt community forum hosted some discussion about potential solutions, but didn't come to a consensus. Jesper Kristensen noted that certificate validation on Linux is "a mess" in other ways too, with applications often using insecure root certificates:

Most [applications] fill the content of these root stores by copying Mozilla's root store and removing Mozilla-specific attributes from the roots because applications can't read these attributes. But Mozilla has repeatedly said that using their root store while ignoring these attributes is insecure.

Ellie Kanning, who started the discussion, filed follow-up bug reports with OpenSSL, NetworkManager, and Freedesktop's desktop specifications, but none of the projects thought that maintaining a system-wide CRL was in-scope for them. I emailed Kanning to request a comment, and she was clear that she isn't an expert in this area, just a Linux user who is worried about the security of her desktop. She called the situation "an incident waiting to happen", and seemed somewhat resigned to it, given the reception of the bugs she tried to file:

It seems to me like this can only be solved if some of the enterprise users, e.g. rallied behind the Linux Foundation, can be convinced to show some interest in maintaining an up-to-date cert store that has some sort of CRL subscription mechanism like Mozilla's cert push that is available for all Linux systems. Perhaps BSDs could then benefit from this as well.

Some people have suggested that the trend of shortening certificate lifetimes — with the maximum lifetime acceptable to browsers planned to be 47 days by 2029 — means that both CRLs and OCSP are becoming less important, and not worth the difficulty of supporting. Let's Encrypt does offer six-day certificates to a limited number of domains on a trial basis; that validity period is shorter than the lifetime of most OCSP responses. Andrew Hutchings, a developer of WolfSSL, said: "With OCSP being flawed in many implementations and CRLs just not scaling, there isn't really an alternative [to shortening certificate lifetimes] right now."

Kanning doesn't agree, pointing out that even the shortest lifetimes being discussed are still a fairly long time:

The problem is in my opinion that many services will simply not move to short-lived [certificates], especially big enterprises that don't have an IT focus I don't see doing that. The Chrome plan seems to be to limit it to around a month, but that's very long time if a cert were to leak right after issuing.

It's clearly not impossible to have secure TLS connections on a modern Linux desktop. Firefox has the code to support this, and Mozilla already maintains the CRL infrastructure to keep it secure. But with OCSP going away, most applications simply don't have access to the frequently updated CRL that they need in order to correctly establish a modern TLS connection. Linux systems would benefit from a standard way to update and maintain a CRL for all programs to use by default, if anyone decides to tackle the problem.

Comments (65 posted)

The tangled web of XSLT browser support

The Extensible Stylesheet Language Transformations (XSLT) language is used by web browsers to style XML content to make it easily readable; XSLT is part of the HTML living standard that is maintained by the Web Hypertext Application Technology Working Group (WHATWG). Only a small fraction of web sites serve content that requires web browsers to support XSLT, in part because major browser implementations have neglected the technology over the past 25 years. Now, it seems, they would like to rid themselves of it entirely. A plan to disable XSLT in Blink (Chrome's rendering engine) and a pull request by a Google Chrome developer to remove mentions of the specification from the HTML standard have been met with opposition, but arguments in favor of XSLT have proven ineffective.

What is XSLT?

While XML documents are suitable for consumption by computers, they are verbose and not particularly readable by humans. XSLT was developed as a language for transforming XML documents into other formats such as HTML, plain text, or other XML formats. When an XML document is served to a web browser with an XSL stylesheet, the browser can render the document into something more suitable for the user to read. For example, the US Congress web site serves legislation as XML with an XSL stylesheet, such as this bill from 2021.

All of the major web browsers (Chrome, Firefox, Safari, etc.) support client-side XSLT rendering, but they only support the 1.0 version that was finalized in November 1999. XSLT development has continued; the current 3.0 version of the standard was finalized in 2017, but the major browser vendors have shown little interest in keeping up with XSLT developments in this century.

Chrome and Safari use libxslt, while Firefox uses the TransforMiiX XSLT processor. LWN covered some of the history of libxslt in June; that implementation has suffered from a lack of resources for quite some time, and the longtime maintainer, Nick Wellnhofer, announced he was stepping down in June. Iván Chavero has offered to take over the project, and was vouched for by Federico Mena Quintero. He will, however, need to get up to speed with XSLT and the code base for the project.

It is worth noting that client-side rendering is not the only option for using XSLT to render XML as HTML for viewing in a web browser. There are a number of open-source projects, such as Apache Xalan and Saxon, that offer server-side processing for XSLT.

Google has sought to drop support for XSLT a few times. In 2013, Adam Barth notified the Blink development list of an intent to deprecate and remove XSLT from the browser engine. Barth argued that the inclusion of XSLT added "more than its share of complexity, which leads to security vulnerabilities", and that dropping XSLT support would help to remove Blink's dependency on libxml. Ultimately, the proposal was put on hold.

Dominic Cooney tried to deprecate and remove XSLT from Chrome in 2015. After much discussion, Rick Byers replied that Chrome's API owners had met and agreed that they would like to eliminate XSLT from Blink eventually. However, prior experience had taught the team that it was important to do so carefully and with a plan to "minimize the user and developer pain". Byers provided a list of components that such a plan would need to have, including real-world case studies for replacements and a deprecation timeline of up to two years. It is unclear if Cooney submitted such a plan, but a decade later Chrome still ships with libxslt and supports XSLT 1.0.

Call for removal

Removing XSLT from the HTML specification was on the agenda for WHATWG's meeting in March. During the discussion Stephen Chenney expressed concern that usage of XSLT was higher than the use counters indicated, and Dan Clark said "even if the data were accurate, not enough zeroes for the usage to be low enough" for removal (minutes here). Freed suggested during the meeting that "we could just mark it deprecated in the spec, to make the statement that we're not actively working on it". Brian Kardell said that it would be possible to remove XSLT from the MDN web documentation as well. "This would be the first time we have something baseline widely available that we've marked as removed", he noted.

After a few more comments proposing alternatives for developers, it was decided to punt the topic to the next meeting, which was then canceled. The topic was not on the WHATWG meeting agenda again until August, after Mason Freed posted an issue to discuss removing XSLT. Freed said that browser implementations of XSLT were frozen in time with the 1.0 standard, and that the underlying libraries for XSLT, such as libxslt, are aging code bases that are "notoriously susceptible to memory safety vulnerabilities".

He also claimed that there had been a significant decline in client-side usage over the years; he later followed up with a calculation that only one out of 7,891 page loads involves client-side XSLT. The topic of dropping XSLT was skipped during the meeting on August 8, because Freed was absent. Despite that, Freed opened the pull request on August 14 to remove XSLT from the HTML specification.

Anne van Kesteren said that Apple's WebKit team "is cautiously supportive" of removing XSLT, but would likely wait for one implementation to fully remove support. Olli Pettay indicated that Mozilla was also supportive, but cautioned that browsers should add console warnings about the deprecation sooner rather than later. Freed posted links to a WebAssembly (Wasm) polyfill that would process XSLT in the browser without relying on native browser features, to demonstrate that it was possible to move the functionality out of the browser while retaining support.

Discussion

While browser makers were supportive of Freed's push to get rid of XSLT, many others from outside the browser-making group weighed in with questions and objections. For example, Alberto Betella agreed that the security concerns were real, but argued that there is a "real-world and modern use case from the podcasting industry" to use XSLT to beautify raw podcast feeds:

RSS feeds remain one of the last open and decentralized distribution mechanisms on the modern web. Platforms like Spotify and YouTube are increasingly moving toward exclusivity and closed podcasting ecosystems. Supporting browser-side XSLT helps keep RSS accessible and human-friendly, especially for independent creators. This ties in directly with the ethos of openness that underpins the web itself, and also the work of groups like WHATWG.

Freed replied that there was no attempt to change RSS or XML, just the XSLT that is used to make the RSS feeds readable if users click on a link that loads an XML file. He wondered if there might be a way to add a processing instruction to the XML to redirect to an HTML page when the client is a browser.

Some favored the proposal to remove XSLT; Tab Atkins Jr. thought it was fine to remove XSLT from browsers, and said it should be "relatively trivial" to generate HTML from XML on the server:

I don't think there's a strong "Open Web" argument to be made here. XML data files being able to be reformatted into HTML is somewhat of an accident of history; we don't have similar functionality for any other data type, despite, for example, JSON files being vastly more common on the web than XML.

But Timo Tijhof replied that early web browsers had built-in feed browsers and native previews of when users would navigate to RSS feeds, "akin to PDF, JSON, and video viewers in browsers today". Now, there is a missing link in the path between clicking an RSS feed link and opening it in a feed reader. There is a reasonable argument to be made that XSLT is not good enough, he said, "and that we need something even easier to adopt".

Aram Zucker-Scharff, said that getting rid of the capability to visually render RSS feeds would mean "signing a death warrant for RSS feeds as an open technology". He warned that site owners would have to alter pages to link to specific platforms "that enclose and intermediate and disappear the open RSS feed", and echoed Betella's concerns that large companies had already pushed to "enclose" RSS within specialized readers, especially for podcasts.

He said that the "exodus from Twitter" had caused renewed experimentation with RSS, XML, and XSLT. Any solution that does away with native rendering of XML in the browser "is inevitably bad for the web platform's health".

The XSLT implementations are "riddled with CVEs" only because of neglect, Dorian Taylor said. Browser vendors have kept XSLT 1.0 parsers around, but have put as little effort into maintaining them as possible. He proposed that XSLT should be rehabilitated rather than scrapped and asked, "is there truly no appetite for a standard language for transforming markup, a thing we all have to do, on every project, all the time?"

Many other people weighed in to voice support for XSLT in the browser. Freed replied that it was clear that talk of removing XSLT struck a nerve, but he reiterated that the implementations shipped today were old, not well maintained, not widely used, and "a serious risk to all users, not just those who actively use XSLT".

He also acknowledged posts asking for improvement and renewal rather than removal, but argued XSLT was simply a technology that "didn't stand the test of time for client side usage in web browsers". (Emphasis in the original.) The Chrome team was "strongly convinced that this would not be the right way to spend our limited resources".

Shutdown

Taylor pointed out that Google is "literally a 2.5-trillion-dollar company" and that it was the browser vendors that chose not to keep up with XSLT. That comment was later hidden by moderators as off-topic, though it can still be viewed if a user is logged in to GitHub. A number of other comments were hidden as off-topic, and the thread was eventually locked to outside comments.

Freed left a final comment on August 19, in which he said that he cares about the health of the overall web:

I want to minimize the pain folks are feeling about this discussion of XSLT removal. But it's important to remember that ordinary users that fall victim to security vulnerabilities also feel pain, and I'm trying to minimize that too. I proposed some solutions to the concrete use cases I heard in this issue. If there are still gaps, I'd like to work on closing them. It's too bad we can't have that discussion here - I'm guessing we can't re-open this issue for outside comments, due to the overall tone of past comments. Either way, from now on, I'll only be responding to technical conversations, and ignoring the rest, for my own sanity.

The pull request thread was also locked to WHATWG collaborators as "too heated". Shortly after that Domenic Denicola, another member of the Chrome team, commented to remind Freed to update the XSLT section of the DOM living standard as well.

Stage one

The WHATWG has a series of stages for a proposal to be merged into the HTML standard. Currently, Freed's proposal is at stage one, the "incubation" stage, and looks to be headed to the second stage, "iteration". According to WHATWG's documentation, that would signify an expectation that a proposal will be eventually merged into the standard. Usually stage two is accompanied by "a prototype in at least one browser engine".

Barring a sudden reversal, the Chrome team looks poised to ship that prototype before too long. The Chrome Platform Status page for the "feature" to deprecate XSLT lists 2026 as the estimated shipping year, though many of the details for the deprecation plan are still left blank. The page does note, in something of an understatement, that "existing users of XSLT are understandably negative on this removal".

After a number of attempts to dump XSLT, it appears that the Chrome team is finally on its way to making that a reality. Whether the effects of that are as dramatic as the XSLT proponents have suggested remains to be seen; it does, however, seem like a loss for the open web overall.

Comments (26 posted)

The "impossibly small" Microdot web framework

The Microdot web framework is quite small, as its name would imply; it supports both standard CPython and MicroPython, so it can be used on systems ranging from internet-of-things (IoT) devices all the way up to large, cloudy servers. It was developed by Miguel Grinberg, who gave a presentation about it at EuroPython 2025. His name may sound familiar from his well-known Flask Mega-Tutorial, which has introduced many to the Flask lightweight Python-based web framework. It should come as no surprise, then, that Microdot is inspired by its rather larger cousin, so Flask enthusiasts will find much to like in Microdot—and will come up to speed quickly should their needs turn toward smaller systems.

We have looked at various pieces of this software stack along the way: Microdot itself in January 2024, MicroPython in 2023, and Flask as part of a look at Python microframeworks in 2019.

Grinberg began his talk with an introduction. He has been living in Ireland for a few years and "I make stuff". That includes open-source projects, blog posts (on a Flask-based blog platform that he wrote), and "a bunch of books". He works for Elastic and is one of the maintainers of the Elasticsearch Python client, "so maybe you have used some of the things that I made for money".

Why?

With a chuckle, he asked: "Why do we need another web framework? We have so many already." The story starts with a move that he made to Ireland from the US in 2018; he rented a house with a "smart" heating controller and was excited to use it. There were two thermostats, one for each level of the house, and he was "really looking forward to the winter" to see the system in action.

As might be guessed, he could set target temperatures in each thermostat; they would communicate with the controller that would turn the heating on and off as needed. In addition, the system had a web server that could be used to query various parameters or to start and stop the heaters. You could even send commands via SMS text messages; "there's a SIM card somewhere in that box [...] very exciting stuff".

When winter rolled around, it did not work that well, however; sometimes the house was too chilly or warm and he had to start and stop the heaters himself. He did some debugging and found that the thermostats were reporting temperatures that were off by ±3°C, "which is too much for trying to keep the house at 20°". The owner of the house thought that he was too used to the US where things just work; "at least she thinks that in America everything is super-efficient, everything works, and she thought 'this is the way things work in Ireland'". So he did not make any progress with the owner.

At that point, most people would probably just give up and live with the problem; "I hacked my heating controller instead". He set the temperatures in both thermostats to zero, which effectively disabled their ability to affect the heaters at all, and built two small boards running MicroPython, each connected to a temperature and humidity sensor device. He wrote code that would check the temperature every five minutes and send the appropriate commands to start or stop the heaters based on what it found.

So the second half of his first winter in Ireland went great. The sensors are accurate to ±0.5°C, so "problem solved". But, that led to a new problem for him. "I wanted to know things: What's the temperature right now? Is the heating running right now or not? How many hours did it run today compared to yesterday?" And so on.

He added a small LCD screen to display some information, but he had to actually go to the device and look at it; what he really wanted was to be able to talk to the device over WiFi and get information from the couch while he was watching TV. "I wanted to host a web server [...] that will show me a little dashboard".

So he searched for web frameworks for MicroPython; in the winter of 2018-2019, "there were none". Neither Flask nor Bottle, which is a good bit smaller, would run on MicroPython; both are too large for the devices, but, in addition, the standard library for MicroPython is a subset of that of CPython, so many things that they need are missing. A "normal person" would likely have just accepted that and moved on; "I created a web framework instead."

Demo

He brought one of his thermostat devices to Prague for the conference and did a small demonstration of it operating during the talk. The device was connected to his laptop using USB, which provided power, but also a serial connection to the board. On the laptop, he used the rshell remote MicroPython shell to talk to the board, effectively using the laptop as a terminal.

He started the MicroPython read-eval-print loop (REPL) on the board in order to simulate the normal operation of the board. When it is plugged into the wall, rather than a laptop, it will boot to the web server, so he made that happen with a soft-reboot command. The device then connected to the conference WiFi and gave him the IP address (and port) where the server was running.

He switched over to Firefox on his laptop and visited the site, which showed a dashboard that had the current temperature (24.4°) and relative humidity (56.9%) of the room. He also used curl from the laptop to contact the api endpoint of the web application, which returned JSON with the two values and the time. There is no persistent clock on the board, so the application contacts an NTP server to pick up the time when it boots; that allows it to report the last time a measurement was taken.

Grinberg said that he wanted to set the expectations at the right level by looking at the capabilities of the microcontrollers he often uses with Microdot. For example, the ESP8266 in his thermostat device has 64KB of RAM and up to 4MB of flash. The ESP8266 is the smallest and least expensive (around €5) device with WiFi that he has found; there are many even smaller devices, but they lack the networking required for running a web server. The other devices he uses are the Raspberry Pi Pico W with 2MB of flash and 256KB of RAM and the ESP32 with up to 8MB of flash and 512KB of RAM. He contrasted those with his laptop, which has 32GB of RAM, so "you need 500,000 ESP8266s" to have the same amount of memory.

Features

The core framework of Microdot is in a single microdot.py file. It is fully asynchronous, using the MicroPython subset of the CPython asyncio module, so it can run on both interpreters. It uses asyncio because that is the only way to do concurrency on the microcontrollers; there is no support for processes or threads on those devices.

Microdot has Flask-style route decorators to define URLs for the application. It has Request and Response classes, as well as hooks to run before and after requests, he said. Handling query strings, form data, and JSON are all available in Microdot via normal Python dictionaries. Importantly, it can handle streaming requests and responses; because of the limited memory of these devices, it may be necessary to split up the handling of larger requests or responses.

It supports setting cookies and sending static files. Web applications can be constructed from a set of modules, using sub-applications, which are similar to Flask blueprints. It also has its own web server with TLS support. "I'm very proud of all the stuff I was able to fit in the core Microdot framework", Grinberg said.

He hoped that attendees would have to think for a minute to come up with things that are missing from Microdot, but they definitely do exist. There are some officially maintained extensions, each in its own single .py file, to fill some of those holes. They encompass functionality that is important, but he did not want to add to the core because that would make it too large to fit on the low-end ESP8266 that he is using.

There is an extension for multipart forms, which includes file uploads; "this is extremely complicated to parse, it didn't make sense to add it into the core because most people don't do this". There is support for WebSocket and server-sent events (SSE). Templates are supported using utemplate for both Python implementations or Jinja, which only works on CPython. There are extensions for basic and token-based authentication and for secure user logins with session data; the latter required a replacement for the CPython-only PyJWT, which Grinberg wrote and contributed to MicroPython as jwt.py. There is a small handful of other extensions that he quickly mentioned as well.

"I consider the documentation as part of the framework"; he is "kind of fanatical" about documenting everything. If there is something missing or not explained well, "it's a bug that I need to fix". He writes books, so the documentation is organized similarly; it comes in at 9,267 words, which equates to around 47 minutes of reading time. There is 100% test coverage, he said, and there are around 30 examples, with more coming.

A design principle that he follows is "no dark magic". An example of dark magic to him is the Flask application context, "which very few people understand". In Microdot, the request object is explicitly passed to each route function. Another example is the dependency injection that is used by the FastAPI framework to add components; Microdot uses explicit decorators instead.

He used the cloc utility to count lines of code, while ignoring comments and blank lines. Using that, Django comes in at 110,000 lines, Flask plus its essential Werkzeug library is 15,500 lines, FastAPI with Starlette is 14,900 lines, Bottle is around 3,000 lines, while the Microdot core has 765 lines ("believe it or not") and a full install with all the extensions on MicroPython comes in at just shy of 1,700 lines of code.

He ended with an example of how Microdot can be so small by comparing the URL matching in Flask with Microdot. The Flask version does lots more than Microdot, with more supported types of arguments in a URL and multiple classes in the werkzeug.routing module; it has 1,362 lines of code. For Microdot, there is a more limited set of URL arguments, though there is still the ability to define custom types, and a single URLPattern class; all of that is done in 63 lines of code. "I don't intend to support everything that Flask supports, in terms of routing, but I intend to support the 20% that covers 80% of the use cases." That is the overall mechanism that he has used to get to something that is so small.

An audience member asked about whether the Microdot code was minified in order to get it to fit. Grinberg said that doing so was not all that useful for MicroPython, but the code is smaller on the board because it is precompiled on another system; that results in a microdot.mpy file, which is bytecode for MicroPython. For example, on the low-end device he is using for his thermostats, Microdot would not be able to be compiled on the device itself. There are some other tricks that can also be used for reducing the RAM requirements, like putting the code into the firmware as part of the MicroPython binary.

The final question was about performance, and how many requests per second could be handled. Grinberg said that he did not have any real numbers, but that the device he demonstrated is "really really slow". That question led to a blog post in late July where Grinberg tried to more fully answer it.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for travel assistance to Prague for EuroPython.]

Comments (2 posted)

Bringing restartable sequences out of the niche

The restartable sequences feature, which was added to the 4.18 kernel in 2018, exists to enable better performance in certain types of threaded applications. While there are users for restartable sequences, they tend to be relatively specialized code; this is not a tool that most application developers reach for. Over time, though, the use of restartable sequences has grown, and it looks to grow further as the feature is tied to new capabilities provided by the kernel. As restartable sequences become less of a niche feature, though, some problems have turned up; fixing one of them may involve an ABI change visible in user space.

A restartable sequences overview

As the number of CPUs in a system grows, so does the desire to write and run highly parallel programs. In user space, as well as in the kernel, concurrent code using locks eventually runs into scalability problems, leading to an interest in the use of lockless algorithms instead. The kernel has a distinct advantage when it comes to lockless concurrent access, though, in that code running in kernel space can prevent interruptions from interrupts, preemption, or migration to another CPU during critical sections; user space has no such guarantees. So any user-space lockless algorithm must work correctly in an environment where code execution can be interrupted at any time.

Restartable sequences are one solution to this problem. To use this feature, an application must designate a critical section that does some work, culminating in a single atomic instruction that commits whatever change is being made. One of the earliest uses of restartable sequences was a memory allocator that would, within its critical section, identify an object to allocate from a per-CPU list, then remove it from that list with an atomic compare-and-exchange operation.

It would obviously be problematic if this critical section were to be interrupted between the identification of the object to allocate and the final step committing the change. To work around this problem, the application informs the kernel of the critical section by filling a structure (struct rseq_cs) describing the address range of the instructions within that section, along with a special abort address. If the kernel interrupts the execution of the relevant thread, to preempt it, move it to another CPU, or to deliver a signal, it will, on return to user space check for the existence of this structure. If the current instruction pointer lies within the critical section, the kernel will cause execution to jump to the abort address. The thread can then clean up after its aborted attempt and restart the operation.

The hope, of course, is that most runs through the critical section will complete without interruption, accomplishing their job in about the fastest way possible. The extra overhead of dealing with aborts only enters the picture in cases where the critical section is interrupted for some reason.

Using restartable sequences requires setting up a shared memory area using the rseq() system call. The actual critical section almost certainly must be written in assembly. Until relatively recently, there was no support for restartable sequences in the GNU C Library (glibc), though that has been changing. Given the effort that is required to use this feature properly, and given that it is a Linux-only feature, it is not surprising that relatively few application developers have made use of it.

Not so niche anymore

The shared-memory area set up by rseq() allows a thread to tell the kernel when it is executing in a critical section, but the communication through that area goes both ways. Whenever the kernel runs a thread, it will update this area to reflect which CPU and NUMA node the thread ended up on. That information is used by glibc to accelerate functions like sched_getcpu(), which can obtain the needed information directly without calling into the kernel. Other uses of restartable sequences within glibc are under consideration; Mathieu Desnoyers (the creator of this feature) has been advocating for increased use of it within glibc to improve scalability for some time.

Recently, there has been interest in another feature intended to help user space write efficient critical sections: time-slice extension. The idea here is that a thread running in a critical section (perhaps holding a lock) could indicate that fact to the kernel as a way of politely asking to not be preempted, even if its time slice runs out. The kernel could, if it is in a good mood, respond by giving the thread a little bit more time to finish its work and release the lock, so that other threads can proceed. It makes obvious sense to tie a feature like this to restartable sequences, so the time-slice-extension patch set added the "please can I run a little longer" bit to the shared area.

Time-slice extension is a feature that affects the core CPU scheduler, and it is likely to see wider use, so it is not surprising that it has brought more attention to restartable sequences. Thomas Gleixner dug into the patches and, not entirely liking what he saw, put together a proposal for an improved interface for time-slice extension. His changes are likely to be the way this work proceeds in the future, and may merit an article on its own, but Gleixner also found a few things to improve in the restartable-sequences code as well.

The trouble with restartable sequences

His observations in this area led to the posting of a separate patch set aimed at addressing the problems he found with restartable sequences. The end result is significantly improved performance, which is a good thing given that the performance cost of restartable sequences has been starting to attract attention. Jens Axboe, for example, responded to the series saying: "I'd see rseq at 2-3% of overall CPU time last I tested". Kernel developers will work long and hard to eliminate a performance hit much smaller than that. A couple of the things that Gleixner fixed are good examples of how the combination of history and oversights can slow things down.

There are a number of ways in which a user-space thread might lose access to the CPU. The restartable-sequences code in current kernels maintains a field, rseq_event_mask, in each thread's task_struct structure to track those ways; there are separate bits for preemption, the delivery of a signal, and migration to a different CPU. So, for example, if the kernel ends up delivering a signal to a task, it will set the RSEQ_EVENT_SIGNAL bit in rseq_event_mask. When the time comes to return to user space after whatever has happened, rseq_need_restart() will be called to see if a critical section was interrupted; in that case, rseq_event_mask will be consulted to see whether the critical section should be continued, or whether the thread should instead be diverted to the abort address.

Gleixner noticed a couple of interesting problems with this code. One is that the kernel is constantly setting the bits in rseq_event_mask, but those bits are only cleared in rseq_need_restart(), and only when the thread happens to be executing within a critical section at the time. Otherwise those bits just pile up there. That is likely to result in a spurious restart the next time an interrupt occurs while the thread is executing within a critical section, taking away some of the performance advantage that the restartable sequences feature was added to provide.

Perhaps more tellingly, though, those bits exist to allow a thread to specify when its critical section should be aborted. Given the nature of any given section, some sorts of events do not risk breaking the algorithm; a thread might be able to handle a signal without risking concurrent access to data needed by its critical sections, for example. But that feature was deprecated for the 6.0 release in 2022; it added complexity without bringing a lot of value. That deprecation was of a relatively severe variety; any process trying to use that feature would be immediately killed with a SIGSEGV signal. So the chances are pretty good that there are no actual users of the feature in the wild now.

Gleixner replaced all of that machinery with a single "an event happened" boolean value. This elimination also allowed the removal of some accesses to user-space memory, which speeds things up. User-space access from the kernel is never entirely cheap, and the need for Spectre mitigations has made it even slower. As a separate optimization, the series changes the remaining user-space access to the masked user-space-access primitives (added in 6.12) that carry a lower mitigation cost.

There are two ways that a thread running in user space can end up switching to kernel mode: an interrupt happens, or the thread makes a system call. All of the cases that restartable sequences are meant to handle will be the result of an interrupt of some type or another. Threads in critical sections are not supposed to make system calls at all. When running on a kernel built with the DEBUG_RSEQ configuration option, making a system call while in a critical section will result in the immediate termination of the offending process — a gentle hint that the restartable sequences feature is not being used correctly. Without that option (as will be the case in production systems), though, the kernel will handle a system-call return in the same way as an interrupt return: if the thread is running in a critical section and an event has occurred, control will be redirected to the abort handler.

Gleixner's work separates the handling of the interrupt and system-call case, since the time-slice-extension feature will only apply for the former. As an optimization, he removed the restartable-sequences handling for system-call returns; the relevant patch notes:

This changes the current behaviour, which just blindly fixes up the critical section unconditionally in the syscall case. But that's a user space problem when it invokes a syscall from within a critical section and expects it to work. That code was clearly never tested on a debug kernel and user space can keep the pieces.

If there are users that behave in this way, and the code has worked so far, they may be in for an unpleasant surprise once this change goes in. That would likely become the cause of an interesting conversation; "user space was always broken" is not normally considered an acceptable argument for causing a working program to break. There is a good chance that this change will have to be reverted if trouble appears. Given the relatively limited use of restartable sequences so far, though, there is reason to hope that no such user exists.

It may be a little while until we find out, anyway. This work will need review, including, presumably, a look at how it interacts with the time-slice extension work. For extra fun, Gleixner has let it be known that he has found more things to fix, so further patches will be forthcoming. But, at their core, the current changes appear to make sense, addressing problems that have managed to sneak into the code over the years. Almost any body of code can benefit from restarted development involving a fresh set of eyes.

Comments (10 posted)

Shadow-stack control in clone3()

Shadow stacks are a control-flow-integrity feature designed to defend against exploits that manipulate a thread's call stack. The kernel first gained support for hardware-implemented shadow stacks, for the x86 architecture, in the 6.6 release; 64-bit Arm support followed in 6.13. This feature does not give user space much control over the allocation of shadow stacks for new threads, though; a patch series from Mark Brown may, after many attempts, finally be about to change that situation.

As its name suggests, a shadow stack is a sort of copy of a thread's ordinary call stack, but its contents are limited to return addresses. On a system with shadow-stack support, each function call will push the return address onto both the normal and shadow stacks. On return from a function, the return addresses are popped from both stacks and compared; if they do not match, some sort of corruption has occurred and the thread in question is killed.

The shadow stack is marked specially in the system's page tables and is not writable from user space. A shadow stack must also contain a special, hardware-generated token at the top; this token identifies it as a real shadow stack, and prevents multiple threads from using the same shadow stack. The setup requirements mean that the creation of a shadow stack for a thread must be done by the kernel.

When the kernel goes to create a thread's shadow stack, there is an immediate question to be answered: how large should that stack be? The creation of the initial shadow stack for a process can be influenced by the process itself, but that is not true for any threads that the process may create thereafter. Whenever a new thread comes into existence, it is given a shadow stack that is the same size as its regular stack as the kernel's best guess for the right size.

That guess, of course, could be far from the mark. While quite a bit of information — local variables and saved registers, for example — is pushed onto the call stack, the shadow stack only holds return addresses, so there is a good chance that an equally sized shadow stack will be far too large for the thread's needs. If the process creates many threads, the amount of memory wasted by oversized shadow stacks could become significant. There are also (less common) situations, described in the 2023 article, when an equally sized shadow stack could turn out to be too small.

Either way, there would be value in giving a process a voice in the sizing of shadow stacks for the threads it creates. For some time now, Mark Brown has been working on the ability to control shadow-stack allocation when a thread is created with clone3(); that work was covered here in 2023. At that point, the patch set was in its fourth revision; it is now in its 19th iteration, a number of changes have been made, and Brown is expressing hopes that the series will soon be ready to merge.

Early versions of the series allowed user space to specify the address and size of the desired shadow stack, but that ran into opposition from other developers. Subsequent attempts, which only allowed the size of the shadow stack to be specified, proved to be too limiting. In the end, it was decided to just have the parent process create a shadow stack as it sees fit. So, since version 5, the process calling clone3() must first ask the kernel to create the shadow stack for the new thread to use with a call to map_shadow_stack():

    sstack = map_shadow_stack(unsigned long addr, unsigned long size,
    			      unsigned int flags);

The addr and size arguments describe where the newly created stack should be placed and how big it should be; setting addr to zero leaves the placement decision to the kernel. The flags argument must be SHADOW_STACK_SET_TOKEN to cause the kernel place the special token at the top of the stack; otherwise the resulting shadow-stack mapping cannot be used for the new thread. This system call will return the virtual address where the stack is actually mapped.

When the time comes to call clone3(), the new shadow_stack_token field in struct clone_args must be set to point to the shadow-stack token. This requirement might be a bit unintuitive; the pointer is to the token, not to the base of the stack itself. So code using this feature will look something like this:

    struct clone_args args;
    void *ss_addr;

    ss_addr = map_shadow_stack(0, 4096, SHADOW_STACK_SET_TOKEN);
    args->shadow_stack_token = ss_addr + 4096 - sizeof(void *);
    pid = clone3(&args, sizeof(args));

This code allocates a single, 4096-byte shadow stack, letting the kernel choose where the stack should be placed; it then points args->shadow_stack_token at the token that the kernel will have stored at the top of the stack. The thread created with the subsequent clone3() call will, if all goes well, be using the newly created shadow stack. Error handling, obviously, has been omitted.

Brown said, in the cover letter: "I think at this point everyone is OK with the ABI, and the x86 implementation has been tested so hopefully we are near to being able to get this merged?" So far, nobody has spoken up to disagree with that idea. In the absence of surprises, this long-under-development addition to the clone3() API may finally be headed for the mainline.

Comments (19 posted)

Security quote of the week

"Sideloading" is the rentseeker word for "being able to run software of your choosing on a computing device you purchased". There is no reasonable case for an operating system developer having a say over what programs you run on your hardware.

— Eugen Rochko

Google's sideloading thing, passkeys, age verification, they're all basically the same shape; anchoring a fixed identity to a computing act "for safety".

There are millions of safety features in the world meant to protect people from themselves; my personal favorites, as metaphors go, are the standard three-point interlocks industrial paper [cutters] and the cages on big Hobart mixers.

Inexperienced, distracted, even inebriated it's basically impossible to hurt yourself with these accidentally.

Software isn't just a machine, though; it's an idea and an ideology that happens to also be a machine.

That paper cutter won't stop working if whatever's printed on the paper you're cutting is inconvenient for the authorities.

That Hobart mixer's safety cage doesn't prevent you from making bread to feed people in line at the soup kitchen, or in line to vote.

Software has intention and those intentions can be arbitrarily changed, and they are. All the time.

— Mike Hoye

Comments (none posted)

Kernel release status

The current development kernel is 6.17-rc3, released on August 24. Linus said: "Anyway, things seem fairly normal for this phase in the release cycle, nothing stands out. Please keep testing."

Stable updates: 6.16.3 was released on August 23. It consists of a set of ext4 filesystem fixes that are probably a good thing for any 6.16 ext4 user to have.

The 6.16.4, 6.12.44, 6.6.103, 6.1.149, 5.15.190, 5.10.241, and 5.4.297 updates are in the review process; they are due on August 28.

Comments (none posted)

Quote of the week

It reinforces a lesson it took me a while to learn in my career: technical correctness and brilliant ideas are necessary but insufficient for moving Linux forward. This community does not lack for talent and ideas. Maintaining trust and collaboration, that is the hard work of Linux.

— Dan Williams

Comments (none posted)

New restrictions on Android app sideloading

Google has announced a new set of restrictions on the ability of users to install apps on their own devices:

Starting next year, Android will require all apps to be registered by verified developers in order to be installed by users on certified Android devices. This creates crucial accountability, making it much harder for malicious actors to quickly distribute another harmful app after we take the first one down. Think of it like an ID check at the airport, which confirms a traveler's identity but is separate from the security screening of their bags; we will be confirming who the developer is, not reviewing the content of their app or where it came from.

Comments (49 posted)

Arch Linux recent service outages

The Arch Linux project has posted an update about recent service outages that have affected its infrastructure:

The Arch Linux Project is currently experiencing an ongoing denial of service attack that primarily impacts our main webpage, the Arch User Repository (AUR), and the Forums.

We are aware of the problems that this creates for our end users and will continue to actively work with our hosting provider to mitigate the attack. We are also evaluating DDoS protection providers while carefully considering factors including cost, security, and ethical standards.

The post contains information on workarounds to use during the service disruption, and notes that Arch is not sharing technical details about the attack or mitigation while the attack is still ongoing.

Comments (5 posted)

GhostBSD 25.02 released

The GhostBSD project has released version 25.02 of the FreeBSD-based desktop operating system. This release brings GhostBSD up to date with FreeBSD 14.3, includes enhancements for the Software Station package management application, and introduces an "OS X-like" desktop environment based on GNUstep called Gershwin:

This early preview includes:

• GNUstep-based desktop environment with familiar OS X-style interface
• Seamless integration with GhostBSD tools through wrappers for installer, Software Station, Backup Station, and Update Station
• Support for running non-GNUstep applications alongside GNUstep apps
• Several included GNUstep applications to get you started

LWN covered GhostBSD in June 2024.

Comments (none posted)

Rosenzweig: Dissecting the Apple M1 GPU, the end

Alyssa Rosenzweig has written a blog post about her work to help ship a "great driver" for the Apple M1 GPU that supports OpenGL, Vulkan, and enables gaming with Proton.

We've succeeded beyond my dreams. The challenges I chased, I have tackled. The drivers are fully upstream in Mesa. Performance isn't too bad. With the Vulkan on Apple myth busted, conformant Vulkan is now coming to macOS via LunarG's KosmicKrisp project building on my work.

Satisfied, I am now stepping away from the Apple ecosystem. My friends in the Asahi Linux orbit will carry the torch from here.

Rosenzweig indicates her next project will be working on Intel's X^e-HPG graphics architecture. LWN covered her talk on Apple M1/M2 GPU drivers in October 2024.

Comments (12 posted)

FFmpeg 8.0 released

Version 8.0 of the FFmpeg audio and video toolkit has been released.

Thanks to several delays, and modernization of our entire infrastructure, this release ended up being one of our largest releases to date. In short, its new features are:

• Native decoders: APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728
• VVC decoder improvements: IBC, ACT, Palette Mode
• Vulkan compute-based codecs: FFv1 (encode and decode), ProRes RAW (decode only)
• Hardware accelerated decoding: Vulkan VP9, VAAPI VVC, OpenHarmony H264/5
• Hardware accelerated encoding: Vulkan AV1, OpenHarmony H264/5
• Formats: MCC, G.728, Whip, APV
• Filters: colordetect, pad_cuda, scale_d3d11, Whisper, and others

Comments (1 posted)

PyCon US 2025 recap and recordings

The PyCon team has announced that all PyCon US 2025 recordings are now available on its YouTube channel.

We had an amazing and diverse group of community members join us for PyCon US 2025, attending from 58 different countries! By the numbers, we welcomed a total attendance of 2,225 Pythonistas to the David L. Lawrence Convention Center. We couldn't be more grateful for all who supported the Python ecosystem and helped make PyCon US 2025 a huge success.

See the LWN conference index for coverage of some of the talks from PyCon US 2025.

Comments (8 posted)

Report: the state of commercial open source

The Linux Foundation, in cooperation with a couple of other groups, has announced the publication on the intersection of businesses and commercial open-source software (deemed "COSS"). Everything, it seems, is great, and COSS companies make a lot of money for their investors.

Even more encouraging, COSS project communities continue along healthy growth paths after the company receives venture funding. In essence, highly valued COSS companies tend to cultivate more vibrant, diverse, and integral open source ecosystems, reinforcing the idea that business value and community value are tightly coupled in successful COSS models.

Comments (10 posted)

CFP Deadlines: August 28, 2025 to October 27, 2025

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

Deadline	Event Dates	Event	Location
August 31	September 26 September 28	GNU Tools Cauldron	Porto, Portugal
September 1	October 18 October 19	OpenFest 2025	Sofia, Bulgaria
September 10	December 11 December 13	Linux Plumbers Conference	Tokyo, Japan
September 10	December 13 December 15	GNOME Asia Summit 2025	Tokyo, Japan
September 11	November 20	NLUUG Autumn Conference 2025	Utrecht, The Netherlands
September 16	December 13 December 14	LibreOffice Asia Conference 2025	Tokyo, Japan
September 19	December 6 December 7	EmacsConf	online
September 21	January 21 January 23	Everything Open	Canberra, Australia
September 29	September 29 October 2	Alpine Linux Persistence and Storage Summit 2025	Wattenberg, Austria
October 12	March 23 March 26	KubeCon + CloudNativeCon Europe	Amsterdam, Netherlands

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

Events: August 28, 2025 to October 27, 2025

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

Date(s)	Event	Location
August 28	Yocto Project Developer Day 2025	Amsterdam, The Netherlands
August 28 August 29	Linux Security Summit Europe	Amsterdam, Netherlands
August 29 August 31	openSUSE.Asia Summit	Faridabad, India
August 30 August 31	UbuCon Asia 2025	Kathmandu, Nepal
September 8	Workshop on eBPF and kernel extensions (colocated with ACM SIGCOMM)	Coimbra, Portugal
September 17 September 18	Kangrejos	Oviedo, Spain
September 19 September 21	Datenspuren 2025	Dresden, Germany
September 20	Software Freedom Day - NJ	Montclair, NJ, US
September 22 September 24	Kernel Recipes	Paris, France
September 23	Open Tech Day 25: Grafana Edition	Nuremberg, Germany
September 26 September 28	Qubes OS Summit	Berlin, Germany
September 26 September 28	GNU Tools Cauldron	Porto, Portugal
September 27 September 28	Nextcloud Community Conference 2025	Berlin, Germany
September 29 October 1	X.Org Developers Conference	Vienna, Austria
September 29 October 2	Alpine Linux Persistence and Storage Summit 2025	Wattenberg, Austria
September 30 October 1	All Systems Go! 2025	Berlin, Germany
October 3 October 4	Texas Linux Festival	Austin, US
October 12 October 14	All Things Open	Raleigh, NC, US
October 17 October 19	OpenInfra Summit Europe 2025	Paris-Saclay, France
October 18 October 19	OpenFest 2025	Sofia, Bulgaria
October 21 October 24	PostgreSQL Conference Europe	Riga, Latvia

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

Alert summary August 21, 2025 to August 27, 2025

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:13962	9	kernel	2025-08-22
AlmaLinux	ALSA-2025:14137	10	libarchive	2025-08-21
AlmaLinux	ALSA-2025:14135	8	libarchive	2025-08-21
AlmaLinux	ALSA-2025:14130	9	libarchive	2025-08-21
AlmaLinux	ALSA-2025:14101	8	mingw-sqlite	2025-08-20
AlmaLinux	ALSA-2025:14126	8	pki-deps:10.6	2025-08-20
AlmaLinux	ALSA-2025:14177	8	tomcat	2025-08-21
AlmaLinux	ALSA-2025:14181	9	tomcat	2025-08-22
AlmaLinux	ALSA-2025:14178	10	tomcat9	2025-08-22
Debian	DSA-5981-1	stable	chromium	2025-08-21
Debian	DSA-5985-1	oldstable	ffmpeg	2025-08-25
Debian	DLA-4282-1	LTS	firebird3.0	2025-08-25
Debian	DLA-4277-1	LTS	firefox-esr	2025-08-21
Debian	DSA-5980-1	stable	firefox-esr	2025-08-20
Debian	DLA-4281-1	LTS	iperf3	2025-08-24
Debian	DLA-4283-1	LTS	luajit	2025-08-25
Debian	DLA-4278-1	LTS	mupdf	2025-08-22
Debian	DSA-5986-1	stable, oldstable	node-cipher-base	2025-08-26
Debian	DSA-5983-1	stable	qemu	2025-08-22
Debian	DSA-5982-1	stable	squid	2025-08-21
Debian	DLA-4279-1	LTS	thunderbird	2025-08-24
Debian	DSA-5984-1	stable	thunderbird	2025-08-24
Debian	DLA-4280-1	LTS	unbound	2025-08-24
Fedora	FEDORA-2025-60b63cf743	F42	chromium	2025-08-26
Fedora	FEDORA-2025-41a6e9b04d	F41	glab	2025-08-23
Fedora	FEDORA-2025-b597c89f32	F42	glab	2025-08-23
Fedora	FEDORA-2025-6c7178c159	F42	keylime-agent-rust	2025-08-27
Fedora	FEDORA-2025-a1ec5a674c	F41	kubernetes1.31	2025-08-23
Fedora	FEDORA-2025-d78e6ddfe3	F42	kubernetes1.31	2025-08-23
Fedora	FEDORA-2025-8f9b0ca4c7	F41	kubernetes1.32	2025-08-23
Fedora	FEDORA-2025-9b52dfdae9	F42	kubernetes1.32	2025-08-23
Fedora	FEDORA-2025-51e8d5ec56	F41	kubernetes1.33	2025-08-23
Fedora	FEDORA-2025-409ed32016	F42	kubernetes1.33	2025-08-23
Fedora	FEDORA-2025-5869edf3de	F41	libtiff	2025-08-27
Fedora	FEDORA-2025-ac7b2513a8	F42	libtiff	2025-08-27
Fedora	FEDORA-2025-a257fc1a8f	F41	matrix-synapse	2025-08-22
Fedora	FEDORA-2025-62fe746ed0	F41	python3-docs	2025-08-26
Fedora	FEDORA-2025-62fe746ed0	F41	python3.13	2025-08-26
Fedora	FEDORA-2025-8f560fcc9b	F41	python3.6	2025-08-21
Fedora	FEDORA-2025-1903cfae97	F42	python3.6	2025-08-21
Fedora	FEDORA-2025-92719fd556	F41	rust-slab	2025-08-22
Fedora	FEDORA-2025-1e9ad724f8	F42	rust-slab	2025-08-22
Fedora	FEDORA-2025-4f0d6d3522	F41	socat	2025-08-22
Fedora	FEDORA-2025-33885cfff8	F42	socat	2025-08-22
Fedora	FEDORA-2025-a029ba03cc	F41	suricata	2025-08-21
Fedora	FEDORA-2025-f555a9146a	F42	suricata	2025-08-21
Fedora	FEDORA-2025-ab370b9ac9	F41	toolbox	2025-08-24
Fedora	FEDORA-2025-9b8165a4b3	F41	webkitgtk	2025-08-22
Oracle	ELSA-2025-14592	OL10	aide	2025-08-27
Oracle	ELSA-2025-14573	OL8	aide	2025-08-26
Oracle	ELSA-2025-14493	OL9	aide	2025-08-25
Oracle	ELSA-2025-14417	OL10	firefox	2025-08-25
Oracle	ELSA-2025-14442	OL8	firefox	2025-08-25
Oracle	ELSA-2025-14416	OL9	firefox	2025-08-25
Oracle	ELSA-2025-10219	OL7	glibc	2025-08-25
Oracle	ELSA-2025-13940	OL8	go-toolset:rhel8	2025-08-21
Oracle	ELSA-2025-14009	OL10	kernel	2025-08-22
Oracle	ELSA-2025-13962	OL9	kernel	2025-08-21
Oracle	ELSA-2025-14420	OL9	kernel	2025-08-26
Oracle	ELSA-2025-14137	OL10	libarchive	2025-08-21
Oracle	ELSA-2025-14135	OL8	libarchive	2025-08-21
Oracle	ELSA-2025-14130	OL9	libarchive	2025-08-21
Oracle	ELSA-2025-13464	OL7	libxml2	2025-08-25
Oracle	ELSA-2025-14101	OL8	mingw-sqlite	2025-08-21
Oracle	ELSA-2025-14625	OL10	mod_http2	2025-08-27
Oracle	ELSA-2025-14557	OL8	pam	2025-08-26
Oracle	ELSA-2025-14126	OL8	pki-deps:10.6	2025-08-26
Oracle	ELSA-2025-14553	OL8	python-cryptography	2025-08-26
Oracle	ELSA-2025-14560	OL8	python3	2025-08-26
Oracle	ELSA-2025-14546	OL8	python3.12	2025-08-26
Oracle	ELSA-2025-14640	OL9	thunderbird	2025-08-27
Oracle	ELSA-2025-14179	OL10	tomcat	2025-08-25
Oracle	ELSA-2025-14177	OL8	tomcat	2025-08-21
Oracle	ELSA-2025-14181	OL9	tomcat	2025-08-21
Oracle	ELSA-2025-14178	OL10	tomcat9	2025-08-22
Oracle	ELSA-2025-14075	OL9	xterm	2025-08-21
Red Hat	RHSA-2025:14493-01	EL9	aide	2025-08-25
Red Hat	RHSA-2025:14417-01	EL10	firefox	2025-08-25
Red Hat	RHSA-2025:14416-01	EL9	firefox	2025-08-25
Red Hat	RHSA-2025:11533-01	EL10	git	2025-08-26
Red Hat	RHSA-2025:11688-01	EL7	git	2025-08-26
Red Hat	RHSA-2025:11534-01	EL8	git	2025-08-26
Red Hat	RHSA-2025:11793-01	EL8.2	git	2025-08-26
Red Hat	RHSA-2025:11800-01	EL8.4	git	2025-08-26
Red Hat	RHSA-2025:11801-01	EL8.6	git	2025-08-26
Red Hat	RHSA-2025:11794-01	EL8.8	git	2025-08-26
Red Hat	RHSA-2025:11462-01	EL9	git	2025-08-26
Red Hat	RHSA-2025:11796-01	EL9.0	git	2025-08-26
Red Hat	RHSA-2025:11795-01	EL9.2	git	2025-08-26
Red Hat	RHSA-2025:11686-01	EL9.4	git	2025-08-26
Red Hat	RHSA-2025:10854-01	EL10	kernel	2025-08-20
Red Hat	RHSA-2025:14009-01	EL10	kernel	2025-08-25
Red Hat	RHSA-2025:14510-01	EL10	kernel	2025-08-25
Red Hat	RHSA-2025:14413-01	EL7.7	kernel	2025-08-25
Red Hat	RHSA-2025:11850-01	EL8	kernel	2025-08-25
Red Hat	RHSA-2025:14438-01	EL8	kernel	2025-08-25
Red Hat	RHSA-2025:13589-01	EL8	kernel	2025-08-25
Red Hat	RHSA-2025:14136-01	EL8.2	kernel	2025-08-25
Red Hat	RHSA-2025:14418-01	EL8.8	kernel	2025-08-25
Red Hat	RHSA-2025:14511-01	EL8.8	kernel	2025-08-25
Red Hat	RHSA-2025:14420-01	EL9	kernel	2025-08-25
Red Hat	RHSA-2025:13962-01	EL9	kernel	2025-08-25
Red Hat	RHSA-2025:14003-01	EL9.2	kernel	2025-08-25
Red Hat	RHSA-2025:12209-01	EL9.2	kernel	2025-08-25
Red Hat	RHSA-2025:14082-01	EL9.4	kernel	2025-08-25
Red Hat	RHSA-2025:13135-01	EL9.4	kernel	2025-08-25
Red Hat	RHSA-2025:11851-01	EL8	kernel-rt	2025-08-25
Red Hat	RHSA-2025:13590-01	EL8	kernel-rt	2025-08-25
Red Hat	RHSA-2025:14094-01	EL9.0	kernel-rt	2025-08-25
Red Hat	RHSA-2025:12311-01	EL9.2	kernel-rt	2025-08-25
Red Hat	RHSA-2025:14137-01	EL10	libarchive	2025-08-25
Red Hat	RHSA-2025:14135-01	EL8	libarchive	2025-08-25
Red Hat	RHSA-2025:14528-01	EL8.2	libarchive	2025-08-25
Red Hat	RHSA-2025:14525-01	EL8.8	libarchive	2025-08-25
Red Hat	RHSA-2025:14130-01	EL9	libarchive	2025-08-25
Red Hat	RHSA-2025:14141-01	EL9.0	libarchive	2025-08-25
Red Hat	RHSA-2025:14142-01	EL9.4	libarchive	2025-08-25
Red Hat	RHSA-2025:10357-01	EL7	pam	2025-08-26
Red Hat	RHSA-2025:14557-01	EL8	pam	2025-08-26
Red Hat	RHSA-2025:10027-01	EL8	pam	2025-08-26
Red Hat	RHSA-2025:10362-01	EL8.2	pam	2025-08-26
Red Hat	RHSA-2025:10361-01	EL8.4	pam	2025-08-26
Red Hat	RHSA-2025:10359-01	EL8.6	pam	2025-08-26
Red Hat	RHSA-2025:10358-01	EL8.8	pam	2025-08-26
Red Hat	RHSA-2025:9526-01	EL9	pam	2025-08-26
Red Hat	RHSA-2025:10354-01	EL9.0	pam	2025-08-26
Red Hat	RHSA-2025:10024-01	EL9.4	pam	2025-08-26
Red Hat	RHSA-2025:14553-01	EL8	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13098-01	EL8.4	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13104-01	EL8.6	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13100-01	EL8.8	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13102-01	EL9.0	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13101-01	EL9.2	python-cryptography	2025-08-26
Red Hat	RHSA-2025:13103-01	EL9.4	python-cryptography	2025-08-26
Red Hat	RHSA-2025:14560-01	EL8	python3	2025-08-26
Red Hat	RHSA-2025:14546-01	EL8	python3.12	2025-08-26
Red Hat	RHSA-2025:14414-01	EL7	squid	2025-08-25
Red Hat	RHSA-2025:13780-01	EL8	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14432-01	EL8.2	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14486-01	EL8.4	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14433-01	EL8.6	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14434-01	EL8.8	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:13782-01	EL9	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14422-01	EL9.0	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14421-01	EL9.2	webkit2gtk3	2025-08-25
Red Hat	RHSA-2025:14423-01	EL9.4	webkit2gtk3	2025-08-25
Slackware	SSA:2025-232-01		mozilla	2025-08-20
SUSE	openSUSE-SU-2025:15472-1	TW	ImageMagick	2025-08-22
SUSE	openSUSE-SU-2025:15474-1	TW	abseil-cpp-devel	2025-08-22
SUSE	openSUSE-SU-2025:15475-1	TW	aide	2025-08-22
SUSE	openSUSE-SU-2025:15462-1	TW	aws-efs-utils	2025-08-20
SUSE	openSUSE-SU-2025:15488-1	TW	cheat	2025-08-26
SUSE	SUSE-SU-2025:02975-1	oS15.6	cmake3	2025-08-25
SUSE	SUSE-SU-2025:02976-1	oS15.6	cmake3	2025-08-25
SUSE	openSUSE-SU-2025:15464-1	TW	docker-machine-driver-kvm2	2025-08-20
SUSE	SUSE-SU-2025:02972-1	SLE15 oS15.4	ffmpeg-4	2025-08-25
SUSE	SUSE-SU-2025:02990-1	SLE15 oS15.6	ffmpeg	2025-08-27
SUSE	SUSE-SU-2025:02991-1	SLE15 oS15.6	firebird	2025-08-27
SUSE	openSUSE-SU-2025:15468-1	TW	firefox-esr	2025-08-21
SUSE	openSUSE-SU-2025:15476-1	TW	flake-pilot	2025-08-22
SUSE	SUSE-SU-2025:02963-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	gdk-pixbuf	2025-08-22
SUSE	SUSE-SU-2025:02954-1	SLE15 oS15.6	gdk-pixbuf	2025-08-21
SUSE	openSUSE-SU-2025:15469-1	TW	gdk-pixbuf-devel	2025-08-21
SUSE	SUSE-SU-2025:02964-1	SLE15 oS15.6	glibc	2025-08-22
SUSE	openSUSE-SU-2025:0314-1	osB15	go-sendxmpp	2025-08-24
SUSE	SUSE-SU-2025:02988-1	SLE15 oS15.6	govulncheck-vulndb	2025-08-26
SUSE	openSUSE-SU-2025:15470-1	TW	govulncheck-vulndb	2025-08-21
SUSE	openSUSE-SU-2025:15483-1	TW	jetty-annotations	2025-08-23
SUSE	openSUSE-SU-2025:15485-1	TW	jupyter-bqplot-jupyterlab	2025-08-23
SUSE	SUSE-SU-2025:02969-1	SLE15 oS15.6	kernel	2025-08-25
SUSE	SUSE-SU-2025:02977-1	SLE15 SES7.1 oS15.6	kubernetes1.18	2025-08-25
SUSE	SUSE-SU-2025:02968-1	SLE12	libqt4	2025-08-25
SUSE	openSUSE-SU-2025:15487-1	TW	libtiff-devel-32bit	2025-08-23
SUSE	openSUSE-SU-2025:0318-1	osB15	minikube	2025-08-25
SUSE	SUSE-SU-2025:02974-1	SLE12	net-tools	2025-08-25
SUSE	openSUSE-SU-2025:15465-1	TW	nova	2025-08-20
SUSE	SUSE-SU-2025:02971-1	SLE12	pam	2025-08-25
SUSE	SUSE-SU-2025:02970-1	SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	pam	2025-08-25
SUSE	openSUSE-SU-2025:15478-1	TW	pam	2025-08-22
SUSE	openSUSE-SU-2025:15479-1	TW	pdns-recursor	2025-08-22
SUSE	openSUSE-SU-2025:15466-1	TW	pluto	2025-08-20
SUSE	openSUSE-SU-2025:15467-1	TW	polaris	2025-08-20
SUSE	SUSE-SU-2025:02981-1	MP4.3 SLE15 SES7.1	postgresql16	2025-08-25
SUSE	SUSE-SU-2025:02980-1	SLE12	postgresql16	2025-08-25
SUSE	SUSE-SU-2025:02987-1	SLE12	postgresql17	2025-08-26
SUSE	SUSE-SU-2025:02986-1	SLE15 oS15.6	postgresql17	2025-08-26
SUSE	openSUSE-SU-2025:0315-1	osB15	proftpd	2025-08-25
SUSE	SUSE-SU-2025:02985-1	SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	python-urllib3	2025-08-25
SUSE	SUSE-SU-2025:02948-1	oS15.4 oS15.6	python310	2025-08-21
SUSE	SUSE-SU-2025:02984-1	MP4.3 SLE15 oS15.4	python311	2025-08-25
SUSE	SUSE-SU-2025:02982-1	SLE15 oS15.6	python312	2025-08-25
SUSE	SUSE-SU-2025:02983-1	SLE12	python36	2025-08-25
SUSE	openSUSE-SU-2025:15480-1	TW	ruby3.4-rubygem-activerecord	2025-08-22
SUSE	SUSE-SU-2025:02957-1	SLE-m5.3	rust-keylime	2025-08-22
SUSE	SUSE-SU-2025:02961-1	SLE-m5.4	rust-keylime	2025-08-22
SUSE	SUSE-SU-2025:02962-1	SLE-m5.5	rust-keylime	2025-08-22
SUSE	openSUSE-SU-2025:15486-1	TW	terragrunt	2025-08-23
SUSE	openSUSE-SU-2025:15473-1	TW	thunderbird	2025-08-22
SUSE	openSUSE-SU-2025:15489-1	TW	tomcat	2025-08-26
SUSE	SUSE-SU-2025:02978-1	SLE15 oS15.6	tomcat10	2025-08-25
SUSE	openSUSE-SU-2025:15490-1	TW	tomcat10	2025-08-26
SUSE	SUSE-SU-2025:02979-1	SLE15 oS15.6	tomcat11	2025-08-25
SUSE	SUSE-SU-2025:02992-1	SLE15 oS15.6	tomcat11	2025-08-27
SUSE	openSUSE-SU-2025:15491-1	TW	tomcat11	2025-08-26
SUSE	openSUSE-SU-2025:15492-1	TW	ucode-intel-20250812	2025-08-26
SUSE	openSUSE-SU-2025:0322-1	osB15	v2ray-core	2025-08-26
SUSE	openSUSE-SU-2025:0323-1	osB15	v2ray-core	2025-08-26
SUSE	SUSE-SU-2025:02973-1	SLE12	webkit2gtk3	2025-08-25
SUSE	openSUSE-SU-2025:15471-1	TW	wicked2nm	2025-08-21
Ubuntu	USN-7718-1	16.04	binutils	2025-08-26
Ubuntu	USN-7706-1	14.04 16.04	ceph	2025-08-21
Ubuntu	USN-7700-1	20.04 22.04	gcc-10, gcc-11, gcc-12	2025-08-20
Ubuntu	USN-7716-1	22.04 24.04 25.04	gst-plugins-base1.0	2025-08-26
Ubuntu	USN-7717-1	22.04 24.04 25.04	gst-plugins-good1.0	2025-08-26
Ubuntu	USN-7703-2	22.04 24.04	linux-aws-6.8, linux-gcp, linux-gcp-6.8, linux-gkeop, linux-ibm, linux-ibm-6.8	2025-08-20
Ubuntu	USN-7711-1	22.04	linux-azure	2025-08-22
Ubuntu	USN-7712-1	22.04	linux-azure-fips	2025-08-22
Ubuntu	USN-7699-2	24.04	linux-hwe-6.14, linux-oem-6.14	2025-08-20
Ubuntu	USN-7704-3	22.04	linux-ibm, linux-intel-iotg, linux-oracle, linux-raspi	2025-08-20
Ubuntu	USN-7701-3	20.04	linux-iot	2025-08-21
Ubuntu	USN-7704-4	22.04	linux-nvidia	2025-08-21
Ubuntu	USN-7703-3	22.04 24.04	linux-oracle, linux-oracle-6.8	2025-08-21
Ubuntu	USN-7719-1	24.04	linux-raspi-realtime	2025-08-26
Ubuntu	USN-7715-1	22.04 24.04 25.04	nginx	2025-08-25
Ubuntu	USN-7648-2	16.04 18.04 20.04	php7.0, php7.2, php7.4	2025-08-22
Ubuntu	USN-7708-1	16.04 18.04 20.04 22.04 24.04 25.04	poppler	2025-08-21
Ubuntu	USN-7710-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04	python3.13, python3.12, python3.11, python3.10, python3.9, python3.8, python3.7, python3.6, python3.5, python3.4	2025-08-22
Ubuntu	USN-7709-1	22.04 24.04 25.04	ruby-webrick	2025-08-21
Ubuntu	USN-7707-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04	tiff	2025-08-21

Full Story (comments: none)