Welcome to the LWN.net Weekly Edition for April 2, 2026

This edition contains the following feature content:

• The many failures leading to the LiteLLM compromise: a revealing look at the weak links in the software-supply chains we depend on.
• Objections to systemd age-attestation changes go overboard: an attempt to help Linux distributions comply with age-attestation laws generates a shockingly hostile response.
• The role of LLMs in patch review: kernel maintainers object to a requirement to respond to feedback from an LLM-based review system.
• Vibe-coded ext4 for OpenBSD: an attempt at copyleft laundering is shot down.
• Rust's next-generation trait solver: the attempt to rewrite Rust's trait solver is making progress.
• Pandoc: a workhorse for document conversion: a look at the most recent release of the Pandoc document-conversion program.

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 many failures leading to the LiteLLM compromise

LiteLLM is a gateway library providing access to a number of large language models (LLMs); it is popular and widely used. On March 24, the word went out that the version of LiteLLM found in the Python Package Index (PyPI) repository had been compromised with information-stealing malware and downloaded thousands of times, sparking concern across the net. This may look like just another supply-chain attack — and it is — but the way it came about reveals just how many weak links there are in the software supply chains that we all depend on.

A Trivyal pursuit

This story starts with a different project, Trivy, which is a widely used security scanner, distributed under the Apache-2.0 license. As is often the case with these scanners, Trivy releases normally include tests for newly discovered vulnerabilities, so projects that depend on Trivy to detect potential security problems in their code have every reason to want to rerun their scans when a new release is made. Many projects hosted on GitHub thus set up an action so that, when a new release tag shows up for Trivy, new scans are automatically run, just in case Trivy has any new problems to point out.

On March 20, Paul McCarty announced that Trivy had been compromised; Philipp Burckhardt wrote up a detailed report on what was done. Somebody had managed to obtain credentials giving write access to the Trivy repository. This attacker then placed commits with malware in that repository, but they did so without changing any existing branches, avoiding the notifications that would have normally gone out in response to such changes. Instead, a large number of release tags were force-pushed to point to the new commits, which was sufficient to cause other projects to perform automatic Trivy runs.

The Trivy malware was of the information-stealing variety; whenever it ran within a project's context, it would sweep up everything it could get its virtual hands on and send it back to the attackers. Trivy itself was never the primary target; it was just a stepping stone giving access to other projects of interest. Just how many projects this exploit was able to hit may not become clear for some time.

On to LiteLLM

One of the projects that fell into that trap was LiteLLM; specifically, the PyPI credentials of one of its developers (krrishdholakia) were harvested. Those credentials were then used to upload compromised versions of LiteLLM (1.82.7 and 1.82.8) to PyPI, where they would subsequently be downloaded by the large number of people who install LiteLLM each day. Specifically, according to futuresearch, there were 47,000 downloads of the compromised LiteLLM package in just 46 minutes.

The word went out quickly, but the distribution of information was hampered by a set of hostile bots that targeted the LiteLLM GitHub issues (#24512 and #24518) with hundreds of spam comments, creating vast amounts of noise. At one point, people were advised to follow the Hacker News discussion rather than the GitHub issues themselves. The malware on PyPI was taken down quickly, but a lot of damage had been done by then.

The second compromised version of LiteLLM, in particular, used an insidious method to run the hostile code on systems where it was installed. Normally, if one installs a compromised Python program, that program will not be able to do anything until somebody runs or imports it. But when the Python interpreter starts up, it looks in the site-packages directory for files with a .pth suffix, and automatically executes the contents of every one it finds. Normally these files are used to configure Python's import paths and such, but they contain ordinary Python code. The litellm_init.pth file added by the compromised LiteLLM package was thus run anytime a Python interpreter started in the install environment (which may be anywhere in the compromised system if LiteLLM was not installed in a virtual environment), regardless of whether anything from LiteLLM itself was run.

That code, once again, gathered up all of the information it could find, including environment variables, SSH keys, Git credentials, Kubernetes secrets, shell histories, crypto wallets, and more. The whole thing was encrypted, packaged into a tar file, and pushed to a system behind the attacker-controlled litellm.cloud domain. There is no way to know how many of these uploads were done or what was in them — until the attackers make use of what they have learned.

Anybody who may have installed the compromised packages clearly has a significant cleanup job to do, including changing any credentials that might have been exfiltrated. The compromised code, for both Trivy and LiteLLM, has been taken down and should not attack any others, but this episode is far from over.

There are going to be vast numbers of compromised systems out there. It seems unlikely that LiteLLM was the only project that was compromised by the Trivy exploit. We have not heard about the others (with the exception of the telnyx compromise reported just as this article was going out); perhaps the attackers have not yet acted on other credentials that they may have acquired. But the attackers are still out there, and they seem unlikely to sit on any such material for long; expect to hear news of other compromised projects. There is also the matter of all those systems that installed the bad LiteLLM packages; again, there is a wealth of information that will have been collected by the attackers, and they seem likely to want to make use of it at some point.

In the end, this episode represents a multi-level cascading failure. A branch-change notification mechanism was bypassed. A software system meant to improve security instead compromised it. Important credentials were stored where automated exploits could read them, and two-factor authentication was evidently not in use. The protections meant to prevent the uploading of hostile packages failed. The ability of Python packages to add configuration code allowed an exploit to reach beyond the compromised package itself. Any of these failures on their own would have been enough to cause a lot of damage; taken together, then enabled a catastrophic security failure that may have only begun to play out.

Comments (41 posted)

Objections to systemd age-attestation changes go overboard

In early March, Dylan M. Taylor submitted a pull request to add a field to store a user's birth date in systemd's JSON user records. This was done to allow applications to store the date to facilitate compliance with age-attestation and -verification laws. It was to be expected that some members of the community would object; the actual response, however, has been shockingly hostile. Some of this has been fueled by a misinformation campaign that has targeted the systemd project and Taylor specifically, resulting in Taylor being doxxed and receiving death threats. Such behavior is not just problematic; it is also deeply misguided given the actual nature of the changes.

Age-attestation and -verification laws that place requirements on operating-system providers have passed in California and Brazil, and are being discussed in many other states and locations. This has led a number of Linux distributions to consider ways that they can comply with the laws if necessary. One idea that is being worked on is to add parental controls to the XDG Accounts portal which is a mechanism that allows applications to query for information about users, such as their name or avatar image. It can gather this information from various data sources, including systemd.

Taylor's changes would allow a system administrator to set and modify each user's birth date stored as birthDate in the YYYY-MM-DD format. Unprivileged users would not be able to modify the date, but could query it, so applications could retrieve the user's age via the Accounts portal. Note that this change does not automatically require or even prompt a user to provide their birth date; it only provides a way for applications to store the date. In other words, Taylor has only implemented one feature that could be used in a larger age-attestation system. His work does not implement an attestation system on its own, nor would such systems be prevented if the change were reverted; the birth date could simply be housed in another data store.

There have been some reasonable objections to the feature; as one example, Jeremy Soller, who works for System76, said that the company had been in talks with legislators, and it might be that open-source operating systems would be exempted from these laws in the end. Even if that does not happen, he worried that a dependency on systemd "which is decidedly unportable to non-Linux" systems, would require two implementations to exist.

Zbigniew Jędrzejewski-Szmek replied that while it was possible California's law would be changed, "similar ideas are popping up in other contexts and it's unlikely that they'll all go away". Ultimately, Luca Boccassi merged Taylor's changes after a bit of back-and-forth about the implementation.

Age attestation vs. verification

It is worth calling out that there is also a substantial difference between age attestation and age verification; attestation allows users or administrators of a system to provide information about their age. The person controlling the device is supplying the information. What is being discussed, for Linux systems, is a way for the user or administrator to supply the user's birth date. How that will be implemented for various desktop environments and distributions is still up in the air; the systemd birthDate field would be a small piece of any attestation systems that wind up being implemented.

The most important distinction is that an attestation system is under the control of the local administrator of a system; no documents are being checked or handed to a third party. Nothing prevents a person controlling the Linux system from supplying a random date rather than the accurate date. The services used for age attestation could also be disabled entirely by the administrator of the system, of course. Just because a Linux distribution ships a feature does not mean that users of the distribution are obliged to keep it turned on; but it should serve to satisfy the legal requirements placed on operating-system suppliers.

Age verification, on the other hand, generally requires furnishing a third party with some kind of proof—such as government identification—about one's birth date. There are many reasons to strongly object to age-verification schemes; privacy concerns and the potential for identity theft when third-party providers inevitably suffer data breaches are two that quickly come to mind. However, age verification is not what is being considered here. The fact that the two are being conflated, though, is not surprising—especially since Taylor used the term "age verification" in his pull request.

Controversy

As a rule, it does not take a great deal to cause a controversy in the open-source community. We are, to put it mildly, an opinionated bunch. Many people choose to use Linux because they wish to have full control over their operating system and applications; a change that offers exactly zero real benefit to the user other than compliance with a poorly thought-out law is not going to spark joy. One could predict a certain amount of objection and opposition to implementing age attestation no matter what.

However, the controversy appears to have been helped along by a few actors looking to stir the pot. In a discussion on the Debian developer mailing list about age-attestation systems, Otto Kekäläinen pointed to a site called The TBOTE Project that has been publishing information on the lobbying campaign to push an age-assurance law that has been introduced in a number of states across the US. Age assurance means that a device provides attestation of a user's age that has been verified, rather than self-supplied. For example, New York's Senate Bill S8102A requires "manufacturers of internet-enabled devices to conduct age assurance to determine a user's age category". This means that a device owner will likely need to perform some kind of age verification, and then the result would be stored locally.

The site also dedicates a section to the systemd project. To say it is conspiratorial in nature would be an understatement. It attempts to cast the systemd change as a sinister plot that has "altered the identity infrastructure of every major Linux distribution". While the site does not shy away from casting a spotlight on individuals in the systemd project, it does not disclose the person or persons who are behind The TBOTE Project. Aaron Rainbolt said that the site had been "used as part of a doxxing/harrassment attack" against an individual, which seems to refer to Taylor. "Given that the person running this repo actively helps doxx people, I consider them (semi-)malicious".

The TBOTE Project site is not alone in trying to fan the flames. Sam Bent, who describes himself as a YouTuber and content creator on his LinkedIn profile, published a hit piece against Taylor on March 20. It would also be best described as "malicious"; the less said about its contents the better, but it seems to have inspired some number of personal attacks against Taylor well beyond the usual objections in a GitHub pull-request comment thread. In an interview with the "It's FOSS" web site, Taylor described some of the backlash he has received; it is far beyond what an open-source contributor (or anyone else) should ever have to put up with:

I understood that the change was not going to be popular, but I was expecting civil discourse and a level-headed response. Things like death threats and harassment are not okay, especially when it negatively impacts unrelated third parties. However, the doxxing (and I am NOT just talking about my name, email and resume – that stuff is on my website, and is reasonably public. I don't commit with a pseudonym and I think it's reasonable to critique my contributions), hate mail, racism, homophobia, antisemitism, editing of my photo, turning my profile picture into memes and making fun of my appearance, etc. made me lose a bit of faith in the FOSS community. I'm really disappointed at the reaction. We should do better than this.

The unpleasant truth

The frustration and anger over government and industry pushes for age verification is justified; taking it out on open-source maintainers or projects is not. Reasonable people can disagree whether it is likely that, say, California would choose to prosecute Linux vendors or projects for non-compliance. We can certainly hope that logic would prevail, but one only needs to look around at the world today to determine that logic wins the day much less often than it should. Hoping that legal authorities will choose to overlook a project, or that the stars will align to provide a positive legal outcome, is not an effective strategy when it comes to avoiding real legal risk.

If a person or project wishes to take on that risk to challenge such laws, that is commendable; but demanding that another person or project take on such risks is unreasonable. The monetary costs of mounting a defense against a state government, even if ultimately successful, would be substantial and more than many projects could afford.

The efforts to push age-verification laws and similar unpleasantness did not show up on the open-source community's doorstep without warning. These political winds have been gathering strength for years; if they are to be challenged, they need to be dealt with by movements and organizations designed to take them on. Rather than harassing individual maintainers, for example, concerned people would do better to put their weight behind organizations like the Electronic Frontier Foundation (EFF) that have spent decades fighting exactly this sort of thing.

It is possible to counter legislative threats to open source and privacy without lobbing death threats at open-source maintainers (or anyone else). The European Union's Cyber Resilience Act (CRA) is a somewhat recent example. The CRA sets automatic security update and incident report requirements for products with digital elements; in non-legislative speak, this means software and devices that run software. The original drafts of the legislation would have saddled freely available open-source software with the same requirements as commercial products.

One might consider it reasonable and even desirable, for example, to require the manufacturer of a router, mobile phone, or car-entertainment system to provide security updates. But the same requirements would have applied to open-source maintainers and projects even when no money had changed hands. That, of course would have been a disaster for open source. FOSS organizations, such as the Eclipse Foundation, Linux Foundation Europe, Open Source Initiative, as well as several others pushed back politely, but firmly, and succeeded in having the CRA draft modified to exempt open-source software.

Attacking open-source maintainers, projects, or Linux distributions is not going to stop government and industry pushes for age verification. In fact, it will not be effective at anything except contributing to maintainer burnout, weakening the larger community, and perhaps encouraging developers to do more behind closed doors—or to stop contributing entirely.

Comments (105 posted)

The role of LLMs in patch review

Discussion of a memory-management patch set intended to clean up a helper function for handling huge pages spiraled into something else entirely after it was posted on March 19. Memory-management maintainer Andrew Morton proposed making changes to the subsystem's review process, to require patch authors to respond to feedback from Sashiko, the recently released LLM-based kernel patch review system. Other sub-maintainers, particularly Lorenzo Stoakes, objected. The resulting discussion about how and when to adopt Sashiko is potentially relevant to many other parts of the kernel.

Morton began by saying that the current way Sashiko integrates into the memory-management workflow isn't working. He merges patches to his tree, and "then half a day later a bunch of potential issues are identified." Morton stated that he was going to further increase the lag between seeing a patch set on the mailing list and merging it to his tree, to give Sashiko time to produce feedback and patch authors time to respond to it. He also wanted its reviews distributed to a wider audience — partly to better determine how useful its comments are, which he is "paying close attention to".

Stoakes said that he would look at the Sashiko reviews for the patch set, but asked Morton to hold off on incorporating it into the subsystem's workflow. He said that he appreciates the tooling, but that it is currently too noisy to use in that way. Stoakes referenced his message in the thread introducing Sashiko (that began on March 17) where he expressed the opinion that its false-positive rate was higher than his own experience using Chris Mason's kernel-review prompts. David Hildenbrand agreed that the false-positive rate was too high to be useful.

Roman Gushchin, Sashiko's creator, told Morton that he was actively working on integrating Sashiko with the kernel's email-based workflow, and that he hoped to have it sending reviews to appropriate recipients within the next week. Morton took the opportunity to ask about another problem with the tool — that many patch sets sent to the mailing list fail to apply in Sashiko's environment. In a follow-up message he expressed his intention not to apply patches to his tree that the system couldn't. Gushchin explained that Sashiko tries to apply patch sets to several bases, in order. For memory-management patches, it uses the patch set's base commit (if specified), then the mm-new tree, followed by mm-unstable, mm-stable, linux-next, and finally Linus Torvalds's tree. The review system evaluates the code in the first tree where the application attempt is successful. He didn't address why mailing-list patches would be failing to apply to these trees, however.

Stoakes asked Morton to hold off on integrating Sashiko so deeply into his workflow:

Andrew, for crying out loud. Please don't do this.

2 of the 3 series I respun on Friday, working a 13 hour day to do so, don't apply to Sashiko, but do apply to the mm tree.

I haven't the _faintest clue_ how we are supposed to factor a 3rd party experimental website applying or not applying series into our work??

He went on to say that he was not attempting to disrespect Gushchin or his efforts, but that even Gushchin had agreed that the tool was not ready to become a blocking component of the development process. Gushchin replied to say that working on Sashiko had increasingly shown him the subjectivity of reviews, and the importance of social context in providing good reviews. He acknowledged that it wasn't "perfect in any way" but suggested that some level of false positives (for example, 20%) was acceptable from a tool that catches the majority of bugs before they're merged. He suggested that this might be a reasonable lens through which to view Sashiko's current performance and future development.

Stoakes replied to clarify that he was objecting to Morton's unilateral demand that "every single point Sashiko raises is responded to". He was emphatically not blaming Gushchin for failures of the memory-management subsystem's review model, and thought the tool was promising. He reiterated his perception that the tool's false-positive rate was much higher than other people were claiming, and that — given its inexhaustible ability to produce new reviews that require human attention — it was important to think critically about what role it can play in the review process. Incorporating the tool in its present state, as anything other than a simple advisory, would increase the workload on the already overworked memory-management maintainers, he said.

This sentiment resonated with Pedro Falcato, who agreed that Sashiko should remain optional for the time being. Morton disagreed:

Rule #1 is, surely, "don't add bugs". This thing finds bugs. If its hit rate is 50% then that's plenty high enough to justify people spending time to go through and check its output.

[...]

Look, I know people are busy. If checking these reports slows us down and we end up merging less code and less buggy code then that's a good tradeoff.

Avoiding bugs is important, Falcato agreed, but: "I simply don't think either contributors or maintainers will be particularly less stressed with the introduction of obligatory AI reviews." He suggested that simply codifying the memory-management review process (as the netdev review process has been) would be more helpful than mandating the use of Sashiko (a suggestion that Mike Rapoport later supported). Falcato also pointed out that Sashiko is experimental, untested software, and it should probably not be made critical to the process yet on those grounds.

Morton responded by looking at actual replies to Sashiko's reviews on the linux-mm mailing list. Out of about 35 emails, 22 received replies indicating that alterations were definitely needed, with the rest being more ambiguous, being false reports, or not being responded to. He expressed the opinion that such a hit rate of finding actual problems in patches was worth the pain of figuring out how to integrate Sashiko into the process. "That's a really high hit rate! How can we possibly not use this, if we care about Rule #1?"

Stoakes disagreed with Morton's interpretation of the data, pointing out that those 22 emails indicate cases where the tool was correct in at least one individual observation. Since it normally sends multiple suggestions and questions per review, the actual rate of false positives for individual comments must be substantially worse than that.

Stoakes again reiterated that he found Sashiko useful, and was using it in his own reviews to some degree. The problem was in making it a mandatory part of the process. He suggested that Morton should delegate the decision of whether and how to use Sashiko to the sub-maintainers, avoid requiring that its automation cleanly applies a patch before accepting it, avoid requiring that every element of its reviews be responded to, and trust sub-maintainers to discard any parts of the reviews that are not both valid and important.

Sashiko is, at the time of writing, not even a month old. According to its statistics page, it has written over 10,000 reviews in that time, with an average of approximately 3,500 words of output (counting quoted source code) per patch. It is, quite literally, producing words faster than any individual person could reasonably read. But approximately half of those words, according to various different statistics, are about bugs that no human reviewer spotted ahead of time — either due to the difficulty of reviewing complex kernel code, or just due to a lack of infinite time to dedicate to the prospect. And several kernel contributors are finding the reviews useful.

As is the case unfortunately often, the problem posed by the use of Sashiko is a social one, not a technical one: how much extra reading, hallucinated problems, delays in the review process, robotic gatekeeping, and reliance on proprietary models is acceptable in order to make sure the kernel accepts less buggy code? It's a question that will eventually touch every subsystem of the kernel and beyond, not just the memory-management code, and one that undoubtedly deserves a lot of discussion. There are no easy answers, but hopefully the kernel community will eventually be able to reach a consensus.

Comments (16 posted)

Vibe-coded ext4 for OpenBSD

A number of projects have been struggling with the question of which submissions created by large language models (LLMs), if any, should be accepted into their code base. This discussion has been further muddied by efforts to use LLM-driven reimplemention as a way to remove copyleft restrictions from a body of existing code, as recently happened with the Python chardet module. In this context, an attempt to introduce an LLM-generated implementation of the Linux ext4 filesystem into OpenBSD was always going to create some fireworks, but that project has its own, clearly defined reasons for looking askance at such submissions.

It all started on March 17, when Thomas de Grivel posted an ext4 implementation to the openbsd-tech mailing list. This implementation, he said, provides full read and write access and passes the e2fsck filesystem checker; it does not support journaling, however. The code includes a number of copyright assertions, but says nothing about how it was written. In a blog post, though, de Grivel was more forthcoming about the code's provenance:

No Linux source files were ever read to build this driver. It's pure AI (ChatGPT and Claude-code) and careful code reviews and error checking and building kernel and rebooting/testing from my part.

There were a number of predictable concerns raised about this code, many having to do with the possibility that it could be considered to be a derived product of the (GPL-licensed) Linux implementation. The fact that the LLM in question was almost certainly trained on the Linux ext4 code and documentation does not help. Bringing GPL-licensed code into OpenBSD is, to put it lightly, not appreciated; Christian Schulte was concerned about license contamination:

I searched for documentation about that ext4 filesystem in question. I found some GPL licensed wiki pages. The majority of available documentation either directly or indirectly points at GPL licensed code. In my understanding of the issue discussed in this thread this already introduces licensing issues. Even if you would write an ext4 filesystem driver from scratch for base, you would almost always need to incorporate knowledge carrying an illiberal license.

Theo de Raadt, however, pointed out that reimplementation of structures and algorithms is allowed by copyright law; that is how interoperability happens. One should not conclude that De Raadt was in favor of merging this contribution, though.

From the OpenBSD point of view, the copyright status of LLM-generated code is indeed problematic, for the simple reason that nobody knows what that status is, or even if a copyright can exist on that code at all. Without copyright, it is not possible to grant the project the rights it needs to redistribute the code. As De Raadt explained:

At present, the software community and the legal community are unwilling to accept that the product of a (commercial, hah) AI system produces is Copyrightable by the person who merely directed the AI.

And the AI, or AI companies, are not recognized as being able to do this under Copyright treaties or laws, either. Even before we get to the point that the AI's are corpus-blenders and Copyright-blenders.

So as of today, the Copyright system does not have a way for the output of a non-human produced set of files to contain the grant of permissions which the OpenBSD project needs to perform combination and redistribution.

Damien Miller said something similar:

Who is the copyright holder in this case? It clearly draws heavily from an existing work, and it's clear the human offering the patch didn't do it. It's not the AI, because only persons can own copyright. Is it the set of people whose work was represented in the training corpus? Was the it the set of people who wrote ext4 and whose work was in the training corpus? The company who own the AI who wrote the code? Someone else?

We don't know. The law hasn't caught up to the technology yet and we can't take the risk that, when it does, it will go in a way that makes use of AI-written code now expose us to legal risk.

These words did not resonate entirely well with de Grivel, who refused to retract his copyright claims on the machine-generated code. He also is clearly pleased with the kinds of things one can do with LLMs:

We can freely steal each other in a new original way without copyright infringment its totally crazy the amount of code you can steal in just 1h. What took 20 years to Bell labs can now be done in 20 hours straight.

The conversation went on for some time, but the result was never really in doubt; De Raadt made it clear when he said: "the chances of us accepting such new code with such a suspicious Copyright situation is zero". In the above-mentioned blog post, de Grivel added a note on March 23 that he would respond by removing all of the LLM-generated code, leaving only code that he has written himself. After this episode, though, convincing others that he really did write any subsequent versions on his own may be an uphill battle. He acknowledged that "forking OpenBSD" might be easier.

The number of people who have concluded that they can have an LLM crank out thousands of lines of code and submit the result to the project of their choice is growing quickly. Needless to say, these people are not always diligent about documenting the provenance of the work they are submitting in their own names. There may well come a time when it turns out that even the sharp eyes of OpenBSD reviewers are unable to keep all of it out of their repositories.

All of this code is setting some worrisome potential traps for the future. As Tyler Anderson pointed out, the price of these tools is unlikely to go down as development projects become more dependent on them. Who will maintain this code, when its original "author" does not understand it and has no personal investment in it, is unclear at best. And if there is, in fact, a potential copyright problem inherent in this code, there will have to be a lot of scrambling (or worse) when it comes to light. Given all of that, it is unsurprising that many projects, especially those with longer time horizons, are proving reluctant to accept machine-generated submissions.

Comments (98 posted)

Rust's next-generation trait solver

Rust's compiler team has been working on a long-term project to rewrite the trait solver — the part of the compiler that determines which concrete function should be called when a programmer uses a trait method that is implemented for multiple types. The rewrite is intended to simplify future changes to the trait system, fix a handful of tricky soundness bugs, and provide faster compile times. It's also nearly finished, with a relatively small number of remaining blocking bugs.

Trait solving

Traits in Rust are similar to typeclasses in Haskell or interfaces in Java: they are a set of associated functions that can be implemented for different types. Library code can use the functions from a trait on any type that implements the trait, even if that type is foreign to the library. When it comes time to generate code, however, the compiler needs to know which specific type is being used, and where its trait implementation lives, so that it can call the correct function. Trait implementations can be generic, and therefore apply to multiple concrete types. Figuring out which trait implementation is relevant to a particular type is the job of the compiler's trait solver.

Most of the time, this is straightforward: the compiler just needs to find a trait implementation of the form impl Trait for Type {...}. The problem grows more complex when considering generic types. For example, a Vec can be cloned if and only if the type of elements it contains can be cloned. In the standard library, there is a trait implementation block that is equivalent to the following (after expanding some syntactic sugar and disregarding the irrelevant A parameter):

    impl<T> Clone for Vec<T>
    where T: Clone
    { ... }

This declaration can be viewed as an instruction for the trait solver: in order to find the Clone implementation for a Vec<Foo>, first find the Clone implementation for Foo. That implementation can be used to construct a working implementation for Vec<Foo>. The current trait solver follows these chains of instructions in a straightforward way. For each trait implementation that must be found, it determines whether it is best resolved through finding an impl statement or through using a where-bound (i.e. a where clause asserting that some generic type implements a trait). These can depend on other trait implementations existing, as in the Vec example, in which case the compiler adds them to a work list. In logic programming, these kinds of prerequisites that must be satisfied for another goal to be reached are called obligations; the compiler keeps taking obligations from the work list and processing them until they have all been eliminated. If they cannot be, an error is indicated.

This approach breaks down with more complicated types, however. It is possible to construct a situation where the obligations to be discharged form a loop. Doing so is a bit complicated, however, so even a minimal example is somewhat long:

    // Create a trait that has an associated generic type. Types that implement
    // Wrap correspond to a particular choice of Wrapper.
    trait Wrap {
        type Wrapper<T>;
    }

    // A singly linked list structure, with the payload omitted for brevity.
    // Each 'next' pointer goes to another list node wrapped in the Wrapper type
    // for some generic type W that must implement Wrap
    struct Link<W: Wrap> {
        next: Option<Box<W::Wrapper<Link<W>>>>
    }

    // Link structures can be formatted for debug print statements when their
    // contents can be — the omitted implementation calls the Debug
    // implementation for next's type, hence the second requirement.
    impl<W> Debug for Link<W>
    where W: Wrap,
          Option<Box<W::Wrapper<Link<W>>>>: Debug {
        ...      
    }

    // My Wrapper is a structure that wraps some other type T as its only field.
    struct MyWrapper<T = ()>(T);

    // And its associated wrapper type is just itself.
    impl Wrap for MyWrapper {
        type Wrapper<T> = MyWrapper<T>;
    }

    // Finally, wrappers can be formatted for debug print statements when the
    // wrapped value can be.
    impl<T> Debug for MyWrapper<T>
    where T: Debug { ... }

In order for the compiler to prove that Link<MyWrapper> implements Debug, it needs to show that a whole chain of requirements holds:

    Link<MyWrapper>: Debug ->
    Option<Box<MyWrapper::Wrapper<Link<MyWrapper>>>>: Debug ->
    Box<MyWrapper::Wrapper<Link<MyWrapper>>>: Debug ->
    MyWrapper::Wrapper<Link<MyWrapper>>: Debug ->
    Link<MyWrapper>: Debug

... but that chain eventually leads the compiler right back to where it started. Attempting to compile a Rust program that uses the Debug implementation of Link results in the error: "overflow evaluating the requirement `Link<MyWrapper>: Debug`".

In this case, however, it should be possible in theory for the compiler to generate an implementation of Debug for the same reason that assemblers can handle instructions that refer to their own address: the compiler can start generating the implementation, leaving a placeholder for the address, and then fill the address in once it knows it. At the stage where the trait solver runs, it isn't dealing with actual addresses, but the same idea applies; writing the Debug implementation for Link<MyWrapper> is a matter of "tying the knot" in a data structure representing the code to produce a structure that refers to itself.

The above example is contrived, but that's because this limitation of the language tends to come up in complex, highly generic code. Self-referential types are nothing new; it's only trying to abstract over them with traits that causes the problem. Code like that is not something that every programmer will need to write, but it is something that can make Rust libraries more flexible. Currently, crate authors need to work around this trait resolution problem by restructuring their interfaces to avoid creating loops in the trait solver.

A new approach

The trait solver's behavior isn't an inherent aspect of the problem, however. It's an implementation choice that was made essentially by default as the language's trait system slowly became more complex. The project to rewrite the trait solver began in 2015 with Chalk, an attempt to formalize Rust's type system. It compiles the rules of the type system — such as the mechanics of trait solving — into a Prolog-like system of logical inference rules that can then be solved generically with well-known logic-programming techniques. Chalk has two internal implementations of logical inference with their own strengths and weaknesses: the SLG solver (which uses an approach based on Prolog tabling) and the recursive solver, which more closely matches the operation of Rust's original trait solver. The SLG solver can handle some kinds of loops that the recursive solver cannot.

Rust developers determined that Chalk wasn't a good fit for the Rust compiler, however. One major concern was with maintaining the usefulness of error messages; the current implementation produces good error messages for simple mistakes, but Chalk's error messages have lagged behind. In 2023, the project decided to rewrite the trait solver within the compiler, using lessons from the first implementation and from Chalk.

The rewrite, called the next-generation trait solver, makes use of caching to both speed up trait solving and to defeat cycles. When called upon to start finding a trait implementation for a type, it starts by assuming that such an implementation will be found, and making a spot for it in the cache — it is marked as provisionally true, but cannot yet be fully relied on. Then the solver follows the chain of logical inferences in much the same manner as the current solver, with the exception that it looks results up in the cache when possible. When it derives a new piece of information, that is added to the cache; if deriving the new information relied on any provisional cache entries, the new entry is also marked as provisional.

If the trait solver ever reaches a point where the only remaining logical obligations refer to provisionally true cache entries, the entries are upgraded to actually true and can be referenced by other type-checking operations. On the other hand, if it doesn't reach such a point, the provisional cache entries are invalidated, and that branch of the computation is considered failed. It will either fail entirely (and show an error to the user), or continue trying some alternative potential solution.

In the case of the example above, when the new solver reached the state of needing to prove that Link<MyWrapper> implements Debug for the second time, it would see that the trait implementation had been cached as provisionally true by the previous exploration and (lacking other logical obligations) conclude that Link<MyWrapper> really does implement Debug.

Currently, the next-generation trait solver only extends this notion of provisional cache entries to a limited number of built-in traits, such as Send, but the plan is to eventually enable the behavior for all traits. The Rust developers are fairly sure that enabling this feature will just allow some code (like the above example) that doesn't currently compile to work, but since this is a logically intricate piece of code on which the correctness of the type system depends, they don't want to be too hasty. The next-generation trait solver itself is currently marked experimental for much the same reason.

One other interesting aspect of the next-generation trait solver is canonicalization. Since its design relies heavily on caching, the more types that can be cached, the faster compilation using the new trait solver will be. For that reason, logical obligations encountered in the course of trait solving are rewritten into a format that removes as many type variables and intermediate results as possible. This also has the nice effect of making it easy to reconstruct proof trees explaining how the compiler reached a particular answer. These are used to create more detailed error messages by explaining which options were tried and why they didn't work. Since the proof trees don't need to be generated unless an error message needs to be shown, being able to reconstruct them from the cache avoids the overhead of constructing them for code that does compile.

Trying it out

The next-generation trait solver is already used in stable Rust for coherence checking (that is, checking that trait implementations do not overlap), but is not yet used for general trait solving. In the nightly release of the compiler, the -Znext-solver=globally flag uses the next-generation trait solver for all trait-related type-system computations. The Rust developers have already used Crater to check that the flag does not cause compile errors for crates publicly released on crates.io, but would like to know if the flag causes problems for anyone's code prior to stabilization.

There are currently 76 open bugs related to the new trait solver, and 78 closed ones. The feature has made more progress than that suggests, however, since several of the closed bugs are rather large, and the remaining bugs are mostly internal compiler errors or performance problems that the Rust developers would like to see addressed. The new trait solver is intended to be both faster and more maintainable than the previous implementation, but whether that promise bears out remains to be seen. In either case, Rust developers may soon have the option to write more-complicated self-referential trait-based interfaces.

Comments (18 posted)

Pandoc: a workhorse for document conversion

Pandoc is a document-conversion program that can translate among a myriad of formats, including LaTeX, HTML, Office Open XML (docx), plain text, and Markdown. It is also extensible by writing Lua filters that can manipulate the document structure and perform arbitrary computations. Pandoc has appeared in various LWN articles over the years, such as my look at Typst and at the importance of free software to science in 2025, but we have missed providing an overview of the tool. The February release of Pandoc 3.9, which comes with the ability to compile the program to WebAssembly (Wasm), allowing Pandoc to run in web browsers, will likely also be of interest.

Problems solved

Writers, scholars, scientists, and many others often need to create versions of their documents in various formats. For example, a mathematician, after preparing a paper formatted with LaTeX, may want to generate an HTML version to share on the web, and later create a set of slides for a conference. Sections of the paper might be useful in a grant application, but the funding agency might require a Microsoft Word format. Creating these various incarnations would seem to require a great deal of redundant work, especially if the paper contains equations, figures, and references.

This is the problem that Pandoc was created to solve. Using Pandoc, our hypothetical mathematician can write the paper once and have it quickly and automatically converted to any of over 40 output formats. Others may simply have a document in some format and want it translated to a different format to use it in some other way. Pandoc also lurks behind other projects and online services that require document conversion, such as the popular Quarto "scientific and technical publishing system". The list of Pandoc input and output formats can be found in its README file.

A program that directly translated among N formats would have to incorporate N² translators. Instead of implementing the resulting hundreds of translation routines, Pandoc relies on a modular architecture. It ingests documents using "readers" specialized for each input format, whose job is to translate into Pandoc's internal abstract syntax tree (AST). Output is emitted by "writers" that translate the internal representation into the desired output format.

This strategy turns the N² problem into a 2N problem. It also makes it easier to enlarge Pandoc's repertoire: a contributor who would like the system to be able to read a new format need only write a Lua program to convert that format into the internal representation, after which Pandoc will be able to translate the format into any of its many outputs. Similarly, a writer module for a new format gives Pandoc the ability to convert any of the document types that it already understands into the new one. (I've simplified the situation somewhat, in that the set of document formats that Pandoc can read is not identical to the set of formats that it can write, but they have a large intersection.)

In practice, the most effective way to start using Pandoc for a new document is to write it in Pandoc's extended dialect of Markdown. This is because the readers for different formats vary in their abilities, but the Markdown reader is fully featured and complete. That variability is necessarily the case, because not every document format can be reliably translated into an AST. For example, LaTeX and Typst can embody arbitrary programs, whose output cannot be determined without running their respective compilers.

If a Markdown document is saved in a file called example.md, this command would translate it into a Typst document:

    pandoc example.md -o example.typ

The output format is inferred from the file extension. To translate it into HTML, a .html extension can be used instead. Another option is to specify the output format with the "-t" flag, for example "-t html".

Pandoc's Markdown dialect incorporates additions to the original specification that make it more suitable for expressing complex documents, while retaining the signature advantage of being pleasant to parse by eye. In addition to everything in traditional Markdown, it can handle ordered lists with letters or Roman numerals, task lists, definition lists, various styles of tables, LaTeX mathematics, footnotes, bibliographic citations, and quite a bit more.

Authors can also insert raw markup into the Markdown source, which is passed directly to the output file, bypassing Pandoc processing. Pandoc supplies syntax for raw markup that allows different fragments to be inserted in the output, depending on the format. For example, this code listing renders the name of Donald Knuth's typesetting engine in plain text, HTML, and (La)TeX; the appropriate fragment is used depending on the output format passed to Pandoc on the command line (or implied by the output file extension).

   The `TeX`{=plain}
     `T<span style="position:relative;top:0.2em">E</span>X`{=html}
     `\TeX\ `{=latex} typesetting system.  

The figure below shows all three versions, as they appear in a terminal, a web browser, and a PDF viewer, respectively. The PDF version was generated by LuaLaTeX processing the LaTeX output.

Citations

Pandoc has sophisticated support for citations and bibliographies. This feature is what makes it possible for scientists and scholars to write in Pandoc's extended Markdown rather than directly in LaTeX. Pandoc borrows the relevant syntax and mechanisms from LaTeX, using similar markup to indicate citations, the same BibTeX text-file databases of references, and the same standard Citation Style Language (CSL) bibliography style files.

As a simple example of how this works, here is a fragment of a document written in Pandoc's Markdown:

   Free software [@fsfs] is important for physics [@heisenbergBeyond] and
   other sciences.  

The bits inside the square brackets indicate references to resources defined in a BibTeX database. This a text file containing the bibliographic data for papers, books, websites, and anything else that an author might want to refer to. Here is the relevant part of the database for this document:

   @article{fsfs,
    author = {Lee Phillips},
    journal = {LWN},
    month = {June},
    title = {{T}he {I}mportance of {F}ree {S}oftware to {S}cience},
    url = {https://lwn.net/Articles/1023299/},
    year = {2025}
   }
   
   @book{heisenbergBeyond,
    address = {New York},
    author = {Werner Heisenberg},
    isbn = {06-131622-9},
    publisher = {Harper {and} Row},
    title = {{P}hysics and {B}eyond},
    url = {https://www.amazon.com/Physics-Beyond-Encounters-Conversations-Perspectives/dp/0061316229/},
    year = {1971}
   }  

The fragment can then be processed with Pandoc to create output, in any of the formats that it supports, with references and a bibliography. The command for doing so is:

   pandoc --citeproc --bibliography=refs.bib refsExample.md -o refsExample.html

In this command "--citeproc" flag tells Pandoc to use its citation machinery and "--bibliography=" points it to the BibTeX file. The input file is refsExample.md, the file extension indicating Markdown. The output will be in HTML5 because of the extension for the output file. The result will be formatted using the default bibliography style, which happens to be the Chicago Manual of Style author-date format. Different styles can be used by downloading the desired CSL file (a good source is the Zotero style repository)

The figure below shows how the result appears in my web browser, first using the default bibliography style and, below that, using a numerical superscript style. The Pandoc command line is the same in both cases; the only change was the installation of a different CSL file in the default location in the filesystem (another option is to use a "--csl" flag to point Pandoc at the desired file).

In a real project the bibliography would be set off from the main text by a header and, probably, a different font, both of which can be conveniently added by Pandoc.

We can even have plain text output with citations, for those occasions when our emails or website comments require maximum pedantry. Here's the output of the same command with the "-t plain" flag added to request plain text:

   Free software¹ is important for physics² and other sciences.
   
   1. Phillips, Lee. (2025). The Importance of Free Software to Science.
   LWN. https://lwn.net/Articles/1023299/
   
   2. Heisenberg, Werner. (1971). Physics and Beyond. Harper and Row. New
   York. ISBN 06-131622-9.

Because it is a command-line program, Pandoc can be flexibly incorporated into various workflows and used in concert with other tools. I have a keyboard shortcut defined in my editor that processes any selected text through Pandoc, using "--citeproc", and places the plain-text output in the clipboard, ready for pasting into emails or comment boxes.

Pandoc filters

A Pandoc filter is a Lua program that acts directly upon the AST. Filters can make changes to document elements and can perform arbitrary computations based on the contents of those elements. For example, a user might create a filter to number all of the paragraphs in a report, or to print a timestamp under an article's title.

There is also an older type of filter that manipulates a JSON serialization of the AST. These filters can be written in any language, but they have extra dependencies and are slower, as they require serialization and deserialization steps. The current recommendation is to write filters in Lua.

Using Lua filters involves no dependencies, as Pandoc has a Lua interpreter built in. In fact, entering "pandoc lua" in the terminal opens a standard Lua read-eval-print loop (REPL).

Here's an example of a simple filter that changes all underlined elements to Strong elements, which are rendered in most output formats as boldface:

   function Underline(elem)
       return pandoc.Strong(elem.content)
   end

To apply this filter, the program can be invoked with the argument "--lua-filter filter.lua" if filter.lua in the current directory contains the code above.

The function doesn't make much sense outside of the Pandoc context, but filters have access to an API that, somewhat magically, turns function names into routines that walk the AST and process nodes matching the name of the function. Another example is a filter that I wrote that allows me to input equations using the more concise Typst math syntax, rather than LaTeX, even when I need to produce a LaTeX document.

Filters are a powerful means to bend Pandoc to serve nearly any document-processing task, limited only by the imagination and patience of the author/programmer. Other potential applications might be to retrieve information from the Internet to insert into documents, to invoke external programs to create illustrations, or to assemble outlines.

Custom readers and writers

Although Pandoc can handle an impressive variety of document formats, it would not make sense to include every highly specialized or ad hoc markup system in existence. For more arcane applications, Pandoc provides the ability to create custom readers and custom writers. A custom reader is a Lua program that parses input text and translates it into Pandoc's AST; a writer does the reverse. To make this more convenient, Pandoc includes Lua's LPeg parsing library.

Some examples of custom readers are pandoc-fountain, which ingests screenplays written using Fountain markup, the IDML Pandoc reader that understands the markup language used in Adobe InDesign projects, and Lean.lua that can handle Lean files. Interesting custom writers include Pandoc Terminal Writer for colorful pretty-printing on the terminal, Pandoc to PreTeXt that creates markup in the PreTeXt format, which is a structural markup language for textbooks and papers, and a custom writer that emits the specialized format used in a discussion forum.

Changes for 3.9

Pandoc 3.9 was released in early February. The most prominent new feature is the ability to compile Pandoc to Wasm, allowing it to run entirely in a web browser. The project has provided an example page that allows users to do general document conversions via a web form. Pandoc in the browser leads to some interesting possibilities. For example, it should be practical to construct pages that accept user content in nearly any markup format, either in comment boxes or as wiki-style editable text, and convert it in realtime to valid HTML5 for inclusion in the page. Another possibility might be educational sites that, for instance, teach Typst or LaTeX with live feedback.

The new release brings with it dozens of small improvements and bug fixes. Most of these are technical minutiae having to do with corner cases, layout subtleties, or obscure markup formats.

There are two enhancements that may be of wider interest. One is wider support for specifying PDF standards (PDF/A, etc.), as long as LuaLaTeX is used to produce the output. The other is a significant improvement to citation handling that allows the author to reset citation history when needed, typically at the beginnings of book chapters. Standard practice is to abbreviate citations after the first mention (omitting publication details, etc.). But at the beginning of a new chapter, there may be a desire to see the full citation again.

Installations and origins

Pandoc is a free program, released under the GPLv2 (or later). It is available in the package repositories of most Linux distributions, but those versions may be behind the recent release. To get the latest release, the source, as well as binaries for Wasm, Windows, macOS, and Linux for both major architectures, are available on the web site. Those who want to use Pandoc to create PDFs must also have LaTeX, Typst, or another program that can accept one of Pandoc's output formats for conversion to PDF, installed. Pandoc will use LaTeX by default, but the user can specify another program.

The Pandoc documentation is quite good, and is all I've ever needed to support my extensive and daily use of the system.

Pandoc was created by John MacFarlane, a professor of philosophy at UC Berkeley specializing in the philosophy of language. The project is distinguished by being one of the few widely used Haskell programs. In an interview from 2023 its creator said:

I think Pandoc is, in general, written in fairly simple Haskell. I don't use too many complicated things in there. And that's partly due to the fact that I wasn't a very sophisticated Haskeller when I started, and I'm still not that much more sophisticated now.

Conclusions

Pandoc is indispensable for anyone who needs to create different kinds of written documents. With Pandoc, I can write for a publication that insists on Word documents without ever touching a GUI program, turn a set of notes into a web page, or have a book's illustrations automatically generated. Pandoc is fast and never, in my experience, fails to do exactly what it is supposed to do.

The program is actively developed and continually improved in its GitHub repository. Contributions are welcomed, and those interested in helping are not necessarily excluded by a lack of intimacy with Haskell. As MacFarlane remarked in the interview: "it's possible for people who are generally familiar with computer languages to look at some Pandoc code sometimes, even if they don't know Haskell, and figure out what might be needed".

Pandoc is most powerful as a command-line tool, where it can be incorporated into scripts and adapted to various document-processing pipelines. However, its new ability to be embedded in web pages is an interesting development that may lead to a wider variety of uses and, perhaps as a secondary effect, to an expanded interest in Haskell.

Comments (11 posted)

Rspamd version 4.0.0 released

Version 4.0.0 of the Rspamd spam-filtering system has been released. Notable new features include HTML fuzzy phishing detection, support for up to eight flags with fuzzy hashes, and more. See the changelog for more on improvements, breaking changes, and bug fixes.

Comments (none posted)

The telnyx packages on PyPI have been compromised

The SafeDep blog reports that compromised versions of the telnyx package have been found in the PyPI repository:

Two versions of telnyx (4.87.1 and 4.87.2) published to PyPI on March 27, 2026 contain malicious code injected into telnyx/_client.py. The telnyx package averages over 1 million downloads per month (~30,000/day), making this a high-impact supply chain compromise. The payload downloads a second-stage binary hidden inside WAV audio files from a remote server, then either drops a persistent executable on Windows or harvests credentials on Linux/macOS.

Comments (5 posted)

Vulnerability Research Is Cooked (sockpuppet.org)

There is a blog post on sockpuppet.org arguing that we are not prepared for the upcoming flood of high-quality, LLM-generated vulnerability reports and exploits.

Now consider the poor open source developers who, for the last 18 months, have complained about a torrent of slop vulnerability reports. I'd had mixed sympathies, but the complaints were at least empirically correct. That could change real fast. The new models find real stuff. Forget the slop; will projects be able to keep up with a steady feed of verified, reproducible, reliably-exploitable sev:hi vulnerabilities? That's what's coming down the pipe.

Everything is up in the air. The industry is sold on memory-safe software, but the shift is slow going. We've bought time with sandboxing and attack surface restriction. How well will these countermeasures hold up? A 4 layer system of sandboxes, kernels, hypervisors, and IPC schemes are, to an agent, an iterated version of the same problem. Agents will generate full-chain exploits, and they will do so soon.

Meanwhile, no defense looks flimsier now than closed source code. Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.

Comments (35 posted)

Kernel release status

The current development kernel is 7.0-rc6, released on March 29. Linus said:

Anyway, exactly because it's just "more than usual" rather than feeling *worse* than usual, I don't currently feel this merits extending the release, and I still hope that next weekend will be the last rc. But it's just a bit unnerving how this release doesn't want to calm down, so no promises.

This development cycle has brought in 13,648 non-merge commits from a record-setting 2,247 developers, 436 of whom are first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.0-rc1	2026-02-22	12468	12468
v7.0-rc2	2026-03-01	434	434
v7.0-rc3	2026-03-08	537	537
v7.0-rc4	2026-03-15	544	544
v7.0-rc5	2026-03-22	391	391
v7.0-rc6	2026-03-29	517	517

See the (subscriber-only) KSDB 7.0 page for lots more information.

Stable updates: 6.12.79 was released on March 27 with a single fix for a LoongArch build regression.

The 6.19.11, 6.18.21, 6.12.80, and 6.6.131 updates are in the review process; they are due on April 2.

Comments (none posted)

Quotes of the week

I prefer someone trying to use their own words to compose a change log and actually learn something on the way over some AI slop that reads nicer any day. Often, when you write a changelog you actually realize which corner cases you might be missing, that the design might be overly complicated, that, maybe, the reasoning or motivation is bad etc. It takes time but you actually learn something and are forced to think (crazy, right?).

The same is particularly true when it comes to writing documentation.

— David Hildenbrand

Note: setting a birth date that makes the caller appear older than 150 years is rejected with EINVAL, as the kernel does not support vampires or other immortal entities at this time. Patches to add undead process support are welcome but will require a separate Kconfig option.

— Christian Brauner

Comments (2 posted)

The forge is our new home (Fedora Community Blog)

Tomáš Hrčka has announced that the Forgejo-based Fedora Forge is now a fully operational collaborative-development platform; it is ready for use by the larger Fedora community, which means the homegrown Pagure platform's days are numbered:

While pagure.io has been a vital part of our community for many years, the time has come to retire our homegrown forge and transition to this powerful new tool.

The final cutover is planned for Flock to Fedora 2026. We strongly encourage teams to migrate their projects well before the conference to ensure a smooth transition. The pagure.io migration is only the first step in a broader infrastructure modernization effort. By the 2027 Fedora 46 release, we plan to retire all remaining Pagure instances across the project, including the package source repositories on src.fedoraproject.org. Getting familiar with Fedora Forge now will help ensure your team is ready as the rest of the Fedora ecosystem transitions.

There is a migration guide for Fedora community members that own projects hosted on Pagure and need to move to the new forge.

Comments (7 posted)

SystemRescue 13.00 released

SystemRescue 13.00 has been released. The SystemRescue distribution is a live boot system-rescue toolkit, based on Arch Linux, for repairing systems in the event of a crash. This release includes the 6.18.20 LTS kernel, updates bcachefs tools and kernel module to 1.37.3, and many upgraded packages. See the step-by-step guide for instructions on performing common operations such as recovering files, creating disk clones, and resetting lost passwords.

Comments (3 posted)

Distributions quote of the week

The reason we advise against deleting and recreating tags is simply that we think the existence of multiple different signed tags of the same name, referring to different contents, is confusing and wrong, for both computers and humans.

It's all very well deleting and replacing the tag on Salsa, but anyone who fetches in between will get the old tag. After that, their git won't usually update it to the new one. So some unknown set of users and co-developers (which I guess you are hoping is empty) has wrong information about what your upload was. Wrong information with your PGP signature on it!

IMO such a mess is not worth it, just to make things *look* neat.

But if you want to do things that way we're not stopping you. You and your collaborators and users get to keep all of the pieces.

— Ian Jackson

Comments (none posted)

Servo 0.0.6 released

Version 0.0.6 of the Rust-based Servo web browser rendering engine has been released. This release boasts a long list of new features, performance enhancements, improvements, and bug fixes. Some of the notable changes include layout performance improvements, a servo:config page for setting any preference, and developer tools enhancements.

Comments (none posted)

Development quote of the week

"By Wednesday morning, Anthropic representatives had used a copyright takedown request to force the removal of more than 8,000 copies and adaptations of the raw Claude Code instructions—known as source code—that developers had shared on programming platform GitHub."

Because if there's one thing GenAI companies absolutely don't take lightly, it's copyright.

— Jens Ohlig commenting on a quote from a Wall Street Journal article.

Comments (8 posted)

Turbulence at The Document Foundation

Michael Meeks has posted an angry missive about changes at The Document Foundation. What has really happened is not entirely clear, but it seems to involve, at a minimum, the forced removal of all Collabora staff from the foundation. There has been a set of "thank you" notes to the people involved posted in the foundation's forums. The Document Foundation's decision to restart LibreOffice Online almost certainly plays into this as well.

Details are fuzzy at best; we will be working at providing a clearer picture, but that will take some time.

Comments (22 posted)

CFP Deadlines: April 2, 2026 to June 1, 2026

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

Deadline	Event Dates	Event	Location
April 7	August 8 August 9	UbuCon Asia 2026 @ COSCUP	Taipei, Taiwan
April 15	May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
April 20	July 13 July 19	DebCamp 26	Santa Fe, Argentina
April 23	October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
April 30	September 29 September 30	devopsdays Berlin 2026	Berlin, Germany
May 25	July 20 July 25	DebConf 26	Santa Fe, Argentina
May 31	October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany

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

Events: April 2, 2026 to June 1, 2026

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

Date(s)	Event	Location
April 10 April 11	Grazer Linuxtage	Graz, Austria
April 20 April 21	SambaXP	Göttingen, Germany
April 23	OpenSUSE Open Developers Summit	Prague, Czech Republic
April 25 April 26	Sesja Linuksowa (Linux Session)	Wrocław, Poland
April 27 April 28	foss-north	Gothenburg, Sweden
April 28 April 29	stackconf 2026	Munich, Germany
April 29 May 1	Linaro Connect Madrid 2026	Madrid, Spain
May 2	22nd Linux Infotag Augsburg	Augsburg, Germany
May 4 May 6	Linux Storage, Filesystem, Memory Management and BPF Summit	Zagreb, Croatia
May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
May 15 May 17	PyCon US	Long Beach, California, US
May 16 May 17	Lomiri Tech Meeting	Tilburg, The Netherlands
May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
May 18 May 23	RustWeek 2026	Utrecht, Netherlands
May 21 May 22	Linux Security Summit North America	Minneapolis, Minnesota, US
May 23 May 24	Curl up	Prague, Czechia
May 26	Media Summit	Nice, France
May 27 May 28	Embedded Recipes	Nice, France
May 29	Yocto Project Developer Day	Nice, France
May 29	libcamera workshop	Nice, France
May 30 May 31	Journées du Logiciel Libre 2026	Lyon, France

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

Alert summary March 26, 2026 to April 1, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:5513	8	389-ds:1.4	2026-03-26
AlmaLinux	ALSA-2026:5931	10	firefox	2026-03-30
AlmaLinux	ALSA-2026:5932	8	firefox	2026-03-30
AlmaLinux	ALSA-2026:5930	9	firefox	2026-03-30
AlmaLinux	ALSA-2026:5939	10	freerdp	2026-03-27
AlmaLinux	ALSA-2026:6004	9	freerdp	2026-04-01
AlmaLinux	ALSA-2026:5585	8	gnutls	2026-03-26
AlmaLinux	ALSA-2026:5941	10	golang	2026-03-27
AlmaLinux	ALSA-2026:5942	9	golang	2026-03-27
AlmaLinux	ALSA-2026:6037	8	kernel	2026-03-30
AlmaLinux	ALSA-2026:6036	8	kernel-rt	2026-03-30
AlmaLinux	ALSA-2026:6266	9	libxslt	2026-04-01
AlmaLinux	ALSA-2026:5580	8	mysql:8.0	2026-03-26
AlmaLinux	ALSA-2026:5640	9	mysql:8.4	2026-03-26
AlmaLinux	ALSA-2026:5913	10	ncurses	2026-03-27
AlmaLinux	ALSA-2026:5599	9	nginx	2026-03-26
AlmaLinux	ALSA-2026:5581	8	nginx:1.24	2026-03-26
AlmaLinux	ALSA-2026:5587	8	opencryptoki	2026-03-26
AlmaLinux	ALSA-2026:5603	9	opencryptoki	2026-03-26
AlmaLinux	ALSA-2026:5588	8	python3	2026-03-26
AlmaLinux	ALSA-2026:6281	8	python3.11	2026-04-01
AlmaLinux	ALSA-2026:6283	8	python3.12	2026-04-01
AlmaLinux	ALSA-2026:6285	9	python3.12	2026-04-01
AlmaLinux	ALSA-2026:5602	9	vim	2026-03-26
AlmaLinux	ALSA-2026:5578	8	virt:rhel and virt-devel:rhel	2026-03-26
Debian	DLA-4515-1	LTS	asterisk	2026-03-30
Debian	DLA-4509-1	LTS	awstats	2026-03-25
Debian	DSA-6181-1	stable	bind9	2026-03-27
Debian	DLA-4510-1	LTS	firefox-esr	2026-03-26
Debian	DSA-6178-1	stable	firefox-esr	2026-03-25
Debian	DLA-4514-1	LTS	gst-plugins-base1.0	2026-03-29
Debian	DLA-4516-1	LTS	gst-plugins-ugly1.0	2026-03-30
Debian	DLA-4513-1	LTS	gvfs	2026-03-28
Debian	DSA-6184-1	stable	incus	2026-03-29
Debian	DSA-6189-1	stable	libpng1.6	2026-03-31
Debian	DSA-6182-1	stable	libxml-parser-perl	2026-03-28
Debian	DSA-6188-1	stable	lxd	2026-03-31
Debian	DLA-4519-1	LTS	netty	2026-03-31
Debian	DSA-6183-1	stable	nodejs	2026-03-29
Debian	DLA-4508-1	LTS	nss	2026-03-25
Debian	DSA-6186-1	stable	php-phpseclib	2026-03-29
Debian	DSA-6187-1	stable	php-phpseclib3	2026-03-29
Debian	DLA-4518-1	LTS	phpseclib	2026-03-30
Debian	DSA-6185-1	stable	phpseclib	2026-03-29
Debian	DLA-4520-1	LTS	python-tornado	2026-04-01
Debian	DLA-4517-1	LTS	roundcube	2026-03-30
Debian	DSA-6180-1	stable	ruby-rack	2026-03-26
Debian	DLA-4512-1	LTS	strongswan	2026-03-27
Debian	DLA-4511-1	LTS	thunderbird	2026-03-26
Debian	DSA-6179-1	stable	thunderbird	2026-03-26
Fedora	FEDORA-2026-1fc0d39acd	F42	bcftools	2026-03-28
Fedora	FEDORA-2026-3b06345bf2	F43	bcftools	2026-03-28
Fedora	FEDORA-2026-cb321bebb5	F44	bcftools	2026-03-28
Fedora	FEDORA-2026-b2ec0d8a47	F43	bind	2026-03-29
Fedora	FEDORA-2026-19d899e92d	F44	bind	2026-03-31
Fedora	FEDORA-2026-b2ec0d8a47	F43	bind-dyndb-ldap	2026-03-29
Fedora	FEDORA-2026-19d899e92d	F44	bind-dyndb-ldap	2026-03-31
Fedora	FEDORA-2026-cc466cfb57	F42	chromium	2026-03-28
Fedora	FEDORA-2026-ad5b2b6b68	F43	chromium	2026-03-29
Fedora	FEDORA-2026-4d42fffb2b	F44	chromium	2026-03-26
Fedora	FEDORA-2026-1269948465	F43	chunkah	2026-04-01
Fedora	FEDORA-2026-04a531cece	F42	cpp-httplib	2026-04-01
Fedora	FEDORA-2026-e76feaf213	F43	cpp-httplib	2026-04-01
Fedora	FEDORA-2026-03599f0b32	F44	cpp-httplib	2026-03-31
Fedora	FEDORA-2026-48e73ed6b8	F42	dotnet10.0	2026-03-28
Fedora	FEDORA-2026-956fc306c4	F44	dotnet10.0	2026-03-26
Fedora	FEDORA-2026-66c97240f2	F42	dotnet8.0	2026-03-28
Fedora	FEDORA-2026-f84afd42df	F43	dotnet8.0	2026-03-31
Fedora	FEDORA-2026-702a03ac4d	F44	dotnet8.0	2026-03-26
Fedora	FEDORA-2026-8ae04c01e3	F42	dotnet9.0	2026-03-28
Fedora	FEDORA-2026-22e517fe60	F43	dotnet9.0	2026-03-31
Fedora	FEDORA-2026-624e30e8a7	F44	dotnet9.0	2026-03-26
Fedora	FEDORA-2026-49237e1ced	F42	firefox	2026-03-31
Fedora	FEDORA-2026-a026a1b0c5	F42	firefox	2026-04-01
Fedora	FEDORA-2026-3dbd8c4b89	F42	fontforge	2026-03-27
Fedora	FEDORA-2026-4f7402837e	F43	fontforge	2026-03-27
Fedora	FEDORA-2026-f6fe509803	F43	freerdp	2026-04-01
Fedora	FEDORA-2026-2c1ab5b23b	F44	freerdp	2026-03-26
Fedora	FEDORA-2026-36ea367760	F44	freerdp	2026-03-31
Fedora	FEDORA-2026-758ce76ef6	F44	giflib	2026-03-28
Fedora	FEDORA-2026-e77ad9d792	F43	gst-devtools	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gst-editing-services	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-doc	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-plugin-libav	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-plugins-bad-free	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-plugins-base	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-plugins-good	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-plugins-ugly-free	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-rtsp-server	2026-04-01
Fedora	FEDORA-2026-e77ad9d792	F43	gstreamer1-vaapi	2026-04-01
Fedora	FEDORA-2026-c3c02ffe75	F43	headscale	2026-03-27
Fedora	FEDORA-2026-76033f35ea	F44	headscale	2026-03-27
Fedora	FEDORA-2026-1fc0d39acd	F42	htslib	2026-03-28
Fedora	FEDORA-2026-3b06345bf2	F43	htslib	2026-03-28
Fedora	FEDORA-2026-cb321bebb5	F44	htslib	2026-03-28
Fedora	FEDORA-2026-62cea4650e	F42	insight	2026-04-01
Fedora	FEDORA-2026-0b2e9c67ef	F43	insight	2026-04-01
Fedora	FEDORA-2026-d79ba951dd	F44	insight	2026-03-31
Fedora	FEDORA-2026-9d5b9f45ec	F43	kryoptic	2026-03-27
Fedora	FEDORA-2026-f9d2152328	F43	libopenmpt	2026-03-27
Fedora	FEDORA-2026-b58c5b3cc0	F44	libopenmpt	2026-03-27
Fedora	FEDORA-2026-55dabf3975	F44	libsoup3	2026-03-30
Fedora	FEDORA-2026-48a302496d	F44	libtasn1	2026-03-30
Fedora	FEDORA-2026-23bb71ea52	F42	maturin	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	maturin	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	maturin	2026-03-28
Fedora	FEDORA-2026-1cbd107c34	F42	mingw-expat	2026-03-30
Fedora	FEDORA-2026-e70c1919fe	F43	mingw-expat	2026-03-30
Fedora	FEDORA-2026-cf814a1a06	F44	mingw-expat	2026-03-30
Fedora	FEDORA-2026-0e9d55a05c	F44	mingw-freetype	2026-03-30
Fedora	FEDORA-2026-c5273647fa	F42	mongo-c-driver	2026-03-28
Fedora	FEDORA-2026-cc129df978	F43	mongo-c-driver	2026-03-28
Fedora	FEDORA-2026-508009213f	F44	mongo-c-driver	2026-03-28
Fedora	FEDORA-2026-2e5626418f	F42	musescore	2026-03-31
Fedora	FEDORA-2026-c571483404	F43	musescore	2026-03-31
Fedora	FEDORA-2026-49237e1ced	F42	nss	2026-03-31
Fedora	FEDORA-2026-367d9a0b61	F44	nss	2026-03-31
Fedora	FEDORA-2026-2dc4882154	F42	ntpd-rs	2026-03-31
Fedora	FEDORA-2026-cbe2315bad	F43	ntpd-rs	2026-03-31
Fedora	FEDORA-2026-eb0777262e	F44	ntpd-rs	2026-03-31
Fedora	FEDORA-2026-b7182d65b7	F43	perl-XML-Parser	2026-03-28
Fedora	FEDORA-2026-dcb80f8e23	F44	perl-XML-Parser	2026-03-28
Fedora	FEDORA-2026-d226775800	F42	perl-YAML-Syck	2026-03-31
Fedora	FEDORA-2026-3572f7e01c	F43	perl-YAML-Syck	2026-03-31
Fedora	FEDORA-2026-a8d89d8ae2	F44	perl-YAML-Syck	2026-03-31
Fedora	FEDORA-2026-bfeb46516b	F42	php-phpseclib	2026-03-28
Fedora	FEDORA-2026-d1feefa819	F43	php-phpseclib	2026-03-28
Fedora	FEDORA-2026-65fdd15133	F42	php-phpseclib3	2026-03-30
Fedora	FEDORA-2026-b7d9416ec4	F43	php-phpseclib3	2026-03-30
Fedora	FEDORA-2026-054c0e22d1	F44	polkit	2026-03-31
Fedora	FEDORA-2026-9d5b9f45ec	F43	pyOpenSSL	2026-03-27
Fedora	FEDORA-2026-5697f4e025	F44	pyOpenSSL	2026-03-31
Fedora	FEDORA-2026-6c4a7cd1b1	F43	pypy	2026-03-29
Fedora	FEDORA-2026-496bf1e0dd	F44	pypy	2026-03-29
Fedora	FEDORA-2026-98502d7938	F43	pypy3.10	2026-03-29
Fedora	FEDORA-2026-55dd4da86b	F44	pypy3.10	2026-03-29
Fedora	FEDORA-2026-85a7950dd4	F43	pypy3.11	2026-03-30
Fedora	FEDORA-2026-8199b7452a	F44	pypy3.11	2026-03-30
Fedora	FEDORA-2026-9d5b9f45ec	F43	python-cryptography	2026-03-27
Fedora	FEDORA-2026-6c010af7be	F43	python-cryptography	2026-03-30
Fedora	FEDORA-2026-2423902e8b	F44	python-cryptography	2026-03-30
Fedora	FEDORA-2026-23bb71ea52	F42	python-fastar	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	python-fastar	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	python-fastar	2026-03-28
Fedora	FEDORA-2026-e77ad9d792	F43	python-gstreamer1	2026-04-01
Fedora	FEDORA-2026-516db080b7	F43	python-ply	2026-03-29
Fedora	FEDORA-2026-c081ac890b	F44	python-ply	2026-03-29
Fedora	FEDORA-2026-1594a9755b	F44	python-pycparser	2026-03-30
Fedora	FEDORA-2026-23bb71ea52	F42	python-uv-build	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	python-uv-build	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	python-uv-build	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	python-uv-build	2026-03-28
Fedora	FEDORA-2026-a0b1d4b9fa	F42	python3.11	2026-03-29
Fedora	FEDORA-2026-5dd28d8058	F43	python3.11	2026-03-29
Fedora	FEDORA-2026-5e63b7a761	F44	python3.11	2026-03-29
Fedora	FEDORA-2026-304f76c660	F43	python3.12	2026-03-28
Fedora	FEDORA-2026-9c8d7e5c9a	F44	python3.12	2026-03-31
Fedora	FEDORA-2026-f373d5f528	F43	python3.13	2026-03-29
Fedora	FEDORA-2026-742bf8c12d	F44	python3.13	2026-03-29
Fedora	FEDORA-2026-3d7ea476e1	F44	python3.14	2026-03-31
Fedora	FEDORA-2026-156169f944	F42	python3.6	2026-03-29
Fedora	FEDORA-2026-1a816eeca2	F43	python3.6	2026-03-29
Fedora	FEDORA-2026-b79ae5877b	F44	python3.6	2026-03-29
Fedora	FEDORA-2026-c283cce7fd	F42	roundcubemail	2026-03-28
Fedora	FEDORA-2026-2decd38070	F43	roundcubemail	2026-03-28
Fedora	FEDORA-2026-9b0f520716	F44	roundcubemail	2026-03-28
Fedora	FEDORA-2026-8c07fcde49	F43	rubygem-json	2026-03-27
Fedora	FEDORA-2026-3a7663d43d	F44	rubygem-json	2026-03-28
Fedora	FEDORA-2026-99de392ccb	F43	rust	2026-04-01
Fedora	FEDORA-2026-30b1c7e18a	F44	rust	2026-03-31
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-ambient-id	2026-03-28
Fedora	FEDORA-2026-9d5b9f45ec	F43	rust-asn1	2026-03-27
Fedora	FEDORA-2026-9d5b9f45ec	F43	rust-asn1_derive	2026-03-27
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-astral-reqwest-middleware	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-astral-reqwest-retry	2026-03-28
Fedora	FEDORA-2026-23bb71ea52	F42	rust-astral-tokio-tar	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	rust-astral-tokio-tar	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	rust-astral-tokio-tar	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-astral_async_http_range_reader	2026-03-28
Fedora	FEDORA-2026-82783c3c1d	F42	rust-cargo-c	2026-03-29
Fedora	FEDORA-2026-7624cdcfb6	F43	rust-cargo-c	2026-03-29
Fedora	FEDORA-2026-ad73d6fafe	F44	rust-cargo-c	2026-03-29
Fedora	FEDORA-2026-433d51e09b	F42	rust-cargo-rpmstatus	2026-04-01
Fedora	FEDORA-2026-e5b9665269	F43	rust-cargo-rpmstatus	2026-03-31
Fedora	FEDORA-2026-d7cc8fd693	F44	rust-cargo-rpmstatus	2026-03-31
Fedora	FEDORA-2026-1a04e4e1ed	F42	rust-cargo-vendor-filterer	2026-04-01
Fedora	FEDORA-2026-f0710d7a56	F43	rust-cargo-vendor-filterer	2026-04-01
Fedora	FEDORA-2026-8deecdc6c6	F44	rust-cargo-vendor-filterer	2026-03-31
Fedora	FEDORA-2026-9d5b9f45ec	F43	rust-cryptoki	2026-03-27
Fedora	FEDORA-2026-9d5b9f45ec	F43	rust-cryptoki-sys	2026-03-27
Fedora	FEDORA-2026-1c54435571	F42	rust-ingredients	2026-03-29
Fedora	FEDORA-2026-d0a08cfd21	F43	rust-ingredients	2026-03-29
Fedora	FEDORA-2026-f5938ebad0	F44	rust-ingredients	2026-03-29
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-native-tls	2026-03-28
Fedora	FEDORA-2026-23bb71ea52	F42	rust-nix	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	rust-nix	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	rust-nix	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-openssl-probe	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-openssl-probe0.1	2026-03-28
Fedora	FEDORA-2026-8f1d7b6821	F42	rust-pty-process	2026-03-29
Fedora	FEDORA-2026-936a74ccc0	F43	rust-pty-process	2026-03-29
Fedora	FEDORA-2026-29e1155702	F44	rust-pty-process	2026-03-29
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-aliyun-oss	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-aws-v4	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-azure-storage	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-command-execute-tokio	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-core	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-file-read-tokio	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-google	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-http-send-reqwest	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-huaweicloud-obs	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-reqsign-tencent-cos	2026-03-28
Fedora	FEDORA-2026-dd42661781	F42	rust-resctl-bench	2026-04-01
Fedora	FEDORA-2026-d7252cbfc9	F43	rust-resctl-bench	2026-04-01
Fedora	FEDORA-2026-12baf239f8	F44	rust-resctl-bench	2026-03-31
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-rustls-native-certs	2026-03-28
Fedora	FEDORA-2026-27e6e0b664	F44	rust-scx_layered	2026-03-31
Fedora	FEDORA-2026-4bf6df19ae	F44	rust-scx_rustland	2026-03-31
Fedora	FEDORA-2026-2d77e9f2c0	F44	rust-scx_rusty	2026-03-31
Fedora	FEDORA-2026-8f1d7b6821	F42	rust-sequoia-chameleon-gnupg	2026-03-29
Fedora	FEDORA-2026-936a74ccc0	F43	rust-sequoia-chameleon-gnupg	2026-03-29
Fedora	FEDORA-2026-29e1155702	F44	rust-sequoia-chameleon-gnupg	2026-03-29
Fedora	FEDORA-2026-23bb71ea52	F42	rust-tar	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	rust-tar	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	rust-tar	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	rust-webpki-root-certs	2026-03-28
Fedora	FEDORA-2026-9d5b9f45ec	F43	rust-wycheproof	2026-03-27
Fedora	FEDORA-2026-609bc373aa	F42	rustup	2026-03-29
Fedora	FEDORA-2026-9defa0fb00	F43	rustup	2026-03-29
Fedora	FEDORA-2026-89d4b6644b	F44	rustup	2026-03-29
Fedora	FEDORA-2026-1fc0d39acd	F42	samtools	2026-03-28
Fedora	FEDORA-2026-3b06345bf2	F43	samtools	2026-03-28
Fedora	FEDORA-2026-cb321bebb5	F44	samtools	2026-03-28
Fedora	FEDORA-2026-9e26f48b50	F42	stgit	2026-03-31
Fedora	FEDORA-2026-d6b7d7e177	F43	stgit	2026-03-31
Fedora	FEDORA-2026-25285d56e4	F44	stgit	2026-03-31
Fedora	FEDORA-2026-03583f302f	F43	suricata	2026-03-28
Fedora	FEDORA-2026-45a7e37b8a	F44	suricata	2026-03-28
Fedora	FEDORA-2026-23bb71ea52	F42	uv	2026-03-29
Fedora	FEDORA-2026-d18cf572b8	F43	uv	2026-03-28
Fedora	FEDORA-2026-b8b59dcf44	F44	uv	2026-03-28
Fedora	FEDORA-2026-e22a7dbf2d	F44	uv	2026-03-28
Fedora	FEDORA-2026-a05ac070cd	F43	vim	2026-03-27
Fedora	FEDORA-2026-a218db2573	F44	vim	2026-03-30
Fedora	FEDORA-2026-ff768f8e37	F42	vtk	2026-03-27
Fedora	FEDORA-2026-55f82da186	F43	vtk	2026-03-27
Fedora	FEDORA-2026-f00460a7d9	F44	webkitgtk	2026-03-31
Fedora	FEDORA-2026-71154797a5	F44	wireshark	2026-03-26
Fedora	FEDORA-2026-f04da48123	F42	xen	2026-04-01
Fedora	FEDORA-2026-f884fd0313	F44	xen	2026-03-31
Mageia	MGASA-2026-0069	9	cmake	2026-03-27
Mageia	MGASA-2026-0078	9	freeipmi	2026-04-01
Mageia	MGASA-2026-0067	9	graphicsmagick	2026-03-25
Mageia	MGASA-2026-0070	9	libpng	2026-03-28
Mageia	MGASA-2026-0071	9	nodejs	2026-03-28
Mageia	MGASA-2026-0074	9	python-openssl	2026-04-01
Mageia	MGASA-2026-0079	9	python-ply	2026-04-01
Mageia	MGASA-2026-0073	9	python-ujson	2026-03-29
Mageia	MGASA-2026-0075	9	ruby-rack	2026-04-01
Mageia	MGASA-2026-0072	9	strongswan	2026-03-29
Mageia	MGASA-2026-0077	9	vim	2026-04-01
Mageia	MGASA-2026-0068	9	xen	2026-03-25
Mageia	MGASA-2026-0076	9	zlib	2026-04-01
Oracle	ELSA-2026-5931	OL10	firefox	2026-03-31
Oracle	ELSA-2026-5932	OL8	firefox	2026-03-31
Oracle	ELSA-2026-5930	OL9	firefox	2026-03-31
Oracle	ELSA-2026-5939	OL10	freerdp	2026-03-26
Oracle	ELSA-2026-4471	OL7	freerdp	2026-03-31
Oracle	ELSA-2026-6005	OL8	freerdp	2026-03-31
Oracle	ELSA-2026-6004	OL9	freerdp	2026-03-31
Oracle	ELSA-2026-5941	OL10	golang	2026-03-26
Oracle	ELSA-2026-5942	OL9	golang	2026-03-26
Oracle	ELSA-2026-6053	OL10	kernel	2026-03-31
Oracle	ELSA-2026-50171	OL8	kernel	2026-03-31
Oracle	ELSA-2026-50171	OL9	kernel	2026-03-31
Oracle	ELSA-2026-50171	OL9	kernel	2026-03-31
Oracle	ELSA-2026-50170	OL9	kernel	2026-03-31
Oracle	ELSA-2026-4756	OL7	libpng	2026-03-31
Oracle	ELSA-2026-5580	OL8	mysql:8.0	2026-03-26
Oracle	ELSA-2026-5640	OL9	mysql:8.4	2026-03-25
Oracle	ELSA-2026-5913	OL10	ncurses	2026-03-26
Oracle	ELSA-2026-5599	OL9	nginx	2026-03-25
Oracle	ELSA-2026-6188	OL9	thunderbird	2026-03-31
Oracle	ELSA-2026-50170		uek-kernel	2026-03-31
Oracle	ELSA-2026-5578	OL8	virt:ol and virt-devel:ol	2026-03-31
Red Hat	RHSA-2026:5941-01	EL10	golang	2026-04-01
Red Hat	RHSA-2026:5943-01	EL10.0	golang	2026-04-01
Red Hat	RHSA-2026:5942-01	EL9	golang	2026-04-01
Red Hat	RHSA-2026:5944-01	EL9.6	golang	2026-04-01
Red Hat	RHSA-2026:5852-01	EL10.0	osbuild-composer	2026-03-27
Red Hat	RHSA-2026:5853-01	EL8.6	osbuild-composer	2026-03-27
Red Hat	RHSA-2026:5167-01	EL10.0	podman	2026-03-26
Red Hat	RHSA-2026:5222-01	EL9.4	podman	2026-03-26
Red Hat	RHSA-2026:5216-01	EL8.2	python3	2026-03-30
Red Hat	RHSA-2026:5219-01	EL9.0	python3.9	2026-03-30
Slackware	SSA:2026-084-01		bind	2026-03-25
Slackware	SSA:2026-085-02		libpng	2026-03-26
Slackware	SSA:2026-084-02		tigervnc	2026-03-25
Slackware	SSA:2026-085-01		tigervnc	2026-03-26
SUSE	openSUSE-SU-2026:20415-1	oS16.0	389-ds	2026-03-28
SUSE	openSUSE-SU-2026:10446-1	TW	ImageMagick	2026-03-30
SUSE	SUSE-SU-2026:1124-1	SLE15	LibVNCServer	2026-03-27
SUSE	SUSE-SU-2026:1008-1	SLE15 SLE-m5.0 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3 oS15.4 oS15.5 oS15.6	Prometheus	2026-03-25
SUSE	openSUSE-SU-2026:10420-1	TW	amazon-cloudwatch-agent	2026-03-28
SUSE	openSUSE-SU-2026:10407-1	TW	azure-storage-azcopy	2026-03-25
SUSE	openSUSE-SU-2026:10448-1	TW	bind	2026-03-31
SUSE	SUSE-SU-2026:20868-1	SLE-m6.0	capstone	2026-03-27
SUSE	openSUSE-SU-2026:20422-1	oS16.0	chromium	2026-03-28
SUSE	openSUSE-SU-2026:0097-1	osB15	chromium	2026-03-26
SUSE	openSUSE-SU-2026:0096-1	osB15	chromium	2026-03-26
SUSE	SUSE-SU-2026:1105-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	containerd	2026-03-27
SUSE	SUSE-SU-2026:1098-1	SLE15 oS15.4 oS15.6	cosign	2026-03-27
SUSE	openSUSE-SU-2026:20404-1	oS16.0	curl	2026-03-28
SUSE	SUSE-SU-2026:20871-1	SLE-m6.0	docker-compose	2026-03-27
SUSE	SUSE-SU-2026:1118-1	SLE12	docker-stable	2026-03-27
SUSE	openSUSE-SU-2026:10442-1	TW	dovecot24	2026-03-30
SUSE	openSUSE-SU-2026:20410-1	oS16.0	exiv2	2026-03-28
SUSE	SUSE-SU-2026:1137-1	SLE-m5.2	expat	2026-03-30
SUSE	SUSE-SU-2026:1159-1	SLE12	expat	2026-03-31
SUSE	SUSE-SU-2026:20935-1		fetchmail	2026-04-01
SUSE	SUSE-SU-2026:20932-1		ffmpeg-7	2026-04-01
SUSE	SUSE-SU-2026:1127-1	SLE12	firefox	2026-03-27
SUSE	SUSE-SU-2026:1126-1	SLE15 oS15.6	firefox	2026-03-27
SUSE	openSUSE-SU-2026:10413-1	TW	firefox-esr	2026-03-25
SUSE	openSUSE-SU-2026:10436-1	TW	freeipmi	2026-03-29
SUSE	SUSE-SU-2026:1129-1	SLE15 oS15.4	freerdp	2026-03-27
SUSE	SUSE-SU-2026:1160-1	SLE15 oS15.6	freerdp	2026-03-31
SUSE	SUSE-SU-2026:1057-1	SLE12	frr	2026-03-26
SUSE	SUSE-SU-2026:1063-1	SLE15 oS15.5 oS15.6	frr	2026-03-26
SUSE	SUSE-SU-2026:1005-1	SLE12	giflib	2026-03-25
SUSE	openSUSE-SU-2026:20428-1	oS16.0	gimp	2026-03-28
SUSE	openSUSE-SU-2026:10415-1	TW	glances-common	2026-03-25
SUSE	openSUSE-SU-2026:0099-1	osB15	glusterfs	2026-03-27
SUSE	openSUSE-SU-2026:0104-1	osB15	glusterfs	2026-03-27
SUSE	SUSE-SU-2026:1042-1	oS15.6	govulncheck-vulndb	2026-03-25
SUSE	SUSE-SU-2026:1135-1	oS15.6	govulncheck-vulndb	2026-03-30
SUSE	SUSE-SU-2026:1037-1	SLE15 oS15.6	grafana	2026-03-25
SUSE	openSUSE-SU-2026:10449-1	TW	gsl	2026-03-31
SUSE	openSUSE-SU-2026:20402-1	oS16.0	gstreamer-plugins-ugly	2026-03-28
SUSE	openSUSE-SU-2026:10450-1	TW	incus	2026-03-31
SUSE	openSUSE-SU-2026:10424-1	TW	jupyter-bqplot-jupyterlab	2026-03-28
SUSE	openSUSE-SU-2026:10429-1	TW	jupyter-jupyterlab-templates	2026-03-29
SUSE	openSUSE-SU-2026:10427-1	TW	jupyter-matplotlib	2026-03-29
SUSE	openSUSE-SU-2026:10440-1	TW	jupyter-nbclassic	2026-03-30
SUSE	SUSE-SU-2026:1091-1	SLE15 oS15.6	kea	2026-03-27
SUSE	openSUSE-SU-2026:10421-1	TW	kea	2026-03-28
SUSE	SUSE-SU-2026:20872-1	SLE-m6.0	kernel	2026-03-27
SUSE	SUSE-SU-2026:20845-1	SLE-m6.0	kernel	2026-03-27
SUSE	SUSE-SU-2026:20876-1	SLE-m6.0 SLE-m6.1	kernel	2026-03-30
SUSE	SUSE-SU-2026:1130-1	SLE11	kernel	2026-03-27
SUSE	SUSE-SU-2026:1078-1	SLE12	kernel	2026-03-26
SUSE	SUSE-SU-2026:1081-1	SLE15	kernel	2026-03-26
SUSE	SUSE-SU-2026:1131-1	SLE15 SLE-m5.3 SLE-m5.4	kernel	2026-03-30
SUSE	SUSE-SU-2026:1003-1	SLE15 SLE-m5.5 oS15.5	kernel	2026-03-25
SUSE	SUSE-SU-2026:1077-1	SLE15 SLE-m5.5 oS15.5	kernel	2026-03-26
SUSE	SUSE-SU-2026:1041-1	SLE15 oS15.6	kernel	2026-03-25
SUSE	SUSE-SU-2026:20931-1	SLE16	kernel	2026-04-01
SUSE	SUSE-SU-2026:20873-1	SLE16 SLE-m6.2	kernel	2026-03-27
SUSE	SUSE-SU-2026:20838-1	SLE16 SLE-m6.2	kernel	2026-03-27
SUSE	openSUSE-SU-2026:10452-1	TW	libjavamapscript	2026-03-31
SUSE	SUSE-SU-2026:1154-1	SLE15	libjxl	2026-03-31
SUSE	openSUSE-SU-2026:0106-1	osB15	libjxl	2026-03-30
SUSE	openSUSE-SU-2026:0107-1	osB15	libjxl	2026-03-30
SUSE	openSUSE-SU-2026:10451-1	TW	libpng16-16	2026-03-31
SUSE	openSUSE-SU-2026:20378-1	oS16.0	libpng16	2026-03-25
SUSE	openSUSE-SU-2026:10453-1	TW	libpolkit-agent-1-0-127	2026-03-31
SUSE	openSUSE-SU-2026:20399-1	oS16.0	libsodium	2026-03-28
SUSE	SUSE-SU-2026:1004-1	SLE12	libsoup	2026-03-25
SUSE	openSUSE-SU-2026:10443-1	TW	libsuricata8_0_4	2026-03-30
SUSE	openSUSE-SU-2026:10422-1	TW	libtpms-devel	2026-03-28
SUSE	openSUSE-SU-2026:20394-1	oS16.0	mumble	2026-03-25
SUSE	SUSE-SU-2026:0227-2	SLE-m5.5	net-snmp	2026-03-31
SUSE	openSUSE-SU-2026:20383-1	oS16.0	net-snmp	2026-03-25
SUSE	SUSE-SU-2026:20940-1		net-tools	2026-04-01
SUSE	SUSE-SU-2026:20870-1	SLE-m6.0	nghttp2	2026-03-27
SUSE	SUSE-SU-2026:20833-1	SLE-m6.2	nghttp2	2026-03-27
SUSE	SUSE-SU-2026:1056-1	SLE12	nghttp2	2026-03-26
SUSE	SUSE-SU-2026:1074-1	SLE15	nghttp2	2026-03-26
SUSE	openSUSE-SU-2026:10423-1	TW	nginx	2026-03-28
SUSE	openSUSE-SU-2026:0109-1	oS42.3 osB15	obs-service-recompress, obs-service-tar_scm	2026-03-30
SUSE	openSUSE-SU-2026:0108-1	osB15	obs-service-set_version	2026-03-30
SUSE	openSUSE-SU-2026:10438-1	TW	openbao	2026-03-30
SUSE	SUSE-SU-2026:20936-1		openexr	2026-04-01
SUSE	openSUSE-SU-2026:10414-1	TW	perl-Crypt-URandom	2026-03-25
SUSE	openSUSE-SU-2026:0110-1	osB15	perl-Crypt-URandom	2026-03-31
SUSE	SUSE-SU-2026:1152-1	SLE12	perl-XML-Parser	2026-03-31
SUSE	SUSE-SU-2026:1153-1	SLE15 oS15.6	perl-XML-Parser	2026-03-31
SUSE	SUSE-SU-2026:1068-1	SLE15 oS15.6	pgvector	2026-03-26
SUSE	openSUSE-SU-2026:10409-1	TW	pgvector-devel	2026-03-25
SUSE	openSUSE-SU-2026:10439-1	TW	plexus-utils	2026-03-30
SUSE	openSUSE-SU-2026:10410-1	TW	pnpm	2026-03-25
SUSE	openSUSE-SU-2026:20397-1	oS16.0	poppler	2026-03-28
SUSE	openSUSE-SU-2026:20388-1	oS16.0	postgresql17	2026-03-25
SUSE	openSUSE-SU-2026:20390-1	oS16.0	protobuf	2026-03-25
SUSE	SUSE-SU-2026:1007-1		python-Jinja2	2026-03-25
SUSE	SUSE-SU-2026:20934-1		python-PyJWT	2026-04-01
SUSE	SUSE-SU-2026:20869-1	SLE-m6.0	python-PyJWT	2026-03-27
SUSE	SUSE-SU-2026:20879-1	SLE-m6.1	python-PyJWT	2026-03-30
SUSE	SUSE-SU-2026:20839-1	SLE-m6.2	python-PyJWT	2026-03-27
SUSE	openSUSE-SU-2026:0095-1	osB15	python-cbor2	2026-03-25
SUSE	SUSE-SU-2026:1094-1	oS15.6	python-deepdiff	2026-03-27
SUSE	openSUSE-SU-2026:20429-1	oS16.0	python-dynaconf	2026-03-28
SUSE	SUSE-SU-2026:20933-1		python-ldap	2026-04-01
SUSE	openSUSE-SU-2026:20421-1	oS16.0	python-ldap	2026-03-28
SUSE	openSUSE-SU-2026:0098-1	osB15	python-nltk	2026-03-27
SUSE	openSUSE-SU-2026:20407-1	oS16.0	python-orjson	2026-03-28
SUSE	SUSE-SU-2026:1075-1	MP4.3 SLE15 oS15.4 oS15.6	python-pyasn1	2026-03-26
SUSE	SUSE-SU-2026:20878-1	SLE-m6.1	python-pyasn1	2026-03-30
SUSE	SUSE-SU-2026:20835-1	SLE-m6.2	python-pyasn1	2026-03-27
SUSE	SUSE-SU-2026:1076-1	SLE12	python-pyasn1	2026-03-26
SUSE	SUSE-SU-2026:1158-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-pyasn1	2026-03-31
SUSE	openSUSE-SU-2026:0102-1	osB15	python-pydicom	2026-03-27
SUSE	openSUSE-SU-2026:20419-1	oS16.0	python-pyopenssl	2026-03-28
SUSE	openSUSE-SU-2026:20393-1	oS16.0	python-simpleeval	2026-03-25
SUSE	SUSE-SU-2026:1064-1	SLE15 oS15.4 oS15.6	python-tornado6	2026-03-26
SUSE	openSUSE-SU-2026:20406-1	oS16.0	python-tornado6	2026-03-28
SUSE	SUSE-SU-2026:1067-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	python-urllib3	2026-03-26
SUSE	SUSE-SU-2026:1090-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3 oS15.6	python3	2026-03-27
SUSE	SUSE-SU-2026:1062-1	SLE15 oS15.4 oS15.6	python310	2026-03-26
SUSE	SUSE-SU-2026:1117-1	MP4.3 SLE15 oS15.4	python311	2026-03-27
SUSE	openSUSE-SU-2026:10425-1	TW	python311-cbor2	2026-03-28
SUSE	openSUSE-SU-2026:10417-1	TW	python311-deepdiff	2026-03-28
SUSE	openSUSE-SU-2026:10411-1	TW	python311-dynaconf	2026-03-25
SUSE	openSUSE-SU-2026:10426-1	TW	python311-intake	2026-03-28
SUSE	openSUSE-SU-2026:10418-1	TW	python311-jsonpath-ng	2026-03-28
SUSE	openSUSE-SU-2026:10430-1	TW	python311-lmdb	2026-03-29
SUSE	openSUSE-SU-2026:10431-1	TW	python311-oci-sdk	2026-03-29
SUSE	openSUSE-SU-2026:10412-1	TW	python311-pydicom	2026-03-25
SUSE	openSUSE-SU-2026:10455-1	TW	python311-requests	2026-03-31
SUSE	SUSE-SU-2026:1107-1	SLE15 oS15.6	python312	2026-03-27
SUSE	openSUSE-SU-2026:10416-1	TW	python313-PyMuPDF	2026-03-25
SUSE	openSUSE-SU-2026:10419-1	TW	rclone	2026-03-28
SUSE	SUSE-SU-2026:1122-1	oS15.4	redis	2026-03-27
SUSE	SUSE-SU-2026:1066-1	SLE15	ruby2.5	2026-03-26
SUSE	SUSE-SU-2026:1027-1	SLE-m5.2 oS15.3	salt	2026-03-25
SUSE	SUSE-SU-2026:20825-1	SLE-m6.1	salt	2026-03-26
SUSE	SUSE-SU-2026:1030-1	SLE15	salt	2026-03-25
SUSE	SUSE-SU-2026:1028-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	salt	2026-03-25
SUSE	SUSE-SU-2026:1029-1	SLE15 SLE-m5.5 oS15.5 oS15.6	salt	2026-03-25
SUSE	openSUSE-SU-2026:20412-1	oS16.0	salt	2026-03-28
SUSE	openSUSE-SU-2026:20380-1	oS16.0	snpguest	2026-03-25
SUSE	SUSE-SU-2026:1065-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	sqlite3	2026-03-26
SUSE	openSUSE-SU-2026:10441-1	TW	strongswan	2026-03-30
SUSE	SUSE-SU-2026:20827-1	SLE-m6.1	systemd	2026-03-26
SUSE	SUSE-SU-2026:20826-1	SLE-m6.1	systemd	2026-03-26
SUSE	SUSE-SU-2026:1061-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	systemd	2026-03-26
SUSE	SUSE-SU-2026:1040-1	SLE15 oS15.6	systemd	2026-03-26
SUSE	openSUSE-SU-2026:10456-1	TW	tailscale	2026-03-31
SUSE	openSUSE-SU-2026:10447-1	TW	thunderbird	2026-03-31
SUSE	openSUSE-SU-2026:0111-1	osB15	tinyproxy	2026-04-01
SUSE	SUSE-SU-2026:1058-1	SLE12	tomcat	2026-03-26
SUSE	openSUSE-SU-2026:20414-1	oS16.0	tomcat11	2026-03-28
SUSE	openSUSE-SU-2026:10444-1	TW	traefik	2026-03-30
SUSE	openSUSE-SU-2026:10445-1	TW	traefik2	2026-03-30
SUSE	SUSE-SU-2026:20941-1		ucode-intel	2026-04-01
SUSE	openSUSE-SU-2026:0103-1	osB15	v2ray-core	2026-03-27
SUSE	openSUSE-SU-2026:0100-1	osB15	v2ray-core	2026-03-27
SUSE	SUSE-SU-2026:1051-1	SLE12	vim	2026-03-26
SUSE	SUSE-SU-2026:1095-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4	vim	2026-03-27
SUSE	openSUSE-SU-2026:20403-1	oS16.0	vim	2026-03-28
SUSE	SUSE-SU-2026:1139-1	SLE12	webkit2gtk3	2026-03-30
SUSE	SUSE-SU-2026:1150-1	SLE15 oS15.4	webkit2gtk3	2026-03-31
SUSE	SUSE-SU-2026:1093-1	SLE15	xen	2026-03-27
SUSE	SUSE-SU-2026:1092-1	SLE15 SLE-m5.5 oS15.5	xen	2026-03-27
Ubuntu	USN-8124-1	22.04 24.04 25.10	bind9	2026-03-25
Ubuntu	USN-8089-2	16.04 18.04 20.04	golang-golang-x-net-dev	2026-04-01
Ubuntu	USN-8130-1	22.04 24.04 25.10	gst-plugins-base1.0	2026-03-30
Ubuntu	USN-8131-1	22.04 24.04 25.10	gst-plugins-good1.0	2026-03-30
Ubuntu	USN-8127-1	14.04 16.04 18.04 20.04 22.04 24.04	imagemagick	2026-03-31
Ubuntu	USN-8128-1	18.04 20.04 22.04 24.04	libcryptx-perl	2026-03-26
Ubuntu	USN-8094-4	24.04 25.10	linux-azure, linux-azure-6.17	2026-03-25
Ubuntu	USN-8125-1	24.04	linux-azure	2026-03-25
Ubuntu	USN-8126-1	22.04	linux-azure-6.8	2026-03-25
Ubuntu	USN-8098-9	18.04	linux-ibm-5.4	2026-03-27
Ubuntu	USN-8123-1	18.04 20.04 22.04 24.04	mbedtls	2026-03-25
Ubuntu	USN-8135-1	14.04 16.04 18.04	pillow	2026-03-31
Ubuntu	USN-8134-1	14.04 16.04 18.04 20.04	pyasn1	2026-03-31
Ubuntu	USN-8129-1	22.04 24.04 25.10	pyasn1	2026-03-30
Ubuntu	USN-8133-1	16.04 18.04 20.04 22.04 24.04 25.10	pyjwt	2026-03-30
Ubuntu	USN-8132-1	16.04 18.04	roundcube	2026-03-30
Ubuntu	USN-8137-1	16.04 18.04 20.04 22.04 24.04 25.10	ruby2.3, ruby2.5, ruby2.7, ruby3.0, ruby3.2, ruby3.3	2026-04-01

Full Story (comments: none)