Welcome to the LWN.net Weekly Edition for March 26, 2026

This edition contains the following feature content:

• Collaboration for battling security incidents: Farzan Karimi explained how cooperation can make or break security efforts in his SunSecCon keynote.
• A truce in the Manjaro governance struggle: a look at the "Manjaro 2.0 Manifesto" discussion and outcome so far.
• Development tools: Sashiko, b4 review, and API specification: recent efforts to improve tooling for kernel development.
• A PHP license change is imminent: a vote is underway to approve a simpler license scheme for the popular scripting language.
• More efficient removal of pages from the direct map: a look at patch sets under discussion to remove pages from the kernel's direct map.
• Tracking when BPF programs may sleep: an attempt to allow sleepable BPF programs to transition to a non-sleepable (atomic) context.

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)

Collaboration for battling security incidents

The keynote for Sun Security Con 2026 (SunSecCon) was given by Farzan Karimi on how incident handling can go awry because of a lack of collaboration between the "good guys"—which stands in contrast to how attackers collaboratively operate. He provided some "war stories" where security incident handling had benefited from collaboration and others where it was hampered by its lack. SunSecCon was held in conjunction with SCALE 23x in Pasadena in early March.

He began with a premise that attackers, which he sometimes referred to as "hackers", collaborate, "they share tools, they share knowledge"; beyond that, they may share access to some of the members of their teams with others. On the other side, for defenders, things are different: "As effective as we are at the individual or team level, we're often victims of these organizational silos that trap us into not being able to collaborate well with each other." Specifically, "think of security versus software teams, product versus enterprise, blue team versus red team". The boundaries can be rigid: "if you're on the enterprise team and touch the scope of the product team, watch out".

He was once on a red team doing an exercise that simulated an attack by an adversary where he found a way to evade detection by disabling the endpoint detection and response (EDR) sensor system. His counterparts on the blue team were unhappy with that methodology because they wanted to use that information to see how he was attempting to evade detection; he pointed out that if attackers can disable EDR, they will. The exercise did not end particularly well, as he was called a "cheater" and a "one-trick pony", which hurt at the time and had the effect of isolating him from working with the blue team.

The goal for the talk was to share some stories that demonstrated how successful collaboration on the defensive side "can transcend the attacker and lead to arrests"; on the flip side, failure to collaborate well can lead to "the attacker getting the upper hand". Karimi briefly introduced himself as the deputy chief information security officer (CISO) at Moderna, which is a Boston-based biotechnology company. He has led offensive security teams for around 15 years, including the red team at Google for Android for a few years, and before that was the founding member of a red team at the game company Electronic Arts (EA). He has spoken at the Black Hat and DEFCON security conferences over the years as well.

His theory is that "the real 0-day in companies isn't necessarily a technical flaw", it is, instead, isolation between humans in the organization. There are social pressures, such as the "fear of looking stupid" or individuals having the "hero mentality", that work against collaboration. While his stories were about security incidents, the details of those are not what is important in the talk. "It's the human behavior after the exploit, these tense situations where they escalated or de-escalated based on how the conversations went".

Story time

A talk he gave at DEFCON 33 in 2025 (YouTube video, slides) provided another example of collaboration gone awry. He presented a new technique, recursive request exploit (RRE), in the talk, but 17 hours before it began he was contacted by the legal department of a company that was affected by the exploit. The company felt that he had not done responsible disclosure, because it expected the problem to be reported to its HackerOne account, but Karimi had used email—to an address that he did not realize was not monitored.

The company had heard about his upcoming talk from a journalist and was threatening legal action if he gave the presentation. So, less than a day before the talk that he had spent months preparing for, he participated in a phone call where he explained what had happened; "it was really just a big miscommunication". He and the company had a different view of things, however. "I thought I was in the right and ethically I thought I took all the right steps, but the optics were different." When that kind of thing happens "you find yourself in a very difficult conversation and you have to find ways to de-escalate in those tense situations". He did not elaborate further, but he must have found some way to de-escalate since he gave the talk shortly thereafter.

When he was at EA, he worked on an incident regarding the virtual currency that is used in the FIFA football (soccer) video games. The currency can be used in-game to create a better team, but it can also be used to buy game merchandise; the FIFA coins have value outside of the game itself, so they are attractive to attackers. A Europe-based attacker found a vulnerability in an API for FIFA that allowed them to generate FIFA coins.

The attacker was able to create $324,000 in the virtual currency, which they immediately distributed across 25,000, seemingly random user accounts. That might seem like they were a "digital Robin Hood just giving FIFA coin back to the people", but a closer analysis showed that some of those accounts were actually controlled by the attacker. They were simply trying to obfuscate where the money was going. That really stacked the deck against EA being able to do something about the crime because it was a foreign actor stealing money and hiding where it was going.

As it turned out, though, "good collaboration across multiple teams led to this person's arrest". When the theft was happening, the EA blue team noticed that something had gone wrong and analyzed the logs to discover which APIs had been attacked. Sometimes, a blue team will just continue doing that kind of analysis, but for this event, it did something different: "they looped in my red team" and asked if the attack could be reproduced from the logs as a form of evidence that it was what the attacker had done.

The red team was able to do that and provided the information to EA's legal team, which took it to court. The judge agreed that a crime had been committed, but the attacker was based in Italy at the time. Karimi said that he was not participating at that point, but that because it was a large enough sum of money, the FBI got involved and the attacker was somehow invited to come to the US. When he did, he was met by the FBI and arrested, eventually going to prison and having to pay restitution. So that was an example of a "really good collaboration, between IR [incident response], red team, and legal".

Unplanned collaboration

His next story was an example where the collaboration was not planned, but was forced on him. He was running a red team and compromising systems, which was exactly what he should be doing, but he unknowingly "compromised" a honeypot for an advanced persistent threat (APT) that attackers had left on the company's systems. The attackers behind the honeypot realized that he was part of the red team, so they used his credentials to launch other attacks on the network—effectively disguising their activities as coming from his account and systems.

One day, an investigator showed up in his office asking some rather pointed questions about what he had been up to, since the attackers had been targeting executives in the company. She was aware that he was not actually the attacker, but "she could have talked to me as if I was the victim or if I was an idiot red-teamer that didn't care about hygiene and left my credentials everywhere". She took a different approach that has stuck with him throughout his career since: she enlisted his aid in monitoring the attackers behind the APT.

"Instead of making me feel stupid, she brought me into the broader IR [incident response] initiative, which was really magic in a way". She probably does not even remember him, he said, but her actions made a big impact on him. She asked him to keep doing his normal things, which was hard given that he knew there were two different groups of people watching his every move. He had to keep that up for around two weeks, while the forensics team would periodically ask him to access various systems so they could watch the APT team follow along shortly thereafter. That allowed the team to collect a bunch of indicators of compromise (IOCs) and it shows, he said, that incidents can also be opportunities.

Over the line

The next tale was about "one of the most humbling moments of my career". While on a red team at Microsoft, he was doing an authorized penetration test (pentest) of an HR application that stored sensitive information about employees, including their salaries. He found a vulnerability that allowed him to get access to salary information, so he stopped and reported the bug.

But, instead of stopping after compromising one record, he made a mistake and wrote a script that pulled out more than 1,000 employee salaries, "like an idiot ... in retrospect". At the time, he thought he was demonstrating the scale of impact. He was "feeling really full of myself" after finding this critical flaw, so he made a second mistake. He joked with his office-mate that he was the lowest paid security engineer at Microsoft.

His office-mate laughed, but someone down the hall heard the joke and they did not laugh. Instead they escalated it and Karimi was called into his manager's office about an hour later. There, Karimi found out that he would not be getting the promotion that he had hoped the find would solidify, but that he might lose his job over the incident, which had already gone to legal as an ethics violation. In a ten-minute span, he had gone from a high that he had found a critical flaw to realizing that his whole career might be in jeopardy.

That kind of situation goes well beyond red-team activities, he said. Anyone with administrative access should be extremely careful in determining whether to use it; "just because you can, doesn't mean you should, and, if you have to think about it, you probably shouldn't". The scope of the work may provide legal permission, "but trust is the social permission and you really need to have both in order to be successful". He did manage to keep his job, which was a positive outcome.

Entertainment conference

The final story was about the web application for ticket sales to a prominent southern California entertainment conference, which he could not name due to an agreement with the conference's legal team. There are about 70,000 attendees and some of them were losing access to their legitimately purchased tickets at the same time there was a spike in ticket sales on reseller sites. He did not work for the conference and was not hired to work on the investigation, he just happened to be attending the conference; "it's a great story of surprise collaboration".

The impact of the problem is potentially quite large, roughly $35 million in total ticket sales and lots more if the conference had to be canceled because of the problems. Ticket buyers would receive an email that contained a link to directly take them to their page in the web portal—without having to log in. He asked if attendees had ideas about what kind of vulnerability to look out for; someone correctly guessed "IDOR", which is an insecure direct object reference.

He showed a redacted version of his portal page and the URL, which had two parameters of interest: login=FKnnnnn and pwd=mmmmm where nnnnn and mmmmm are two different numbers. He asked the audience for ideas on what to change in the URL; someone noted that "FK" are his initials and that the pwd number corresponded to the registration number on the page. He agreed and noted that the registration number was an incrementing integer per registration. The number after his initials turned out to be his phone number. "All of these are guessable parameters."

It gets worse, though. The phone number was a throwaway field in the login, he said, so the primary key was just the initials. In five minutes or so he had written a proof-of-concept script to loop through all of the initials "AA" to "ZZ" trying each pwd number from one to 900,000, which showed "hundreds and hundreds of tickets" that could be compromised. He took that to the organization, which immediately stepped up to fix the vulnerability and to handle the fraudulent ticket reselling. He asked attendees what they thought he got paid for that work, which was not zero, as guessed, but slightly more—a T-shirt, he said to laughter.

"It doesn't matter whether you're a defender or you're on the offensive side, a software engineer or a sysadmin, when we stop treating each other as opponents, we win." Once that happens, "we start trusting each other more as a result". That is the thread running through all of the stories he related, he said.

The talk video is not yet available, but the YouTube livestream recording is for anyone interested in seeing the talk.

[Thanks to LWN's travel sponsor, the Linux Foundation, for its travel funding to attend SCALE in Pasadena.]

Comments (none posted)

A truce in the Manjaro governance struggle

Members of the Manjaro Linux distribution's community have published a "Manjaro 2.0 Manifesto" that contains a list of complaints and a demand to restructure the project to provide a clear separation between the community and Manjaro as a company. The manifesto asserts that the project's leadership is not acting in the best interests of the community, which has caused developers to leave and innovation to stagnate. It also demands a handover of the Manjaro trademark and other assets to a to-be-formed nonprofit association. The responses on the Manjaro forum showed widespread support for the manifesto; Philip Müller, project lead and CEO of the Manjaro company, largely stayed out of the discussion. However, he surfaced on March 19 to say he was "open to serious discussions", but only after a nonprofit had actually been set up.

Manjaro is based on Arch Linux; the idea behind the distribution is to provide a user-friendly version of Arch that is focused on stability. Manjaro provides additional tools for system maintenance, and has its own software repositories. The distribution uses a rolling-release model, with three branches (stable, testing, and unstable) for users to choose from. It began as an installer for Arch Linux, created by Müller, Guillaume Benoit, and Roland Singer, which was first announced in 2011 on the Arch forum and operated as a volunteer-driven project. As the project became more popular, it began taking donations for server costs and other "special activities" in 2013. The first stable release, Version 15.09 ("Bellatrix"), was announced in September 2015.

Müller announced in 2019 that he was forming a company in Germany with Manjaro core team member Bernhard Landauer. If that was discussed with the larger Manjaro community beforehand I have not found any evidence of it. The company was set up as a Kommanditgesellschaft (KG) called "Manjaro GmbH & Co. KG". Its stated goals were to improve the Manjaro infrastructure, become self-sustaining, and to hire additional contributors. It was also announced that the new company would hold the Manjaro trademarks in the EU and US "to prevent unauthorized use of Manjaro as a brand" while ensuring that the name could "always be used freely by the community". In 2024, the company announced that Landauer was leaving "to focus on other professional endeavors", and would be replaced by Roman Gilg as the chief technical officer.

Laptop-gate

The project has had some problems with the separation between company and community before now. Manjaro had already been taking donations for various activities before the formation of the company; funds were held in Müller's bank account. After the formation of the company, the funds for its community activities were moved to Open Collective. In 2020, after the split between company and community finances, there was a controversy over the purchase of a laptop from community funds.

Jonathon Fernyhough, who passed away in 2023, was serving as treasurer for Manjaro's community donations in 2020. He said that Müller had approved the purchase of a laptop by an unidentified third person against the project's written expense policy: Fernyhough rejected the expense. That led to his leaving his post as treasurer:

Phil was unhappy about the rejection and the additional questions about how community funds would be used. As a consequence I am no longer treasurer, leaving Phil in control of all funds once again. Phil is now in a position to use community funds as he sees fit in order to move the community project in the same direction as his company.

I will still be floating around the forum but at this point Manjaro doesn't seem all that friendly any more.

A forum post by Matti Hyttinen about Fernyhough's departure asserted that the laptop purchase was a legitimate expense, but the disagreement was solely about the process involved. It also said that Fernyhough's "position within the team became untenable" because of the way that he had expressed his disagreement about the handling of the expense. Fernyhough, though, called into question the way that community funds were being used, not just the failure to follow written process. He said that there was a definite conflict of interest with Manjaro GmbH "making deals with a hardware company to optimise Manjaro for laptops, then claiming expenses from community funds for laptops from that company to do development for that company."

Manifesto

Frank Vandermeiren made the manifesto public on March 9. It states that it is meant to be used as a focus for discussion and, ultimately, a guide for an organizational restructuring of the project. It describes separating the project from the company entirely and forming a nonprofit ("Manjaro e.V.") registered association. The Manjaro for-profit company would, over time, become a downstream of the project. The document also goes into some detail about how people would join the nonprofit association, how the decision-making process would work, and so forth.

The motivation given for this is that the project has "stagnated, lost trust, lost almost all of its contributors, and even became a laughingstock for repeatedly making the same mistakes" such as failing to renew SSL certificates in a timely fashion. The manifesto refers to "project leadership", rather than naming Müller directly, but also argues that Manjaro is "being run as one individual's personal project" with everything centralized around that person; it does not require much detective work to make the connection. It claims that Müller refuses to share access to supporting infrastructure for Manjaro with the rest of the project's team.

The Manjaro name is only used for its popularity, and the community is only used as guinea pigs and as unpaid workers, with as a result that the Project is severely suffering. As an example of this, no attempt is being made to acquire any funds for the Project, and the funds owned by the Manjaro GmbH & Co KG company are not being invested into the Project, with as a result that the Project's funds have now run out, causing Manjaro's only full-time developer to lose their only source of income.

We want the Manjaro Project to be revitalized, regain respect, attract contributors, and again provide meaningful value to the Open Source community.

The developer the manifesto is referring to seems to be Mark Wagie, though he does not seem to have been receiving full-time wages; according to the expenses page on Open Collective, he has regularly received payments from the project on an almost-monthly basis, totaling about €15,000, going back to October 2023. The Open Collective project page shows that Manjaro has raised a total of €87,556.13 since it joined, and has disbursed nearly €82,000 of that; it currently has a balance of less than €6,400. The project raised about €15,600 in the last 12 months via Open Collective; it does not appear that any of the funds came from the company.

Demands

In addition to its complaints and ideas about the future, the manifesto also makes a few demands. First, it says that the project expects the company to provide a license for use of the Manjaro trademark through 2029, while retaining the right to use the mark for its own products "as long as the Manjaro GmbH & Co KG company's use of the trademark does not cause any confusion" with the projects and such offered by the nonprofit. It also demands that the company declare its willingness to yield the trademark to the nonprofit entirely after 2029 for the price of one Euro.

On top of requiring the company to hand over the trademark, the manifesto demands that any assets or infrastructure "for which the Manjaro Project is its primary user" be handed over to the nonprofit. That includes the relevant GitHub organizations, Git repositories, Manjaro forum, manjaro.org domain, and more. The company is allowed to continue using the infrastructure "but is expected to actively work towards migrating as much as reasonably possible" and compensate the nonprofit for the usage costs. Further, the nonprofit would not guarantee that any shared services would be continued; the project could take down services or replace them without consulting the company first.

Finally, it states that if Müller ignores the manifesto, or does not make a serious attempt at "negotiating an acceptable compromise solution", the supporters will take action in stages. The first stage was simply to wait "a reasonable timespan" for a response; apparently he was given a copy of the manifesto privately around February 23. The second stage is to publicly release the document, which has obviously happened, and begin a "general strike"; the supporters of the manifesto will stop their "nonessential" work on the distribution and community efforts. The third stage is to "consider forking and/or leaving" the project.

The Manjaro web site lists a core team consisting of 17 people; at least six of those team members, including Gilg, have signed on in support of the manifesto. A few of the signatories have used only their forum usernames, so it is not clear whether those people are core team members. It also seems likely that some of the team are no longer active in the project, but have not been removed from the team list.

Reactions

Since the manifesto was made public on March 9, there have been more than 220 responses in a separate thread created specifically for the discussion. The first response, from Todor Uzunov, was completely in favor of the proposal: "The project is going down the drain as it is and is in many aspects poorly maintained. I was actually looking for alternative as a main daily OS because I cannot imagine this will survive another year or two." Koshika Surasena said that he whole-heartedly agreed with "all sentiments discussed and evident", but hoped that the community had not jumped the gun by going public. He worried that a public fight might harm the project, but noted that "waiting can only go for so long, and the project is definitely in a downward trend now".

Dennis ten Hoove, one of the manifesto's signatories, elaborated on the claims that the distribution had stagnated in the past five years or so. Manjaro had once had a "sizable group of people" contributing between five and ten years ago, but only two remained active with "maybe another 2 people picking up small stuff every now and then". He complained that there are "piles of issue reports being unaddressed" and pointed out that the work on Manjaro Arm has stalled. Releases for Arm seem to have stopped in early 2023; the images offered on the download page are from the 23.02 release, which was announced in February 2023. He also voiced concern about core applications like Manjaro's package manager (Pamac) and its installer (Calamares):

If a backbone application such as Pamac or Calamares breaks the project lacks motivated people with the skills to fix it. The Pamac dev has been MIA since the end of last year and there is a reported crash which needs fixing, but it is not getting fixed because there is no backup.

The majority of users seemed to be in agreement with the need for change, but not all. User "wntr" said that the manifesto was overly aggressive and "a coup demanding an unconditional surrender. Nobody sane would agree to this." They warned that a failure to reconcile could become "a public and possibly legal battle about who gets to be king of the pile of ash".

Another user, "Kobold", felt that things were fine. "I couldn't be happier with the Distro and I don't think that I would find a good replacement for Manjaro". In a later comment, though, they pointed to a thread from November 2025 that cast some doubt on the health of the project. The topic was about updates to Manjaro's stable repository; why had it not been updated in two months? When Todor Uzunov said that the project was understaffed, Müller's reply raised more questions than it answered: "Basically Mark and I do some work for Manjaro but we don't know for how long".

In context, his comment suggests that things may not be going well for Manjaro as a business, and that perhaps Müller is feeling burned out as well. If so, that would not be surprising; burnout is a real problem for open-source maintainers as well as small-business founders. Trying to be both simultaneously is, no doubt, quite demanding. The comment, though, does little to reassure other contributors or users when it's coming from the project lead who seems to have sole access to much of the project's infrastructure.

Müller's response

His first reply to the manifesto did little to quell concerns. Müller said that he had been sent a draft of the manifesto and was told it might be formally submitted at a later date. Now that it had been posted to the forum, it seemed that the community's intentions to form a nonprofit association were serious. He said that he had no personal objections to the founding of a nonprofit, but he would not be involved in the process.

Any transfers of company assets or infrastructure require close consultation with the company and yet to be established new legal entity, in order to ensure that the interests of both parties are safeguarded as amicably and smoothly as possible. Any actions that could damage the business must be ruled out. To ensure the smooth operation of the company, assets relevant to the company will remain within the company.

Finally, I would like to note that any actions or comments that could damage the business or reputation of myself or the company should be refrained from in order to ensure a mutually agreeable process and avoid legal actions.

Gilg, who at present still seems to be with the company despite having signed on to the manifesto, thanked Müller for the reply and "general agreement" that an association should be founded. He questioned the need for consultation with the company about the transition of assets to an association. The manifesto already provides a "precise list of assets", and he did not see a problem moving them to an association. Gilg asked if Müller saw an issue with it, but he did not reply directly. Nor did he reply to any of the other issues raised in the manifesto or participate in the discussion. However, Müller had been active on the forum in other threads; on March 16, he announced a set of package updates and warned that an age-verification law in Brazil might impact Manjaro users.

An association it is

On March 17, Vandermeiren acknowledged that with the matter out in the open it is difficult for Müller to respond publicly "without pulling a boatload of haters on top of himself", but noted that he has not responded via "the back channels" either. He said that the group behind the manifesto is patient and respectful, but a decision would ultimately have to be made.

Two days later Müller replied that "it seems a bit like the 'Mutiny on the Bounty'" to him, but he was not against having a nonprofit association. He would be open to discussions with a new entity, when it exists: "From my perspective, the new entity must first be established and a transition plan drawn up before anything can actually be set in motion." He also indicated that he had spoken to Gilg, and that Gilg had expressed an interest in taking the lead in founding the nonprofit association.

The ball is in your court. Decide as a community. Go ahead and set the new entity up, then get in touch with me – otherwise, business as usual...

Vandermeiren replied that the response "gives us hope that we can work out this problem very soon". Ten Hoove said that he thought there was an agreement to move forward, and that Gilg would handle the founding of the association. "We'll do as you ask and found the e.V., then work together to facilitate the migration of community components to said e.V." He also thanked the community for its support, "we'll take it from here. And we'll keep you in the loop."

For now, it appears there will be a return to the status quo until an association is founded and negotiations begin. Müller has only indicated a willingness to have discussions, though; he has not provided a guarantee that he is willing to turn over all, or any, of the assets listed in the manifesto. We will keep an eye on any developments as they happen, and hope that the outcome is a good one that serves the Manjaro community well.

Comments (1 posted)

Development tools: Sashiko, b4 review, and API specification

The kernel project has a unique approach to tooling that avoids many commonly used development systems that do not fit the community's scale and ways of working. Another way of looking at the situation is that the kernel project has often under-invested in tooling, and sometimes seems bent on doing things the hard way. In recent times, though, the amount of effort that has gone into development tools for the kernel has increased, with some interesting results. Recent developments in this area include the Sashiko code-review system, a patch-review manager built into b4, and a new attempt at a framework for the specification and verification of kernel APIs.

Sashiko

Sashiko has been slowly gaining visibility in the development community; it was formally announced by Roman Gushchin on March 17. It is based on large language models, and its job is to review patches posted to the kernel mailing lists. According to Gushchin:

In my measurement, Sashiko was able to find 53% of bugs based on a completely unfiltered set of 1,000 recent upstream issues using "Fixes:" tags (using Gemini 3.1 Pro). Some might say that 53% is not that impressive, but 100% of these issues were missed by human reviewers.

Developers have already started paying attention to the tool's reviews, with some maintainers (Andrew Morton, for example) expecting patch submitters to read and respond to those reviews.

Sashiko is based on a set of review prompts initially developed by Chris Mason, but it uses "a different multi-stage review protocol, which somewhat mimics the human review process and forces the LLM to look at the proposed change from different angles". While the only access to Sashiko is through the web interface now, the plans inevitably call for it to develop the ability to send out reviews over email.

The system is described as being "fully open-source", downloadable from a GitHub repository under the Apache-2.0 license. The ownership of the code itself has been given to the Linux Foundation. Sashiko is, of course, an open-source system that is built on a proprietary foundation (the Gemini model), so it is not truly a free-software solution. But it is a step closer to that than what we had before. And a tool like this does indeed seem to bring value to the community. While the ability of LLMs to generate kernel code is unproven at best, their ability to find obscure problems in code written by humans has been reasonably well demonstrated.

The use of tools like Sashiko will surely grow, but there is a worrisome aspect as well. Since Sashiko depends on its underlying LLM, the Sashiko service depends on some generous benefactor being willing to make the LLM time it needs available. That is happening now, while the AI bubble remains pretty well inflated and the purveyors of LLMs are trying to create dependencies on those models wherever they can. At some point, though, that generosity seems likely to come to an end. Google is nicely donating LLM time for Sashiko now, but remember that the company once freely handed out Nexus One phones to developers. Now those developers are expected to buy their own toys. One hopes that, when that history repeats itself in the LLM context, the community will not have let the ability to do its own reviews atrophy entirely.

b4 review

Konstantin Ryabitsev's b4 tool has changed kernel development in a number of ways. Maintainers depend on it to simplify the tasks of applying patches and adding review tags. Increasingly, developers (especially those who do not work full-time in the kernel community) use it for email-free patch submission. B4 can download email threads from the lore archive, making it possible to read kernel-related discussions locally without subscribing to the linux-kernel firehose. The in-development review functionality, which is not yet part of a formal b4 release, promises to further ease the patch-review process.

In short, the b4 review subcommand provides a terminal-based interface to a number of patch-review operations. After enrolling a repository, the user can add one or more patch sets of interest, using message IDs, lore URLs, or by simply piping a patch into the tool from an email client. The main b4 review screen lists each in-progress patch set and its current state.

A separate review screen allows looking at each patch in a series. With a single keystroke, an entire patch series can be fed to the checkpatch.pl tool, and the results gathered for inspection. Another keystroke opens an editor with a specific patch where the reviewer can enter comments in the usual way. There are operations to add tags (Reviewed-by, for example) to the response. Inevitably, another command will feed the patch to the user's LLM-based review system of choice; Sashiko integration is underway as of this writing. Once the comments are deemed ready, they can be emailed back out with another command.

For maintainers, b4 review can bring in comments sent by others for consideration. There are also tools to apply a set of accepted patches, and to help with conflict resolution. And, at the end of it all, there is feature to automatically send "thank-you" notes to the submitters whose patches have been applied.

Intrigued, I played a bit with b4 review on the stream of documentation patches; the screenshots in this section are the result of that experiment. The tool in its current state has a lot of rough edges — it is described as being in "alpha" condition, after all. That experiment resulted in the posting of an embarrassingly mangled review that led to the discovery (and fixing) of a b4 review bug; a number of other issues were reported as well. This tool is fun to play with, but it is not yet ready for sustained production use.

It will get there, though, and it has the potential to change how a lot of people work. b4 review is not the first patch-tracking and management tool out there, but it is one that is designed to work in a distributed manner, without a central server. It is a part of Ryabitsev's effort to reduce the role of email in the development process to a sort of transport layer, and to free contributors from the need to engage directly with it if they do not wish to. The lore archive would be hard to replace, but b4 review does not otherwise depend on any system being up and available. This is a tool that is worth watching.

API specification

There has been a recurring desire for better ways to specify the interface that the kernel provides to user space — and to verify that this API actually matches the specification. A specification of this type, if it could be created and maintained, would serve a number of purposes. It would help developers ensure that patches do not change the user-space API in incompatible ways. Formal verification tools would have a better description of how the kernel is supposed to work. Development environments could use this description to assist in the writing and debugging of code. And so on.

Efforts to implement this sort of specification have typically languished, though, for a number of reasons. For example, a group including Gabriele Paoloni has been working on a specification language for some time, but has struggled to attract interested developers. A separate effort in this area, most recently posted on March 13, is a specification framework by Sasha Levin. This is a new version of work that was last covered here in 2025.

Like other attempts, Levin's work is focused on the kernel-doc comments that already describe thousands of functions within the kernel. It expands the coverage of those comments to describe, in a formal way, many aspects of a function's behavior. As an example, the documentation for this framework provides an example comment for kmalloc() (which is not part of the user-space API, but internal functions can be specified too):

    /**
     * kmalloc - allocate kernel memory
     * @size: Number of bytes to allocate
     * @flags: Allocation flags (GFP_*)
     *
     * context-flags: KAPI_CTX_PROCESS | KAPI_CTX_SOFTIRQ | KAPI_CTX_HARDIRQ
     * param-count: 2
     *
     * param: size
     *   type: KAPI_TYPE_UINT
     *   flags: KAPI_PARAM_IN
     *   constraint-type: KAPI_CONSTRAINT_RANGE
     *   range: 0, KMALLOC_MAX_SIZE
     *
     * error: ENOMEM, Out of memory
     *   desc: Insufficient memory available for the requested allocation.
     */

The first four lines are part of the existing kernel-doc format; everything after that is new. This specification describes the contexts within which kmalloc() can be called, various details about the parameters to the function, and the return value. For a rather more detailed example, see the specification for the read() system call, which goes on for several pages. It covers the parameters and (numerous) error returns, as seen above, but also includes information on signal handling, lock acquisition, side effects (modifying the file position, for example), and more.

There is an alternative format using macros rather than comments; it's not entirely clear why the second format exists. Beyond functions, there are plans for facilities to describe the arguments to ioctl() calls.

Once the specifications exist, there are a number of things that can be done with them. There is a tool to ensure, at compile time, that the specifications are consistent with the declarations of the functions they describe. The specifications are available via the debugfs filesystem in human-readable, JSON, and XML formats. There is also a run-time validation mode that checks whether functions are called in an allowed context with parameters within the given constraints, and that the return value is as specified. The cost of all this is nearly 500KB of memory used for each described function; this is not a feature one would want to enable in production kernels.

The problem with this kind of specification mechanism is always the same. Few people disagree with having precise specifications for how the code is supposed to work, but even fewer seem to be willing to put in the time to create and maintain those specifications. The work can be tedious and tends not to astonish users with exciting new features; it is the sort of thing that people generally need to be paid to do. LLMs can be pressed into service for some of this work (as was done for this series), but humans still need to be involved to be sure that the results are accurate — and to maintain them going forward. Creating this sort of framework is feasible from a technology point of view, but success in this area will also depend on solving the social problem of creating and maintaining the specifications themselves.

Comments (2 posted)

A PHP license change is imminent

PHP's licensing has been a source of confusion for some time. The project is, currently, using two licenses that cover different parts of the code base: PHP v3.01 for the bulk of the code and Zend v2.0 for code in the Zend directory. Much has changed since the project settled on those licenses in 2006, and the need for custom licensing seems to have passed. An effort to simplify PHP's licensing, led by Ben Ramsey, is underway; if successful, the existing licenses will be deprecated and replaced by the BSD three-clause license. The PHP community is now voting on the license update RFC through April 4, 2026.

In its early days, the PHP project changed its licensing with some frequency: between 1995 and 2006, PHP changed licenses or modified the terms of its custom licenses seven times. Initially, PHP was distributed under the GPLv2. Then PHP 3, released in 1998, was shipped under a dual-license scheme; it was available under the GPLv2 and a new PHP License based on the Apache License 1.0. This was chosen by PHP creator Rasmus Lerdorf to make PHP more palatable to commercial interests:

PHP2 has gotten quite a few nibbles from various commercial interests over the past year. The GPL, plus my own stubbornness killed most of them. PHP, if I can help it, will always be free. But, I am not against letting commercial entities take a shot at a commercial version as long as the terms are such that the major contributors don't feel cheated.

The first iteration of the custom license, though, had a clause that required written permission from the PHP development team for commercial redistribution. That proved unworkable, so the clause was stricken for the PHP 3.0.14 release. The LICENSE file in that release did not carry a version number.

PHP 4.0, released in May 2000, was a major overhaul; it included the Zend Engine, described at the time as a full rewrite of the PHP scripting engine, written by Zeev Suraski and Andi Gutmans. The pair had formed a company, Zend Technologies, which sought to commercialize the Zend Engine separately from PHP; it provided a grant to allow the Zend Engine to be integrated into PHP and guaranteed that it would remain under the Zend license or another license consistent with the Open Source Definition (OSD) from the Open Source Initiative (OSI), even though the Zend license itself is not OSI-approved. Thus, the PHP project picked up the Zend license for code in the Zend directory of its source tree. PHP 4.0 also dropped the GPLv2 altogether in favor of the PHP License version 2.02.

PHP's licenses were updated a few more times; the PHP 3.0 license was approved by the OSI, but the license received a small final set of changes that pushed it to version 3.01. The changes only modified the copyright years and rephrased how the acknowledgements should be phrased for PHP and Zend, they did not impact the rights granted in any way. The reasons for that change are lost to the mists of time, but that version was never approved by the OSI. The license text has proven to be a problem because it only appears to apply to software shipped by the "PHP Group". Confusingly, the PHP Group does not seem to be an actual legal entity, but a list of ten people involved in PHP development early on. Some contend that software from parties other than the PHP Group cannot use it as a valid license. That has caused headaches for other projects, such as Debian. Ramsey has covered the history of PHP's licensing in the RFC for those who want even more detail.

Proposal

Ramsey opened discussion on the RFC in July 2025; he proposed replacing both of the existing licenses with the three-clause BSD license beginning with the next major release, PHP 9.0. He had enlisted an expert for the exercise; he said he was working with Pamela Chestek, chair of OSI's license committee, for legal questions and concerns.

He said that he had already spoken with all the members of the PHP Group and each member had already voiced approval for the change. He had also gotten approval from Perforce Software, which had acquired Zend in 2019 as part of the portfolio owned by Rogue Wave Software (which had, itself, acquired Zend in 2015). One might wonder about all of the individual contributors who had submitted code to PHP over the years: don't they also have to approve a license change? In the RFC, Ramsey argues that is not the case. PHP has not required a contributor-license agreement (CLA) to assign copyright to the project, and there is no implicit transfer of copyright to the project. However, there is an implied assignment of license:

When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license covering their contributions (which is wholly valid, with examples including Derick Rethans's timelib, which is bundled within the PHP source code), it is implied they are granting use of their contributions under the same license terms as the project.

[...] Typically, when changing the license on an open source project, one must gain approval from all copyright owners, since the rights granted might change under the terms of the new license. However, as described in this section and in other places in this document, changing to the Modified BSD License does not change any of the rights granted by contributors who are not the PHP Group or Perforce Software.

Even though the RFC asserts that the project does not require permission, it says that the discussion would remain open for at least six months "as a courtesy" to ensure that interested parties had an opportunity to respond. Ramsey provided updates and reminded people that the topic was still under discussion a few times since the RFC's announcement in July; thus far, it does not seem that anyone has objected.

A few people have had questions, of course. Rethans wondered "why wait until (specifically) PHP 9, and not PHP-next (the one after 8.5)?" Ramsey said that there were no technical or legal reasons; it just seemed like the PHP 9 release would be the right time to make the change. If others thought 8.6 would be the appropriate time, that was also fine. The RFC was later updated to change the proposal to the "next version" of PHP.

Peter Kokot suggested that GPL-compatibility should be "just slightly clarified to make PHP usage simpler in the future for cases when GPL-licensed software is involved". He pointed out that PHP has the option to be linked to two libraries that use GPLv3: the GNU Readline Library and the GNU dbm (GDBM) database-function library. He was thinking of deprecating build-time linking options for those libraries to make PHP "worry-free for packagers". Ultimately the possibility to link to GDBM and Readline would be removed entirely. Ramsey said that the change would make things simpler for packagers:

For those who are packaging PHP and linking against GPL libraries, the current PHP License, version 3.01, presents an incompatibility that cannot be resolved because of the additional restrictions it places on users. However, under the Modified BSD License, there is no incompatibility, as long as the combined package is released under the terms of the GPL.

On March 14, Ramsey announced that he was opening voting on the RFC. The votes are public and tallied on the PHP wiki in the body of the RFC. It's unclear how many eligible voters there are in total currently: in 2019 there were 180 people with voting privileges. At the moment, 47 people have voted in favor, two have voted to abstain; even though the early results seem overwhelmingly positive it is not yet certain the proposal will pass. If it does, though, it is largely thanks to the work that Ramsey has put in over the past few years in behind-the-scenes conversations, getting approvals, and shepherding the RFC to a final vote.

Comments (3 posted)

More efficient removal of pages from the direct map

The kernel's direct map provides code running in kernel mode with direct access to all physical memory installed in the system — on 64-bit systems, at least. It obviously makes life easier for kernel developers, but the direct map also brings some problems of its own, most of which are security-related. Interest in removing at least some pages from the direct map has been simmering for years; a couple of patch sets under discussion show some use cases for memory that has been removed from the direct map, and how such memory might be efficiently managed.

The good thing about the direct map is that it gives the kernel easy access to all of the system's installed memory. That is also the bad thing about the direct map, of course. When all of memory is accessible, it becomes a target for attackers. A stray pointer might be pressed into service to corrupt data anywhere in the system (though technologies like supervisor mode access prevention can help). Directly mapped memory is also susceptible to speculative-execution attacks, which can be employed to exfiltrate information from the kernel or from an unrelated process or virtual machine.

Many of these attacks can be thwarted by removing memory from the direct map; if memory is not reachable, the kernel cannot access it and, as a result, cannot disclose or modify its contents. The memfd_secret() system call will remove memory from the direct map for this reason, but wider use of direct-map removal has been slow to come. Memory that is not in the direct map is harder to manage, and there are a number of performance problems that can be caused by removing memory from the direct map. So, while various patches have been in circulation for a while, they have not generally cleared the bar for inclusion in the mainline kernel.

guest_memfd

A common use case for large Linux systems is to run virtualized guests, often hosting multiple unrelated — and possibly hostile — users. It should come as no surprise that there are attackers out there who are interested in targeting some of those virtual machines from others on the same host. There are a number of efforts being made to thwart such attacks, at both the hardware and software levels; one of those is this patch set implementing direct-map removal of guest_memfd pages, posted by Nikita Kalyazin, built on work initially posted by Patrick Roy.

A guest_memfd is a form of memfd (a block of memory attached to a file descriptor) intended for use by virtual machines. This memory has a number of special characteristics, including the fact that it cannot normally be mapped into user space on the host system. That makes attacks from the hosts a bit harder, but there is more that can be done.

On systems with the right sort of hardware support, memory in a guest_memfd can be encrypted, making access from outside the virtual machine impossible. Not only is the host unable to decrypt the contents of the memory; any attempt to access it will generate a machine-check exception. That makes encrypted memory into a sort of land mine that would be best removed from the host kernel's address space entirely. Beyond that, though, encrypted memory is far from universally available. On systems where guest memory is not encrypted, removing it from the direct map will make it more resistant to attacks from the host, and far less susceptible to speculative-execution attacks from hostile guests.

So this patch set adds a new flag, GUEST_MEMFD_FLAG_NO_DIRECT_MAP, to the KVM_CREATE_GUEST_MEMFD ioctl() call provided by the KVM hypervisor. When that flag is present, the memory assigned to the newly created memfd will be removed from the host kernel's direct map. Internally, the series creates a new address-space flag, AS_NO_DIRECT_MAP, to mark an address space that is not directly mapped. When the memfd is freed, the underlying memory will be restored to the kernel's direct map.

Direct-map removal creates an interesting problem: how does KVM itself, running on the host, access the memory within the guest_memfd? There are a number of operations, many having to do with emulated I/O devices, that need that sort of access. The problem is solved by mapping the guest_memfd memory into the user-space address space (on the host) of the KVM process that is running the guest; KVM can then access that memory by way of functions like copy_from_user(). The end result is that the mapping of the memory has been shifted from the kernel's address space to a specific user space. That is sufficient to protect it from speculative-execution attacks on the kernel from a different guest.

This patch series has been circulating since July 2024, and has yet to clear the bar for merging into the mainline kernel. There are a few concerns holding this kind of work back, one of which is the performance implications of fragmenting the kernel's direct map, which, when it can, uses a huge mapping, reducing pressure on the system's translation lookaside buffer (TLB). Work done by Mike Rapoport a few years ago showed that the performance implications are not as bad as some had feared, but this fragmentation is still best avoided if possible. Meanwhile, flushing the TLB globally to reflect direct-map changes is expensive. Another roadblock, though, is that KVM can be built as a loadable module, and the memory-management developers are reluctant to export the ability to manipulate the direct map to modules. Given that there are other potential reasons to remove memory from the direct map, perhaps a better way of doing that is indicated here.

Enter the mermap

Brendan Jackman has been working on a more general address-space isolation (ASI) patch series for a while now. As a general rule, memory that does not appear within a given address space cannot be attacked by way of speculative-execution gadgets or more straightforward vulnerabilities. The kernel can already isolate its address space from user space to defend against Meltdown attacks, but this technique could be taken much farther. For example, many system calls could be at least partially implemented without access to most of the kernel's address space, with wider access only being granted for the code that strictly needs it.

Needless to say, any sort of practical address-space isolation will require removing memory from the direct map. As part of an effort to push this work forward, Jackman has posted a patch series to make the management of unmapped memory easier and more efficient.

Specifically, this series adds a new GFP flag, __GFP_UNMAPPED, that can be used to request unmapped memory from the page allocator. This allows the page allocator to manage these pages in a relatively efficient manner; they can be grouped together in a separate memory block, allowing them to be allocated and freed without changing the direct map every time (or fragmenting the direct map), and without the need for global TLB flushes. Allocating unmapped pages becomes a lot like allocating any other sort of page.

Except, of course, there are some complications. For example, another flag implemented by the page allocator is __GFP_ZERO, which requests that the pages be zero-filled. How can the kernel perform that zeroing without access to the memory involved? The answer is something that Jackman calls the "mermap", which is evidently a shortening of "ephemeral mapping". The pages in question are temporarily mapped into the kernel's address space, but only for the local CPU; they can then be zeroed, and there is no need for the global TLB flush that a wider mapping would require. An implication of this implementation, though, is that holding references to ephemerally mapped pages blocks migration for the running task, since it would lose access to those pages on any other CPU.

The page allocator needs to be able to track unmapped pages to be able to efficiently manage them. As Jackman points out in the series cover letter, the page allocator already has a mechanism for grouping pages by an attribute: the migration type, which is used to separate, for example, allocations of movable memory from those for unmovable memory. The migration type could thus be used to describe unmapped memory but, in current kernels, it can only track one attribute. A page might be both unmapped and unmovable, for example; the attributes are orthogonal to each other, and should be tracked separately. Migration types, as implemented, cannot support orthogonal attributes.

To address that shortcoming, Jackman's series adds the concept of a "freetype", described as "just a migratetype plus some flags". The current uses of migration types are, themselves, migrated to freetypes in a relatively large patch; work later in the series then adds the unmapped attribute and enables the page allocator to work with it, culminating in the implementation of __GFP_UNMAPPED.

This mechanism, once in place, would allow the guest_memfd machinery to more efficiently work with unmapped pages. It also "serves as a Trojan horse to get the page allocator into a state where adding ASI's features 'Should Be Easy'". None of that work appears in this series, though. What does appear is an update to memfd_secret() to use __GFP_UNMAPPED pages. This implementation is described as "hacky", though, since Jackman feels it could be optimized further.

Overall, __GFP_UNMAPPED is only in its second revision; that is early days for this sort of core page-allocator change. It is likely to require some work yet, before it can be considered for the mainline. This series will, though, certainly serve as fodder for discussion at the upcoming Linux Storage, Filesystem, Memory Management, and BPF Summit, to be held in early May, as will the guest_memfd work that it supports. Stay tuned.

Comments (1 posted)

Tracking when BPF programs may sleep

BPF programs can run in both sleepable and non-sleepable (atomic) contexts. Currently, sleepable BPF programs are not allowed to enter an atomic context. Puranjay Mohan has a new patch set that changes that. The patch set would let BPF programs called in sleepable contexts temporarily acquire locks that cause the programs to transition to an atomic context. BPF maintainer Alexei Starovoitov objected to parts of the implementation, however, so acceptance of the patch depends on whether Mohan is willing and able to straighten it out.

In an atomic context, kernel code is not allowed to do anything that would delay the continued execution of the kernel, such as waiting for block I/O or faulting a page back into memory. It is usually up to the kernel programmer (assisted by the kernel's various forms of instrumentation) to make sure that they don't accidentally call a function that can sleep in such a context. BPF programs were originally only capable of running in atomic contexts, and were therefore never allowed to call functions that could sleep. In 2020, the BPF verifier was extended to handle BPF programs that could sleep (by marking the entire program with a special flag), but such programs were not permitted to call many of the existing BPF interfaces, which assumed they could transition to an atomic context.

The main advantage of marking a BPF program as sleepable is that it is allowed to copy data from user space (which can sleep if the data needs to be faulted back into memory). Since that is generally useful, it would be nice if more BPF programs could be marked as sleepable; currently, many cannot because they need to take locks or acquire resources that are only available in an atomic context. Mohan's patch set allows for more fine-grained accounting of contexts in BPF programs by having the BPF verifier track whether the program is allowed to sleep on an instruction-by-instruction basis instead of globally for the whole program.

The BPF verifier tracks which kernel resources a BPF program has access to at a given point by looking for kfuncs (kernel functions to which BPF programs have access) that are annotated with the KF_ACQUIRE and KF_RELEASE markers. When a program calls a kfunc with the KF_ACQUIRE marker, the verifier tracks the return value and ensures that the program eventually passes it back to a compatible KF_RELEASE kfunc. A preparatory patch in Mohan's series adds support for these flags to BPF iterators. The main patches add another marker, KF_FORBID_FAULT, that tells the verifier that the program is not allowed to sleep as long as it holds a reference to the acquired resource. The intention is just to prevent page faults (hence the name), but the implementation forbids all kinds of sleeps (of which page faults are a subset). KF_FORBID_FAULT can only be used on kfuncs that are already marked with KF_ACQUIRE. Once the resource is released, the program is allowed to sleep again.

In his cover letter, Mohan gave an example of when this increased granularity might be useful. The task_vma iterator lets BPF programs iterate over a task's virtual memory areas (VMAs) — but doing anything with that information is difficult, because the iterator yields vm_area_struct structures. Those structures only remain valid as long as mmap_lock is held. Taking that lock creates a context in which page faults are forbidden, since page-fault handling may need to take the same lock. With his changes, BPF programs can now read from the VMA to obtain a user-space pointer, and then explicitly release the VMA structure to exit the atomic context and interact with user space. (Although, of course, the VMA in question could be unmapped by another CPU as soon as the lock is released, so the program needs to be able to cope with failure.)

    bpf_for_each(task_vma, vma, task, 0) {
        u64 start = vma->vm_start;

        /* Faulting forbidden, but VMA pointer access allowed */
        
        bpf_iter_task_vma_release(&___it);
        
        /* mmap_lock released, VMA pointer invalidated */
        /* Faulting (and sleeping) is fine here. */

        bpf_copy_from_user(&buf, sizeof(buf), (void *)start);
    }

An earlier version of the patch set called the new kfunc marker KF_FORBID_SLEEP, but Starovoitov had concerns about the name and semantics. KF_ACQUIRE is also used for things other than locks, particularly for reference-counted resources; Starovoitov suggested differentiating between KF_ACQUIRE (for reference counts) and KF_ACQUIRE_LOCK (for actual locks), and merging the semantics of KF_FORBID_SLEEP into the latter.

Mohan was fine with that suggestion, but Eduard Zingerman thought it might be worth exploring a more radical change. The verifier currently tracks four kinds of resources that all forbid sleeping, but with different acquire/release logic: active interrupts, active RCU locks, active preemption locks, and other active locks. The list of which kfunc corresponds to which kind of acquire/release logic is hard-coded; Zingerman suggested that, if Mohan was already going to make changes to the meaning of KF_ACQUIRE, it might be worthwhile to explore separate markers for these four categories to make the verifier's logic more generic.

Mohan said that exploring the possibility is now next on his agenda after the current patch set is done. For now, the name of the new annotation was changed to KF_FORBID_FAULT to indicate a narrower intended use. Mohan's follow-up work will look at refactoring the kfunc flags to allow for more precisely identifying the type of lock being used. That may take some time, however, because Starovoitov still has problems with the implementation of the latest version of the patch set. "Sorry. This is no go. We have to go back to the drawing board with the whole thing."

Starovoitov specifically objected to the way that Mohan's code repurposed the id field of the structure that the verifier uses to track stack slots containing references to iterators. There are already several slightly different uses of IDs across the verifier — something Amery Hung is working on cleaning up — and Starovoitov doesn't want to add another one that is specific to iterators when the patch set is supposed to add a generic mechanism.

Mohan has not yet responded to Starovoitov's concerns with a new version of the patch set, but he has submitted another patch set that changes the task_vma iterator to use per-VMA locking instead of mmap_lock. The iterator copies the VMA and drops the lock before providing the VMA to the BPF program, making the iterator usable in sleepable contexts. That patch set is still undergoing revision, but it could solve the specific problem of using task_vma iterators in a sleepable context. Hopefully the more general mechanism (and Zingerman's suggested cleanup) will still be a priority for Mohan afterward, even if the newer patch set meets his needs.

Comments (none posted)

LiteLLM on PyPI is compromised

This issue report describes a credential-stealing attack buried within LiteLLM 1.82.8 in the PyPI repository. It collects and exfiltrates a wide variety of information, including SSH keys, credentials for a number of cloud services, crypto wallets, and so on. Anybody who has installed this package has likely been compromised and needs to respond accordingly.

Update: see this futuresearch article for some more information. "The release contains a malicious .pth file (litellm_init.pth) that executes automatically on every Python process startup when litellm is installed in the environment."

Comments (3 posted)

Setting up a Tor Relay at National Taiwan Normal University (Tor Blog)

The Tor Blog has an interesting article about the non-technical side of setting up a Tor Relay. It documents how a computer science student at National Taiwan Normal University worked with the university system to set up a relay and provides a template for future attempts:

In Taiwan, anonymous networks do not lack technical documentation or ideological support. The real scarcity is experience from actually working through the real institutional system once. Especially in an environment where academic networks are highly centralized and outbound connectivity is tightly controlled, distributed anonymous infrastructure like Tor Relays is inherently difficult to sustain.

This implementation at National Taiwan Normal University was not meant to provide a final answer for anonymous networks. It was a concrete attempt made within real-world institutions. It may not immediately improve the performance or security of anonymous networks, and it was not intended to become a directly reproducible standard process. What it did achieve was leaving behind a clearly visible path of practice—one that can be understood, referenced, and built upon.

Comments (none posted)

Kernel release status

The current development kernel is 7.0-rc5, released on March 22. Linus said: "It looks like things are starting to calm down - rc5 is smaller than the previous rc's this merge window, although it still tracks a bit larger than rc5s historically do."

This development cycle has brought in 13,213 non-merge changesets from 2,166 developers, 404 of whom are first-time kernel contributors. As a result, 7.0 will be the new record holder for the most contributors ever (and possibly for the most first-timers as well). The history so far 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

Stable updates: 6.19.9 and 6.18.19 were released on March 19, followed by 6.19.10, 6.18.20, 6.12.78, 6.6.130, and 6.1.167 on March 25.

Comments (none posted)

b4 v0.15.0 released

Version 0.15.0 of the b4 patch-management tool is out. Highlights in this release include the b4 review workflow manager for maintainers (covered briefly in this article), b4 dig, which can find the original mailing-list submission behind a commit, three-way-merge support in b4 shazam, and more. See the release notes for details.

Full Story (comments: none)

Down: Debunking zswap and zram myths

Chris Down has posted a detailed look at how the kernel's zswap and zram subsystems work — and how they differ.

Most people think of zswap and zram simply as two different flavours of the same thing: compressed swap. At a surface level, that's correct – both compress pages that would otherwise end up on disk – but they make fundamentally different bets about how the kernel should handle memory pressure, and picking the wrong one for your situation can actively make things worse than having no swap at all

Comments (14 posted)

Google details new 24-hour process to sideload unverified Android apps (Ars Technica)

Ars Technica describes the ritual that will be required before a future Android device will deign to install apps from somewhere other than the Play Store. It is not for the impatient.

Here are the steps:

• Enable developer options by tapping the software build number in About Phone seven times
• In Settings > System, open Developer Options and scroll down to "Allow Unverified Packages."
• Flip the toggle and tap to confirm you are not being coerced
• Enter device unlock code
• Restart your device
• Wait 24 hours
• Return to the unverified packages menu at the end of the security delay
• Scroll past additional warnings and select either "Allow temporarily" (seven days) or "Allow indefinitely."
• Check the box confirming you understand the risks.
• You can now install unverified packages on the device by tapping the "Install anyway" option in the package manager.

Comments (255 posted)

Agama 19 released

Version 19 of the Agama installer for openSUSE and SUSE has been released. This release includes major changes in Agama's architectural design, organization of the web interface, and more.

We always wanted Agama to follow the schema [...] in which the core of the installer could be controlled through a consistent and simple programming interface (an API, in developers jargon). In that schema, the web-based user interface, the command-line tools and the unattended installation are built on top of that generic API.

But previous versions of Agama were full of quirks that didn't allow us to define an API that would match our quality standards as a solid foundation to build a simple but comprehensive installer. Agama 19 represents a quite significant architectural overhaul, needed to leave all those quirks behind and to define mechanisms that can be the cornerstone for any future development.

LWN last looked at Agama in September 2025.

Comments (3 posted)

Distributions quote of the week

I am neither pro team maintenance nor anti team maintenance. I am in favor of doing the things that make it more rewarding to volunteer to work on Debian. For some people, particularly new contributors, that means having easy onboarding, a robust team of people who can teach you how to do things and answer your questions, and a place to contribute where you can feel useful quickly. We should therefore have lots of those opportunities. For some people, the reward in Debian comes from going off to quietly work in one's corner or think hard about a problem and solve it the way that you want to solve it while minimizing the coordination that one has to do with other people. So we should also provide appropriate opportunities to do that.

In other words, if we want more volunteers, we should try to maximize volunteer payment. We pay our volunteers not in money, but with mission and purpose, community, and collaboration, but also autonomy, control, and independence. Different types of compensation matter more to different people.

Sometimes we have to force a particular way of doing things in Debian because we have a serious problem and we don't have another way of solving it. In those cases, we have to suck it up and live with the consequences, which may include losing volunteers. But we should do that carefully and selectively. I'm not sure pushing universal team maintenance on people who don't want it qualifies as careful or selective.

— Russ Allbery

Comments (none posted)

Firefox 149.0 released

Version 149.0 of the Firefox web browser has been released. Notable features in this release include a new split-view feature for viewing two web pages side-by-side, a built-in VPN for browser traffic only, and more.

Comments (7 posted)

GNOME 50 released

GNOME 50 has been released. Notable changes in this release include enhancements to the Orca screen-reader application, interface and performance improvements for GNOME's file manager (Files), a "massive set of stability and performance updates" for its display-handling technologies, and much more. See also the "What's new for developers" article that covers changes of interest to GNOME and GNOME application developers.

Comments (15 posted)

Krita 5.3.0 and 6.0.0 released

The Krita project has announced the release of Krita 5.3.0 and 6.0.0:

Krita 5.3/6.0 is the result of many years of work by the Krita developers. Some features have been rewritten from the ground up, others make their first appearance.

Enjoy the completely new text feature: on canvas editing, full opentype support, text flowing into shapes. It is now easier than ever to create vector-based panels for comic pages. Tools got extended: for instance, the fill tool now can close gaps. The liquify mode of the transform tool is much faster. There are new filters: a propagate colors filter and a reset transparent filter. Support for HDR painting has been improved. The recorder docker can now work in real time. There is improved support for file formats, like support for text objects in PSD files. And much, much, much more!

According to the announcement, the versions are almost functionally identical. However, the 6.0.0 release is the first based on Qt 6; it has more Wayland functionality but is considered experimental. It cautions that users should stick to 5.3.0 for real work. See the release notes for a full list of changes.

Comments (none posted)

LibreQoS v2.0 released

Version 2.0 of the LibreQoS traffic-management and network operations platform has been released.

This release makes LibreQoS easier to operate, easier to understand, and much more useful for day-to-day network work. Now users can see more of what is happening across the network, troubleshoot subscriber issues with better tools, and work from a much stronger local WebUI.

This release includes many capabilities that reflect ideas and direction long championed by our late colleague, Dave Täht.

Dave's work helped shape the understanding of bufferbloat and the importance of latency under load across the networking community. His influence continues to guide both LibreQoS and the broader effort to improve Internet quality.

The project has also announced the release of the LibreQoS Bufferbloat Test v2, also dedicated to Täht. It runs in a user's browser to look at "latency under load, jitter, loss, and what those things mean for the kinds of traffic people actually care about: browsing, streaming, video calls, audio calls, backups, and gaming".

Comments (none posted)

Radicle 1.7.0 released

Version 1.7.0 ("Daffodil") of the Radicle peer-to-peer, local-first code collaboration stack has been released. Some of the changes in this release include improved I/O usage, the ability to block nodes at the connection level, and clearer errors for rad id updates. See the release notes for a full list of changes and bug fixes.

Comments (none posted)

Samba 4.24.0 released

Version 4.24.0 of the Samba SMB filesystem implementation has been released. There are a number of significant changes, including audit support for authentication information, remote password management, a number of Kerberos improvements, asynchronous-I/O rate limiting, and more.

Full Story (comments: none)

Development quote of the week

If we allow people to use LLMs to write code for a given project/platform, experience in that platform will potentially atrophy or under develop as contributors increasingly rely on out sourcing their applicable skills and decisions to "AI".

Even if you believe out sourcing the minutia of coding is a net positive, the "enshitification" principal in general should give you pause; as soon as the net developer skill for a project has degraded to a point of reliance, even somewhat, I think we can be confident those AI tools will NOT get less expensive.

I'd rather be independently less productive, than dependent on some MegaCorp(TM)'s good will to rent us back access to our brains at a fair price.

— Tyler Anderson

Comments (none posted)

CFP Deadlines: March 26, 2026 to May 25, 2026

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

Deadline	Event Dates	Event	Location
March 29	May 29	Yocto Project Developer Day	Nice, France
March 31	June 6	Hong Kong Open Source Conference	Hong Kong, Hong Kong
April 15	May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
April 20	July 20 July 25	DebConf 26	Santa Fe, Argentina
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

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

Events: March 26, 2026 to May 25, 2026

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

Date(s)	Event	Location
March 23 March 26	KubeCon + CloudNativeCon Europe	Amsterdam, Netherlands
March 28	Central Pennsylvania Open Source Conference	Lancaster, Pennsylvania, US
March 28 March 29	Chemnitz Linux Days	Chemnitz, Germany
March 28 March 29	InstallFest 2026	Prague, Czechia
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

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

Alert summary March 19, 2026 to March 25, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:4898	9	capstone	2026-03-20
AlmaLinux	ALSA-2026:5113	8	gimp:2.8	2026-03-20
AlmaLinux	ALSA-2026:4772	8	glibc	2026-03-19
AlmaLinux	ALSA-2026:4649	10	grub2	2026-03-20
AlmaLinux	ALSA-2026:4760	9	grub2	2026-03-20
AlmaLinux	ALSA-2026:4723	10	kernel	2026-03-20
AlmaLinux	ALSA-2026:4759	9	kernel	2026-03-20
AlmaLinux	ALSA-2026:5063	10	libarchive	2026-03-20
AlmaLinux	ALSA-2026:5080	9	libarchive	2026-03-20
AlmaLinux	ALSA-2026:4728	8	libpng	2026-03-19
AlmaLinux	ALSA-2026:4629	10	libvpx	2026-03-20
AlmaLinux	ALSA-2026:4828	9	mysql	2026-03-20
AlmaLinux	ALSA-2026:4705	10	nginx	2026-03-20
AlmaLinux	ALSA-2026:4717	10	opencryptoki	2026-03-20
AlmaLinux	ALSA-2026:4473	8	python3.11	2026-03-19
AlmaLinux	ALSA-2026:4713	10	python3.12	2026-03-20
AlmaLinux	ALSA-2026:4715	10	vim	2026-03-20
AlmaLinux	ALSA-2026:5146	10	yggdrasil	2026-03-20
AlmaLinux	ALSA-2026:5145	10	yggdrasil-worker-package-manager	2026-03-20
Debian	DSA-6171-1	stable	chromium	2026-03-20
Debian	DSA-6177-1	stable	chromium	2026-03-25
Debian	DLA-4503-1	LTS	evolution-data-server	2026-03-19
Debian	DSA-6173-1	stable	freeciv	2026-03-21
Debian	DSA-6168-1	stable	freetype	2026-03-18
Debian	DSA-6169-1	stable	imagemagick	2026-03-19
Debian	DLA-4504-1	LTS	libvirt	2026-03-20
Debian	DSA-6175-1	stable	libyaml-syck-perl	2026-03-22
Debian	DLA-4506-1	LTS	mapserver	2026-03-23
Debian	DLA-4505-1	LTS	ruby-rack	2026-03-23
Debian	DSA-6170-1	stable	snapd	2026-03-19
Debian	DSA-6174-1	stable	spip	2026-03-22
Debian	DSA-6176-1	stable	strongswan	2026-03-23
Debian	DLA-4507-1	LTS	vlc	2026-03-24
Debian	DSA-6172-1	stable	webkit2gtk	2026-03-21
Fedora	FEDORA-2026-62f9125c65	F44	aqualung	2026-03-19
Fedora	FEDORA-2026-2fef29d32a	F43	bpfman	2026-03-20
Fedora	FEDORA-2026-7ffd130a98	F42	chromium	2026-03-22
Fedora	FEDORA-2026-ae897eb928	F43	chromium	2026-03-25
Fedora	FEDORA-2026-b7d2936de3	F44	chromium	2026-03-20
Fedora	FEDORA-2026-920df14fb5	F44	chromium	2026-03-25
Fedora	FEDORA-2026-46d93351cd	F43	cmake	2026-03-24
Fedora	FEDORA-2026-7ed700921c	F42	containernetworking-plugins	2026-03-25
Fedora	FEDORA-2026-8ee0451243	F43	containernetworking-plugins	2026-03-25
Fedora	FEDORA-2026-d6b4b4df31	F44	containernetworking-plugins	2026-03-25
Fedora	FEDORA-2026-6ed9c65eaf	F42	cpp-httplib	2026-03-21
Fedora	FEDORA-2026-c2049f7220	F43	cpp-httplib	2026-03-21
Fedora	FEDORA-2026-2c2afa9f9e	F44	cpp-httplib	2026-03-20
Fedora	FEDORA-2026-854e553ffa	F43	dotnet10.0	2026-03-20
Fedora	FEDORA-2026-c260342365	F43	giflib	2026-03-24
Fedora	FEDORA-2026-5637749c07	F43	glib2	2026-03-21
Fedora	FEDORA-2026-aeb63d9dfb	F42	kiss-fft	2026-03-19
Fedora	FEDORA-2026-291357abab	F43	kiss-fft	2026-03-19
Fedora	FEDORA-2026-ecc754cb95	F44	kiss-fft	2026-03-19
Fedora	FEDORA-2026-f029d04054	F43	libsoup3	2026-03-21
Fedora	FEDORA-2026-4450956be5	F43	libtasn1	2026-03-19
Fedora	FEDORA-2026-ba6641558a	F43	localsearch	2026-03-23
Fedora	FEDORA-2026-62f9125c65	F44	mac	2026-03-19
Fedora	FEDORA-2026-390ce5262d	F44	musescore	2026-03-25
Fedora	FEDORA-2026-39819a3d62	F42	openssh	2026-03-21
Fedora	FEDORA-2026-bab4aa5da7	F43	openssh	2026-03-20
Fedora	FEDORA-2026-62fb46caac	F44	openssh	2026-03-22
Fedora	FEDORA-2026-d4bdf7108e	F44	polkit	2026-03-20
Fedora	FEDORA-2026-9e5037f4e6	F42	python-diskcache	2026-03-24
Fedora	FEDORA-2026-319d85836c	F43	python-diskcache	2026-03-24
Fedora	FEDORA-2026-56264d0a56	F44	python-diskcache	2026-03-24
Fedora	FEDORA-2026-5c75eb75d1	F43	python-multipart	2026-03-25
Fedora	FEDORA-2026-dec8f790f7	F42	python-scitokens	2026-03-22
Fedora	FEDORA-2026-727b73bfa0	F43	python-scitokens	2026-03-22
Fedora	FEDORA-2026-86ad7d8a1a	F44	python-scitokens	2026-03-22
Fedora	FEDORA-2026-0f099ed388	F42	python-ujson	2026-03-22
Fedora	FEDORA-2026-bf741e26e4	F43	python-ujson	2026-03-22
Fedora	FEDORA-2026-5725d633ec	F44	python-ujson	2026-03-22
Fedora	FEDORA-2026-cb86172c17	F44	python3.6	2026-03-21
Fedora	FEDORA-2026-a6d1791c49	F42	scitokens-cpp	2026-03-23
Fedora	FEDORA-2026-52c99ecf64	F43	scitokens-cpp	2026-03-23
Fedora	FEDORA-2026-176625c3fc	F44	scitokens-cpp	2026-03-23
Fedora	FEDORA-2026-c47c476fdd	F42	uxplay	2026-03-21
Fedora	FEDORA-2026-a00f52ac25	F43	uxplay	2026-03-21
Fedora	FEDORA-2026-1885157e34	F42	vim	2026-03-19
Fedora	FEDORA-2026-f5d072060b	F44	vim	2026-03-20
Fedora	FEDORA-2026-675dd9b166	F42	wordpress	2026-03-21
Fedora	FEDORA-2026-5774d46593	F43	wordpress	2026-03-21
Fedora	FEDORA-2026-bf984d4931	F44	wordpress	2026-03-21
Fedora	FEDORA-2026-8ae1a1c3d7	F43	xen	2026-03-23
Mageia	MGASA-2026-0061	9	expat	2026-03-20
Mageia	MGASA-2026-0060	9	graphicsmagick, imagemagick	2026-03-19
Mageia	MGASA-2026-0059	9	openssh	2026-03-19
Mageia	MGASA-2026-0063	9	perl-XML-Parser	2026-03-24
Mageia	MGASA-2026-0058	9	perl-YAML-Syck	2026-03-19
Mageia	MGASA-2026-0065	9	roundcubemail	2026-03-24
Mageia	MGASA-2026-0066	9	trilead-ssh2	2026-03-24
Mageia	MGASA-2026-0062	9	vim	2026-03-24
Mageia	MGASA-2026-0064	9	webkit2	2026-03-24
Oracle	ELSA-2026-5513	OL8	389-ds:1.4	2026-03-24
Oracle	ELSA-2026-4898	OL9	capstone	2026-03-19
Oracle	ELSA-2026-5113	OL8	gimp:2.8	2026-03-24
Oracle	ELSA-2026-4772	OL8	glibc	2026-03-24
Oracle	ELSA-2026-5585	OL8	gnutls	2026-03-24
Oracle	ELSA-2026-4648	OL8	grub2	2026-03-19
Oracle	ELSA-2026-4760	OL9	grub2	2026-03-19
Oracle	ELSA-2026-3685	OL7	kernel	2026-03-24
Oracle	ELSA-2026-4759	OL9	kernel	2026-03-19
Oracle	ELSA-2026-50160	OL9	kernel	2026-03-24
Oracle	ELSA-2026-5063	OL10	libarchive	2026-03-24
Oracle	ELSA-2026-5080	OL9	libarchive	2026-03-24
Oracle	ELSA-2026-4828	OL9	mysql	2026-03-19
Oracle	ELSA-2026-5581	OL8	nginx:1.24	2026-03-24
Oracle	ELSA-2026-5587	OL8	opencryptoki	2026-03-24
Oracle	ELSA-2026-5603	OL9	opencryptoki	2026-03-24
Oracle	ELSA-2026-4148	OL7	python-pyasn1	2026-03-19
Oracle	ELSA-2026-5588	OL8	python3	2026-03-24
Oracle	ELSA-2026-50160		uek-kernel	2026-03-24
Oracle	ELSA-2026-5602	OL9	vim	2026-03-24
Oracle	ELSA-2026-5146	OL10	yggdrasil	2026-03-24
Oracle	ELSA-2026-5145	OL10	yggdrasil-worker-package-manager	2026-03-24
Red Hat	RHSA-2026:4693-01	EL8.8	container-tools:rhel8	2026-03-20
Red Hat	RHSA-2026:3842-01	EL9	delve	2026-03-25
Red Hat	RHSA-2026:5063-01	EL10	libarchive	2026-03-19
Red Hat	RHSA-2026:5080-01	EL9	libarchive	2026-03-19
Red Hat	RHSA-2026:5461-01	EL8.4	osbuild-composer	2026-03-24
Red Hat	RHSA-2026:4753-01	EL8.8	osbuild-composer	2026-03-19
Red Hat	RHSA-2026:5533-01	EL9.0	osbuild-composer	2026-03-24
Red Hat	RHSA-2026:5327-01	EL9.2	osbuild-composer	2026-03-23
Red Hat	RHSA-2026:5544-01	EL9.6	osbuild-composer	2026-03-24
Red Hat	RHSA-2026:4892-01	EL10	rhc	2026-03-19
Red Hat	RHSA-2026:4907-01	EL10.0	rhc	2026-03-19
Red Hat	RHSA-2026:4952-01	EL8	rhc	2026-03-19
Red Hat	RHSA-2026:5030-01	EL8.4	rhc	2026-03-19
Red Hat	RHSA-2026:5031-01	EL8.6	rhc	2026-03-19
Red Hat	RHSA-2026:5022-01	EL8.8	rhc	2026-03-19
Red Hat	RHSA-2026:4901-01	EL9	rhc	2026-03-19
Red Hat	RHSA-2026:5079-01	EL9.0	rhc	2026-03-19
Red Hat	RHSA-2026:5076-01	EL9.2	rhc	2026-03-20
Red Hat	RHSA-2026:5078-01	EL9.4	rhc	2026-03-20
Red Hat	RHSA-2026:5077-01	EL9.6	rhc	2026-03-20
Red Hat	RHSA-2026:5234-01	EL9.2	skopeo	2026-03-25
Red Hat	RHSA-2026:5146-01	EL10	yggdrasil	2026-03-20
Red Hat	RHSA-2026:5145-01	EL10	yggdrasil-worker-package-manager	2026-03-20
Slackware	SSA:2026-077-01		expat	2026-03-18
Slackware	SSA:2026-083-02		mozilla	2026-03-24
Slackware	SSA:2026-083-01		mozilla	2026-03-24
SUSE	SUSE-SU-2026:0940-1	SLE15	Announcement ID: SUSE-SU-2026:0940-1 Release Date: 2026-03-20T13:41:23Z Rating: important References:	2026-03-20
SUSE	SUSE-SU-2026:0941-1	SLE15	Announcement ID: SUSE-SU-2026:0941-1 Release Date: 2026-03-20T13:41:30Z Rating: important References:	2026-03-20
SUSE	SUSE-SU-2026:0943-1	SLE15	Announcement ID: SUSE-SU-2026:0943-1 Release Date: 2026-03-20T13:41:33Z Rating: important References:	2026-03-20
SUSE	SUSE-SU-2026:0944-1	SLE15	Announcement ID: SUSE-SU-2026:0944-1 Release Date: 2026-03-20T13:41:37Z Rating: important References:	2026-03-20
SUSE	SUSE-SU-2026:0945-1	SLE15	Announcement ID: SUSE-SU-2026:0945-1 Release Date: 2026-03-20T13:41:40Z Rating: important References:	2026-03-20
SUSE	SUSE-SU-2026:0938-1	SLE15 oS15.6	GraphicsMagick	2026-03-20
SUSE	openSUSE-SU-2026:10391-1	TW	GraphicsMagick	2026-03-20
SUSE	openSUSE-SU-2026:10399-1	TW	GraphicsMagick	2026-03-23
SUSE	SUSE-SU-2026:20696-1	SLE-m6.0	ca-certificates-mozilla	2026-03-18
SUSE	SUSE-SU-2026:20652-1	SLE-m6.1	ca-certificates-mozilla	2026-03-18
SUSE	openSUSE-SU-2026:10382-1	TW	cargo1.92	2026-03-19
SUSE	openSUSE-SU-2026:10383-1	TW	cargo1.93	2026-03-19
SUSE	openSUSE-SU-2026:10376-1	TW	chromedriver	2026-03-19
SUSE	openSUSE-SU-2026:20372-1	oS16.0	chromium	2026-03-18
SUSE	openSUSE-SU-2026:0094-1	osB15	chromium	2026-03-23
SUSE	openSUSE-SU-2026:0093-1	osB15	chromium	2026-03-23
SUSE	SUSE-SU-2026:20653-1	SLE-m6.1	cockpit	2026-03-18
SUSE	SUSE-SU-2026:20695-1	SLE-m6.0	cockpit-machines	2026-03-18
SUSE	SUSE-SU-2026:20650-1	SLE-m6.1	cockpit-machines	2026-03-18
SUSE	SUSE-SU-2026:20688-1	SLE-m6.2	cockpit-podman	2026-03-18
SUSE	openSUSE-SU-2026:10375-1	TW	coturn	2026-03-19
SUSE	SUSE-SU-2026:20722-1	SLE-m6.0	curl	2026-03-19
SUSE	SUSE-SU-2026:20668-1	SLE-m6.1	curl	2026-03-18
SUSE	SUSE-SU-2026:20760-1	SLE-m6.2	curl	2026-03-24
SUSE	SUSE-SU-2026:0921-1	SLE12	curl	2026-03-18
SUSE	openSUSE-SU-2026:10371-1	TW	curl	2026-03-18
SUSE	SUSE-SU-2026:20694-1	SLE-m6.0	docker	2026-03-18
SUSE	SUSE-SU-2026:20651-1	SLE-m6.1	docker	2026-03-18
SUSE	SUSE-SU-2026:0950-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	docker	2026-03-23
SUSE	SUSE-SU-2026:20656-1	SLE-m6.1	docker-compose	2026-03-18
SUSE	SUSE-SU-2026:0972-1	SLE15 oS15.6	docker-stable	2026-03-23
SUSE	openSUSE-SU-2026:20366-1	oS16.0	docker-stable	2026-03-18
SUSE	SUSE-SU-2026:20795-1	SLE-m6.0	dpkg	2026-03-24
SUSE	SUSE-SU-2026:20766-1	SLE-m6.1	dpkg	2026-03-24
SUSE	openSUSE-SU-2026:10401-1	TW	freeciv	2026-03-23
SUSE	SUSE-SU-2026:0969-1	SLE12	freerdp	2026-03-23
SUSE	SUSE-SU-2026:0933-1	SLE15 oS15.6	freerdp	2026-03-19
SUSE	SUSE-SU-2026:0968-1	SLE15	freerdp2	2026-03-23
SUSE	SUSE-SU-2026:20730-1	SLE-m6.0	freetype2	2026-03-23
SUSE	SUSE-SU-2026:20726-1	SLE-m6.0 SLE-m6.1	freetype2	2026-03-23
SUSE	SUSE-SU-2026:20708-1	SLE-m6.0	gnutls	2026-03-18
SUSE	SUSE-SU-2026:20654-1	SLE-m6.1	gnutls	2026-03-18
SUSE	SUSE-SU-2026:0947-1	SLE15	go1.25-openssl	2026-03-20
SUSE	SUSE-SU-2026:0977-1	SLE15 oS15.6	go1.25-openssl	2026-03-24
SUSE	SUSE-SU-2026:0993-1	SLE15	go1.26-openssl	2026-03-24
SUSE	SUSE-SU-2026:0976-1	SLE15 oS15.6	go1.26-openssl	2026-03-24
SUSE	SUSE-SU-2026:0998-1	SLE15 oS15.6	gstreamer-plugins-ugly	2026-03-24
SUSE	SUSE-SU-2026:20686-1	SLE-m6.2	gstreamer-rtsp-server, gstreamer-plugins-ugly, gstreamer- plugins-rs, gstreamer-plugins-libav, gstreamer-plugins-good, gstreamer-plugins- base, gstreamer-plugins-bad, gstreamer-docs, gstreamer-devtools, gstreamer	2026-03-18
SUSE	SUSE-SU-2026:0923-1	SLE15 oS15.4	gvfs	2026-03-18
SUSE	SUSE-SU-2026:0960-1	SLE15 oS15.6	gvfs	2026-03-23
SUSE	SUSE-SU-2026:20762-1	SLE-m6.2	harfbuzz	2026-03-24
SUSE	SUSE-SU-2026:20685-1	SLE-m6.2	helm	2026-03-18
SUSE	SUSE-SU-2026:0948-1	SLE15 SLE-m5.5 oS15.6	helm	2026-03-23
SUSE	SUSE-SU-2026:0931-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	jq	2026-03-19
SUSE	SUSE-SU-2026:0984-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-03-24
SUSE	SUSE-SU-2026:20720-1	SLE-m6.0	kernel	2026-03-19
SUSE	SUSE-SU-2026:20713-1	SLE-m6.0	kernel	2026-03-19
SUSE	SUSE-SU-2026:20819-1	SLE-m6.0	kernel	2026-03-24
SUSE	SUSE-SU-2026:20794-1	SLE-m6.0	kernel	2026-03-24
SUSE	SUSE-SU-2026:20711-1	SLE-m6.0 SLE-m6.1	kernel	2026-03-18
SUSE	SUSE-SU-2026:20667-1	SLE-m6.0 SLE-m6.1	kernel	2026-03-18
SUSE	SUSE-SU-2026:20772-1	SLE-m6.0 SLE-m6.1	kernel	2026-03-24
SUSE	SUSE-SU-2026:0962-1	SLE15	kernel	2026-03-23
SUSE	SUSE-SU-2026:0961-1	SLE15 SLE-m5.2	kernel	2026-03-23
SUSE	SUSE-SU-2026:0928-1	SLE15 SLE-m5.2 oS15.3	kernel	2026-03-18
SUSE	SUSE-SU-2026:0930-1	SLE12	krb5-appl	2026-03-19
SUSE	openSUSE-SU-2026:20374-1	oS16.0	krb5-appl	2026-03-18
SUSE	openSUSE-SU-2026:0088-1	osB15	krb5-appl	2026-03-18
SUSE	openSUSE-SU-2026:10406-1	TW	lemon	2026-03-23
SUSE	SUSE-SU-2026:20750-1	SLE-m6.2	libpng16	2026-03-24
SUSE	SUSE-SU-2026:20755-1	SLE-m6.2	librsvg	2026-03-24
SUSE	SUSE-SU-2026:20756-1	SLE-m6.2	libsodium	2026-03-24
SUSE	SUSE-SU-2026:20727-1	SLE-m6.0	libsoup	2026-03-23
SUSE	SUSE-SU-2026:20649-1	SLE-m6.1	libsoup	2026-03-18
SUSE	SUSE-SU-2026:20737-1	SLE-m6.1	libsoup	2026-03-23
SUSE	SUSE-SU-2026:20752-1	SLE-m6.2	libsoup	2026-03-24
SUSE	SUSE-SU-2026:0936-1	SLE-m5.2	libssh	2026-03-20
SUSE	SUSE-SU-2026:20767-1	SLE-m6.1	libssh	2026-03-24
SUSE	SUSE-SU-2026:20707-1	SLE-m6.0	libxslt, libxml2	2026-03-18
SUSE	SUSE-SU-2026:20657-1	SLE-m6.1	libxslt, libxml2	2026-03-18
SUSE	openSUSE-SU-2026:10388-1	TW	mumble	2026-03-20
SUSE	SUSE-SU-2026:20751-1	SLE-m6.2	net-snmp	2026-03-24
SUSE	SUSE-SU-2026:20662-1	SLE-m6.1	openssh	2026-03-18
SUSE	SUSE-SU-2026:20769-1	SLE-m6.1	ovmf	2026-03-24
SUSE	SUSE-SU-2026:0935-1	oS15.4	php-composer2	2026-03-20
SUSE	SUSE-SU-2026:20753-1	SLE-m6.2	protobuf	2026-03-24
SUSE	SUSE-SU-2026:0975-1	SLE15 oS15.6	python-Authlib	2026-03-24
SUSE	SUSE-SU-2026:20706-1	SLE-m6.0	python-cryptography	2026-03-18
SUSE	SUSE-SU-2026:20655-1	SLE-m6.1	python-cryptography	2026-03-18
SUSE	openSUSE-SU-2026:20373-1	oS16.0	python-django	2026-03-18
SUSE	SUSE-SU-2026:20748-1	SLE-m6.2	python-maturin	2026-03-24
SUSE	SUSE-SU-2026:20821-1	SLE-m6.0	python-pyasn1	2026-03-25
SUSE	openSUSE-SU-2026:20375-1	oS16.0	python-pypdf2	2026-03-18
SUSE	openSUSE-SU-2026:0086-1	osB15	python-simpleeval	2026-03-18
SUSE	SUSE-SU-2026:20797-1	SLE-m6.0	python-tornado6	2026-03-24
SUSE	SUSE-SU-2026:20770-1	SLE-m6.1	python-tornado6	2026-03-24
SUSE	SUSE-SU-2026:20761-1	SLE-m6.2	python-tornado6	2026-03-24
SUSE	openSUSE-SU-2026:10404-1	TW	python310	2026-03-23
SUSE	openSUSE-SU-2026:10402-1	TW	python311-PyPDF2	2026-03-23
SUSE	SUSE-SU-2026:20710-1	SLE-m6.0	python311	2026-03-18
SUSE	SUSE-SU-2026:20796-1	SLE-m6.0	python311	2026-03-24
SUSE	SUSE-SU-2026:20665-1	SLE-m6.1	python311	2026-03-18
SUSE	SUSE-SU-2026:20768-1	SLE-m6.1	python311	2026-03-24
SUSE	openSUSE-SU-2026:10398-1	TW	python311	2026-03-21
SUSE	openSUSE-SU-2026:10393-1	TW	python311-pyasn1	2026-03-20
SUSE	openSUSE-SU-2026:10403-1	TW	python311-pypdf	2026-03-23
SUSE	openSUSE-SU-2026:10380-1	TW	python311-uv	2026-03-19
SUSE	openSUSE-SU-2026:10377-1	TW	python312	2026-03-19
SUSE	openSUSE-SU-2026:10394-1	TW	python313	2026-03-21
SUSE	openSUSE-SU-2026:10405-1	TW	python314	2026-03-23
SUSE	SUSE-SU-2026:0971-1	oS15.3 oS15.6	python39	2026-03-23
SUSE	SUSE-SU-2026:20716-1	SLE-m6.0	qemu	2026-03-19
SUSE	SUSE-SU-2026:20666-1	SLE-m6.1	qemu	2026-03-18
SUSE	SUSE-SU-2026:20693-1	SLE-m6.2	qemu	2026-03-18
SUSE	openSUSE-SU-2026:10365-1	TW	ruby4.0-rubygem-sprockets	2026-03-18
SUSE	openSUSE-SU-2026:10364-1	TW	ruby4.0-rubygem-sprockets	2026-03-18
SUSE	openSUSE-SU-2026:10366-1	TW	ruby4.0-rubygem-thor	2026-03-18
SUSE	openSUSE-SU-2026:10367-1	TW	ruby4.0-rubygem-web-console	2026-03-18
SUSE	openSUSE-SU-2026:10368-1	TW	ruby4.0-rubygem-websocket-extensions	2026-03-18
SUSE	SUSE-SU-2026:0949-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.6	runc	2026-03-23
SUSE	SUSE-SU-2026:20744-1	SLE-m6.2	rust-keylime	2026-03-24
SUSE	SUSE-SU-2026:20820-1	SLE-m6.0	salt	2026-03-25
SUSE	openSUSE-SU-2026:10369-1	TW	skaffold	2026-03-18
SUSE	openSUSE-SU-2026:10370-1	TW	smb4k	2026-03-18
SUSE	SUSE-SU-2026:20771-1	SLE-m6.1	sqlite3	2026-03-24
SUSE	SUSE-SU-2026:0955-1	SLE12	sqlite3	2026-03-23
SUSE	SUSE-SU-2026:0980-1	SLE15	strongswan	2026-03-24
SUSE	SUSE-SU-2026:0981-1	SLE15 oS15.4	strongswan	2026-03-24
SUSE	SUSE-SU-2026:0978-1	SLE15 oS15.5	strongswan	2026-03-24
SUSE	SUSE-SU-2026:0979-1	SLE15 oS15.6	strongswan	2026-03-24
SUSE	SUSE-SU-2026:20823-1	SLE-m6.0	systemd	2026-03-25
SUSE	SUSE-SU-2026:20822-1	SLE-m6.0	systemd	2026-03-25
SUSE	SUSE-SU-2026:0991-1	SLE12	systemd	2026-03-24
SUSE	openSUSE-SU-2026:10390-1	TW	tempo-cli	2026-03-20
SUSE	SUSE-SU-2026:0922-1	SLE12	tomcat	2026-03-18
SUSE	SUSE-SU-2026:0932-1	SLE15 oS15.6	tomcat	2026-03-19
SUSE	SUSE-SU-2026:20682-1	SLE-m6.1	ucode-intel	2026-03-18
SUSE	SUSE-SU-2026:20758-1	SLE-m6.2	ucode-intel	2026-03-24
SUSE	SUSE-SU-2026:0987-1	SLE-m5.2 oS15.3	util-linux	2026-03-24
SUSE	SUSE-SU-2026:0982-1	SLE-m5.3 SLE-m5.4 oS15.4	util-linux	2026-03-24
SUSE	SUSE-SU-2026:20714-1	SLE-m6.0	util-linux	2026-03-19
SUSE	SUSE-SU-2026:20664-1	SLE-m6.1	util-linux	2026-03-18
SUSE	SUSE-SU-2026:20717-1	SLE-m6.0	vim	2026-03-19
SUSE	SUSE-SU-2026:20712-1	SLE-m6.0	vim	2026-03-19
SUSE	SUSE-SU-2026:20740-1	SLE-m6.0	vim	2026-03-23
SUSE	SUSE-SU-2026:20735-1	SLE-m6.0	vim	2026-03-23
SUSE	SUSE-SU-2026:20732-1	SLE-m6.0	vim	2026-03-23
SUSE	SUSE-SU-2026:20741-1	SLE-m6.1	vim	2026-03-23
SUSE	SUSE-SU-2026:20738-1	SLE-m6.1	vim	2026-03-23
SUSE	SUSE-SU-2026:20765-1	SLE-m6.2	vim	2026-03-24
SUSE	SUSE-SU-2026:20759-1	SLE-m6.2	vim	2026-03-24
SUSE	SUSE-SU-2026:20723-1	SLE-m6.0	virtiofsd	2026-03-19
SUSE	SUSE-SU-2026:20661-1	SLE-m6.1	virtiofsd	2026-03-18
SUSE	SUSE-SU-2026:20684-1	SLE-m6.2	virtiofsd	2026-03-18
SUSE	SUSE-SU-2026:20709-1	SLE-m6.0	zlib	2026-03-18
SUSE	SUSE-SU-2026:20659-1	SLE-m6.1	zlib	2026-03-18
Ubuntu	USN-8108-1	16.04 18.04 20.04 22.04 24.04	bouncycastle	2026-03-18
Ubuntu	USN-8109-1	14.04 16.04 18.04 24.04	debian-goodies	2026-03-23
Ubuntu	USN-8103-1	16.04 18.04 20.04 22.04 24.04 25.10	exiv2	2026-03-18
Ubuntu	USN-8103-2	20.04 22.04 24.04 25.10	exiv2	2026-03-19
Ubuntu	USN-8105-1	24.04 25.10	freerdp3	2026-03-18
Ubuntu	USN-8105-2	24.04 25.10	freerdp3	2026-03-19
Ubuntu	USN-8111-1	22.04 24.04 25.10	glance	2026-03-19
Ubuntu	USN-8114-1	22.04 24.04 25.10	gvfs	2026-03-23
Ubuntu	USN-8110-1	14.04 16.04 18.04 20.04 22.04 24.04	libnet-cidr-perl	2026-03-23
Ubuntu	USN-8112-1	16.04 18.04	linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe, linux-kvm, linux-oracle	2026-03-20
Ubuntu	USN-8098-3	18.04 20.04	linux-aws, linux-aws-5.4, linux-gcp-5.4, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp	2026-03-18
Ubuntu	USN-8095-4	22.04	linux-aws-6.8	2026-03-23
Ubuntu	USN-8112-2	18.04	linux-aws-fips, linux-fips, linux-gcp-fips	2026-03-20
Ubuntu	USN-8107-1	20.04	linux-aws-fips	2026-03-18
Ubuntu	USN-8121-1	20.04	linux-aws-fips	2026-03-24
Ubuntu	USN-8112-3	16.04 18.04	linux-azure, linux-azure-4.15	2026-03-24
Ubuntu	USN-8112-5	14.04	linux-azure	2026-03-24
Ubuntu	USN-8098-7	20.04	linux-azure	2026-03-25
Ubuntu	USN-8112-4	18.04	linux-azure-fips	2026-03-24
Ubuntu	USN-8098-8	20.04	linux-azure-fips	2026-03-25
Ubuntu	USN-8059-9	24.04	linux-azure-fips	2026-03-24
Ubuntu	USN-8098-6	20.04	linux-fips, linux-gcp-fips	2026-03-24
Ubuntu	USN-8098-4	18.04 20.04	linux-hwe-5.4, linux-ibm	2026-03-24
Ubuntu	USN-8116-1	22.04	linux-intel-iot-realtime	2026-03-23
Ubuntu	USN-8098-5	20.04	linux-iot, linux-kvm	2026-03-24
Ubuntu	USN-8096-5	22.04	linux-nvidia-tegra-igx	2026-03-23
Ubuntu	USN-8094-3	24.04	linux-realtime-6.17	2026-03-23
Ubuntu	USN-8122-1	16.04 18.04	pjproject	2026-03-24
Ubuntu	USN-8115-1	22.04 24.04 25.10	pyopenssl	2026-03-23
Ubuntu	USN-8018-3	14.04 16.04 18.04 20.04 22.04	python2.7	2026-03-19
Ubuntu	USN-8120-1	24.04	redis	2026-03-24
Ubuntu	USN-8097-2	20.04	roundcube	2026-03-18
Ubuntu	USN-8118-1	20.04	rust-sized-chunks	2026-03-23
Ubuntu	USN-8117-1	22.04 24.04 25.10	strongswan	2026-03-23
Ubuntu	USN-8119-2	14.04 16.04 18.04 20.04	systemd	2026-03-24
Ubuntu	USN-8119-1	22.04 24.04 25.10	systemd	2026-03-24
Ubuntu	USN-8113-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10	tiff	2026-03-23
Ubuntu	USN-8106-1	24.04 25.10	valkey	2026-03-18

Full Story (comments: none)