openSUSE News

When the Code Stays Clean and Trust Collapses Anyway

admin@opensuse.org (Hans de Raad) — Fri, 26 Jun 2026 14:00:00 +0000

Why Europe’s third way needs sovereign open-source assurance, and what the openSUSE community, the SUSE ecosystem and the businesses built on them should do about it

Accompanying article to the openSUSE Conference 2026 keynote by Hans de Raad (OpenNovations) - “Open Source Won Distribution. Now It Must Win Assurance.”

Most writing about European digital policy starts in Brussels. This article starts in a package manager, because that is where the abstraction becomes real and where the openSUSE community already lives.

In May 2026, a project called GSD, short for “Get Shit Done,” became one of the more instructive open-source episodes of the agentic-AI era. It is worth dwelling on, not because it was the most dramatic security event of the year, but because it was the clearest. GSD was a genuinely useful tool. It was an open-source framework that sat on top of Claude Code and around a dozen other AI coding runtimes and solved a real and widely felt problem: the degradation in quality that sets in when an AI coding session fills its context window, the phenomenon its own documentation called context rot. It worked by breaking development into phases and running each in a fresh agent context, and by early May 2026 it had earned roughly 59,000 stars on GitHub, 138 contributors, and adoption across the kind of teams who do serious work with AI assistance. People installed it because it helped, which is the only reason anyone installs anything.

Then the trust around it collapsed. The original maintainer became unreachable on 1 April 2026, the associated social accounts were deleted, and a Solana-based token tied to the project, the $GSD token, was publicly linked to a rug pull around 21 to 22 May 2026. The community responded within a day, forking the codebase to a continuation called get-shit-done-redux, preserving the MIT-licensed code with all of its branches and tags, stripping the token and social references, and republishing under a new package scope. The original repository was locked. None of this is in dispute; it is documented across the project’s own pages, the community fork, and the coverage that followed.

What makes GSD instructive is what the security review found, and what it did not. The fork team published its own security audit, and an independent reviewer went through the same code. Both agreed on the headline: there was no active backdoor and no exfiltration payload in the reviewed source, and the listed security tests passed. If your mental model of open-source risk is “scan the code for malware,” GSD passed. And yet the independent review reached a sharper and more uncomfortable conclusion. It found the community audit honest but incomplete, and it identified the single highest risk in the entire situation as something that was not in the code at all: the previous maintainer still held the keys to publish to the original package on the registry. Anyone who kept installing from the original package name was trusting a person who had already demonstrated a willingness to walk away from the project and the community without warning, and the relevant question was not whether the package was malicious today but who could push an update to it tomorrow. The review went further still, naming structural gaps the audit had downplayed: the tool handed its AI agents broad shell and filesystem access and then relied on guardrails that warn but never block, emitting their warnings into the very context window that a prompt-injection attack would occupy.

This is the pattern worth naming, because it is the pattern the rest of this article is about. Call it trust-state inversion. It is the situation where the visible artifact still looks acceptable while the trust relationships around it no longer do: maintainer continuity, registry authority, release governance, financial incentives, package ownership, update channels, and the downstream estate that has to be cleaned up afterwards. For a passive library that would already matter. For an agentic AI development tool that can read files, write files, execute commands, install dependencies and rewrite a project’s lockfile, it matters a great deal more, because the blast radius of a hostile update is no longer a bad formatting function but the developer’s source code, credentials, SSH keys, environment files and continuous-integration secrets.

GSD also shows why the old model of open-source risk is no longer sufficient on its own. A vulnerability scanner answers one class of question: is a known-vulnerable component present. A source review answers another: was suspicious code found in what was inspected. Both still matter. Neither answers who can publish the next version, whether release authority is resilient, whether the project has a succession plan, whether financial incentives have quietly distorted governance, or whether an AI tool can add a dependency before a human notices. Those are the questions that decide whether a dependency is trustworthy, and they are not questions a scanner is built to ask.

It is worth being precise about what is and is not established here, because the discipline of being precise is itself part of the lesson. The amount of money involved in the token event was reported by community and crypto sources at roughly half a million dollars, but the most-cited coverage stated plainly that there was no confirmed figure in public reporting at the time, so the number should be treated as an estimate rather than a fact. The creator’s public identity is well documented across many sources that predate the incident, so naming the project’s creator is not an accusation, but the characterisation of the token event as deliberate fraud by that person is a community classification rather than a proven legal finding, and the careful formulation is that the event is publicly linked to the maintainer rather than proven against him. The fork maintainer himself modeled exactly this restraint. His continuity announcement separated what was known from what was inferred and stated, in plain words, that absence of news is not the same as evidence, declining to assert intent he could not prove and inviting anyone with contrary evidence to bring it. That is what producing trustworthy evidence under pressure looks like, and it is a better illustration of the discipline this article will argue for than any abstract definition.

There is a constructive ending, too, and it deserves to be told alongside the failure. The community fork did not stop at rebranding. It added package-legitimacy checks through a tool that screens dependencies across the major registries using signals such as registry age, download count, source-repository linkage and naming distance to popular packages, with a fallback that forces a human checkpoint before any install if the checker is unavailable. The downstream plugin packaging moved installation inside the editor session rather than the host shell and bundled its own copy of the tooling, specifically to remove the global-install trust dependency. In other words, the community looked at the gaps the independent review had surfaced and built defences against them. That is the open-source ecosystem doing what it does best, in public, under scrutiny.

This is the right place to begin a discussion of the Cyber Resilience Act, the NIS2 Directive, the revision of the Cybersecurity Act and the EU Tech Sovereignty Package, for an openSUSE audience, because GSD is not really a story about one tool. It is a story about what open-source assurance is up against in 2026. And the point is not that GSD is itself automatically a matter for the CRA or NIS2 or the AI Act. The point is that the toolchain which builds regulated and customer-facing software has become part of the evidence chain. If an agentic tool contributed to validated software, to security evidence, to product code, to test artifacts or to a regulated AI system, a mature organisation should be able to say which tool and which version was used, what it touched, what it changed, what human review occurred, and how the dependency risk was assessed. That is not bureaucracy. It is traceability, and the rest of this article is about why Europe is now building an entire policy stack on top of that single idea.

The same lesson in the classic distribution chain

GSD is the agentic-AI restatement of a lesson the open-source world already learned the hard way through xz-utils. The two cases are worth holding side by side, because together they define the problem more completely than either does alone.

The xz backdoor, catalogued as CVE-2024-3094 and rated at the maximum severity, was discovered in March 2024 by a Microsoft engineer who noticed that secure-shell logins on a test machine were running about half a second slower than they should and spent several hours tracing the anomaly. What he found was the culmination of a campaign that had run for roughly two and a half years. A contributor operating under a pseudonym had built credibility in the xz project through legitimate work, while a set of sock-puppet accounts applied steady pressure on the project’s lone, overextended maintainer to add a co-maintainer. Once granted that authority, the attacker introduced a backdoor, and the way it was introduced is the part that matters for a distribution audience. The malicious code was not in the public source repository. It existed only in the release tarballs, in a modified build script that the attacker, now a trusted maintainer, produced and signed. The backdoor targeted the specific way that several Linux distributions link the compression library into the secure-shell daemon through systemd, and it would have given its author the ability to run code remotely on a very large number of machines. It was caught before it reached stable distributions, and only because one engineer chased a latency anomaly that he had every reason to ignore.

The xz incident showed that a distribution’s trust machine can be attacked through the release path, by turning the gap between what people review in source control and what they actually ship in a release artifact into a hiding place. GSD showed that the same trust machine can be bypassed entirely, when developers pull high-privilege tooling straight from a registry or a code-hosting platform into their local workflow, outside the curation and signing that a distribution provides. In the first case the artifact was poisoned. In the second the publish channel and the governance context around it became unsafe to rely on. Both point to the same conclusion, and it is the conclusion this whole article turns on: open-source assurance is no longer only about scanning code. It is about governing the chain of authority around the code.

It is worth saying clearly what a Linux distribution actually is, because the openSUSE audience knows this in their hands but the wider readership often does not, and the policy world almost never does. A distribution is not a pile of packages. It is a trust machine. It takes thousands of upstream components, each maintained by different people under different conventions in different parts of the world, and it reviews them, patches them, builds them in a controlled build service, signs them, publishes them through repositories and mirrors, and updates them on a managed lifecycle, turning a sprawl of independent projects into a coherent operating environment that a downstream user can install and rely on without ever meeting an upstream maintainer. The Open Build Service, reproducible-build work, package signing, security advisories, and long-term-support branch policy are not compliance theatre invented for a regulation. They are the assurance infrastructure of a distribution, built over decades because distributions learned the hard way that trust has to be manufactured, not assumed. This matters enormously for what follows, because much of what the Cyber Resilience Act will ask manufacturers to do, a good distribution already does. The task is less to invent new compliance machinery and more to make existing engineering evidence legible to the legal, procurement and conformity-assessment systems that are now asking to see it.

The chain of authority that now needs governing includes the classic layers of an open-source supply chain: source repositories, maintainers, package managers, build systems, mirrors, signing keys, software bills of materials, advisories, vulnerability databases and distribution channels. It also now includes a newer layer that GSD made visible. Agentic AI coding tools can recommend packages, run install commands, edit lockfiles, and normalise dependency choices that no human has properly examined. The early warning sign already has a name, slopsquatting, which describes attackers registering plausible package names that an AI system is prone to hallucinate and suggest, so that a developer who accepts the suggestion installs an attacker’s code. The consequence is that the dependency graph is no longer only what developers deliberately chose. It is increasingly what their tools suggested, installed, or made easy to accept. This is what we are up against, and it is the reason the evidence layer, which the second half of this article is about, now matters more than it ever has.

The sausage factory and the view from orbit

Against that background, the European policy landscape can look almost comically complicated. CRA. NIS2. CSA. CADA. Chips Act 2.0. The Open Source Strategy. The Digital Commons EDIC. The ENISA Single Reporting Platform. M/606. EUCC. EUCS. EUVD. The Open Regulatory Compliance Working Group. STAN4CR. CYBERSTAND. To anyone not paid to follow the Brussels machinery, this is alphabet soup, and the natural reaction is to assume that the people producing it have lost the thread.

The old line about laws and sausages is useful here, and you should use it without cynicism. Up close, policy formation is genuinely messy. It is consultations and compromises and impact assessments and lobbying and standardisation requests and delegated acts and guidance documents and implementation deadlines and budget fights and late corrections. From the floor of the factory it looks like disorder. But the disorder is not evidence of incoherence. It is evidence of asynchrony, and the asynchrony has a cause. Policy does not move in lockstep because reality does not move in lockstep. Different crises expose different failures at different moments, and each failure produces its own instrument on its own timetable.

The pattern becomes legible when you line up the crises against the responses. Heartbleed, in 2014, exposed the underfunding of critical cryptographic infrastructure: a library securing a large fraction of the web was being maintained on roughly two thousand dollars a year in donations by a handful of people, one of them full-time. Log4Shell, in December 2021, exposed the operational blast radius of a single widely embedded open-source component, a logging library maintained by volunteers under a foundation, whose flaw set off a global scramble and a long tail in which a large share of affected systems were still vulnerable many months later. The xz backdoor, in 2024, exposed maintainer sustainability and release-path trust. GSD, in 2026, exposed registry control, agentic-AI privilege and maintainer-trust collapse. Cloud dependency exposed Europe’s strategic exposure to a small number of non-European providers. Artificial intelligence and semiconductors exposed capacity gaps. Each of these produced or accelerated a policy response, and the responses arrived in the order the crises did, which is why they look unrelated.

From higher orbit, they resolve into a single structure that is worth stating as plainly as possible, because it is the spine of the entire argument. Europe is trying to turn digital dependency into a trust market. The Cyber Resilience Act creates product accountability. NIS2 creates organisational resilience. The revision of the Cybersecurity Act aims to build certification, cyber-posture assurance and trusted-supplier logic. The Tech Sovereignty Package tries to build capacity through chips, cloud, AI infrastructure, open source, energy planning, procurement and funding. The standardisation request M/606 tries to translate legal requirements into harmonised standards that produce repeatable evidence. The Open Source Strategy names open source as a pillar of technological sovereignty. The Digital Commons EDIC and the Sovereign Tech funding models point toward maintenance and stewardship as public infrastructure. And public procurement turns the whole strategy into market demand. Seen that way, the alphabet soup is not random. It is a layered attempt to answer one question: how can Europe build and operate digital infrastructure that is open, secure, interoperable, competitive and trustworthy under pressure.

The instruments are asynchronous. The direction of travel is not. That single sentence is worth more to an audience than any acronym-by-acronym walkthrough, because it converts a sense of chaos into a sense of architecture, and architecture is something you can engage with.

Europe’s third way is a trust market

Europe’s digital strategy is often framed as a binary choice: depend on American hyperscalers or risk exposure to Chinese state-backed infrastructure. That framing is too narrow, and it concedes too much. Europe’s stronger idea is a third way, built on open standards, open source, interoperability, rights-based governance, cybersecurity and a competitive market that rewards transparency over opacity.

This third way is not digital autarky, and it is important to say so, because the caricature of European sovereignty is a wall. It is not a call to cut Europe off from partners or from global open-source collaboration, both of which Europe depends on and benefits from. It is a rejection of blind dependency. A sovereign digital capability is not defined by where the servers physically sit or by the word “sovereign” appearing in a procurement document. It is defined by a set of capabilities: the ability to know what is in your systems, to maintain them, to port them, to audit them, to replace a supplier, to recover from a failure, and to produce evidence for all of the above. Sovereignty, in this reading, is not a label. It is a capability to know, maintain, replace, verify and recover.

Open source is central to this model because it can provide the control layer. Open code can be inspected. Open standards reduce lock-in. Open implementations can become shared reference infrastructure. Open collaboration spreads cost and expertise. Open licensing enables forking, adaptation and continuity when a vendor or a maintainer fails. These are real properties, and they are the reason open source is the natural substrate for a sovereignty strategy.

But open source is not automatically sovereign, and pretending otherwise is the fastest way to discredit the whole idea. A package maintained by one exhausted volunteer can be entirely open and still dangerously fragile, as both Heartbleed and xz showed. A foundation can be trusted and still underfunded. A public administration can migrate to open source and still struggle if the underlying projects lack support markets, security processes or long-term maintainability. A company can build on open-source components and still have no defensible account of what is inside its product, where it came from, who maintains it, or how quickly a vulnerability could be assessed. The licence file says one thing about freedom; the governance and the funding and the evidence say something else about reliability, and reliability is what a trust market runs on.

The strategic question, then, is not whether Europe supports open source in principle. Everyone supports open source in principle. The strategic question is whether Europe can build sovereign open-source assurance: the ability to know, maintain, secure, evidence, procure, replace and recover the open-source components on which critical products and services depend. That is the missing layer between the policy language about sovereignty and the operational burden that lands on the smallest actors in the chain, and it is the layer this article, and the keynote it accompanies, exist to make visible.

The CRA turns sovereignty into an evidence problem

The Cyber Resilience Act is the first hard operational test of this model, and it is worth understanding in enough detail to act on, because the businesses in the SUSE audience will be living inside these mechanics.

The CRA entered into force on 10 December 2024, twenty days after its publication in the Official Journal, and its main obligations apply from 11 December 2027. But the date that should anchor your planning is earlier. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. This is the first moment the trust stack has to produce operational evidence, and it arrives more than a year before full application. The reporting sequence is not a vague obligation to tell someone eventually. It is four distinct clocks. An early warning is due within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability or a severe incident. A fuller notification is due within 72 hours. A final report on an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure is available. A final report on a severe incident is due within one month. These reports go through a single channel, the ENISA Single Reporting Platform, to the coordinating national computer security incident response team at the manufacturer’s main establishment, and onward to ENISA and other relevant teams. The platform is the only channel; national email is not a substitute, and at this stage there is no programmatic interface, so the process is a human one. Crucially, these reporting obligations apply to products already on the market, not only to products placed on the market after full application, which means legacy fleets, long-lived software and long-term-support branches are in scope from September 2026.

For a manufacturer, this is an evidence machine, and it has to be built before the clock starts rather than improvised after the first incident. A company has to be able to say, under time pressure, which products are affected, which components are involved, which versions are exposed, whether the vulnerability is actually exploitable in the context of its product, whether upstream has a fix, whether a mitigation exists, which customers are affected, what they need to be told, and what can be reported defensibly within the legal deadlines. None of that is possible without an inventory of products and components, a vulnerability-intake and triage process, a way to map a vulnerability to the specific shipped artifacts it affects, and a record of who decided what and when.

There is a second mechanic that the SUSE audience should understand because it bears directly on distributions and on the businesses that build on them: substantial modification. The CRA’s obligations attach to whoever places a product on the market under their own name or trademark, but they also attach to whoever substantially modifies a product, because a substantial modification can make the modifier the manufacturer for the modified version. A substantial modification is not merely a new release; it is a change that alters the intended purpose or introduces new or increased cybersecurity risk not already covered by the original risk assessment. For software ecosystems this is a live question. Enabling a connector, changing a cryptographic default, adding a remote-management capability, forcing a cloud dependency, or shipping a hardened and rebranded stack can all cross the line. A desktop operating system released in 2026 that receives a feature update in 2028 which changes its intended purpose or increases its cybersecurity risk triggers obligations for that updated version, and the entity making the modification becomes the manufacturer for compliance purposes. For integrators who take a distribution, modify it, brand it and ship it, this is the difference between being a distributor and being a manufacturer, and it is worth knowing which side of the line a given activity falls on before a market-surveillance authority asks.

Alongside reporting and modification sits the support-period obligation. The manufacturer must determine and communicate a support period for the product, must handle vulnerabilities throughout the product’s lifecycle, and must keep the technical documentation and certain records available for at least ten years after placing the product on the market, or longer if the support period exceeds ten years. For long-lived software this is a documentation and lifecycle-governance commitment that has to be designed in, not retrofitted.

This is where the small and medium-sized enterprise becomes the compliance shock absorber, and naming the problem honestly is more useful than pretending it away. A fifteen-person company in healthtech, industrial automation, security or data management may ship a product built on a Linux base, a database, cryptographic libraries, web frameworks, container images, package managers, cloud-backed functions, open-source build tooling, and now AI-assisted development workflows. Under the CRA it may be the manufacturer for the product it places on the market, with all the reporting and documentation duties that implies. But many of the upstream projects it depends on are non-commercial, outside direct manufacturer obligations, or supported by a foundation or steward with a lighter role. The SME sits close to the market and the customer and far from control over its upstream dependencies. If upstream evidence is weak, the SME has to translate informal community practice into formal regulatory evidence, under time pressure, every time something goes wrong. That is expensive, it is fragile, and it is unfair, and if Europe gets the model wrong it is the SME that pays.

If Europe gets it right, the same pressure becomes an advantage. An SME that understands its open-source supply chain, maintains a real component inventory, supports the upstream projects it depends on, uses secure build pipelines and can produce evidence quickly will become a more trusted supplier than a competitor who cannot. But that outcome requires the open-source ecosystem to produce reusable assurance, not only reusable code. The rest of this article is about how that assurance gets built, funded and recognised.

A final point on the CRA, and it is the one that justifies the keynote’s “deadline fixed, machinery in flight” framing. The deadline is genuinely fixed. The machinery genuinely is not finished. As of early June 2026, no CRA harmonised standard has been ratified or cited in the Official Journal, which means the presumption of conformity that harmonised standards are supposed to provide is not yet available for any product category. No notified bodies have been designated, and the machinery that lets member states designate them only opened on 11 June 2026, with the Commission’s best-efforts target for sufficient capacity set at 11 December 2026. The ENISA Single Reporting Platform is not yet live and is scheduled to become operational on the reporting date itself, 11 September 2026, with ENISA publishing the registration, training and dry-run materials during June 2026. The honest message to a manufacturer is therefore not to wait for the system to become comfortable. The conformity standards are not ready, the notified bodies are not designated, and the reporting platform is not live, and none of that postpones the reporting obligation or the underlying requirement to meet the essential cybersecurity requirements directly. The rational response is to build your own evidence pipeline now and demonstrate conformity directly against the requirements, because the alternative is to discover in September that the machinery you were waiting for never arrived in time.

The steward is a bridge, not a command structure

The CRA’s treatment of open source is far more nuanced than the early drafts led the community to fear, and the story of how it got that way is itself one of the most encouraging things an open-source audience can hear.

When the Commission first proposed the CRA in September 2022, the open-source community warned that as drafted it would have a chilling effect, because it would have pulled most consequential open-source projects into manufacturer-grade obligations, including the prospect of affixing a conformity mark to releases. In April 2023, the Eclipse Foundation and eleven other organisations, twelve in total, published an open letter to the European institutions, with a second letter following. Their central argument was that open-source software made up more than seventy percent of the software in products with digital elements in Europe and was about to be regulated without proper consultation of the people who actually produce it. The institutions listened. The political agreement reached in December 2023 substantially improved the open-source treatment and, for the first time in any regulation, created a new category of economic actor, the open-source software steward, and the implementation period was extended to give the ecosystem time to adapt. The community changed the law once, through organised engagement, and the steward concept exists because of it. That is the precedent the keynote closes on, and it is true.

The steward role itself needs careful explanation, because it is easy to get wrong in both directions. A steward, in the CRA’s terms, is a legal person that provides sustained support for free and open-source software intended for commercial activities and plays a main role in ensuring its viability. A steward is not a manufacturer under another name; it does not put a conformity mark on the downstream products that integrate the software it supports. The Commission’s position is that stewards have tailored obligations, including a documented cybersecurity policy, cooperation with market-surveillance authorities, and certain reporting responsibilities, and that stewards are not subject to administrative fines for CRA infringements. But the steward is also not a regulator sitting above a project, and this is the part the simplified framing gets wrong. The Eclipse Foundation’s Open Regulatory Compliance Working Group, in a November 2025 analysis of the steward role, made the point precisely: the CRA’s text can read as though a steward imposes a security policy onto a project, whereas real open-source projects already maintain their own security policies and governance cultures, with the steward providing coordination and infrastructure rather than direction. The most credible way to understand the steward is as a bridge. It provides legal continuity, infrastructure support, coordinated vulnerability handling, evidence support, communication and funding, and it makes a project’s existing security practices legible to the downstream users who now need to see them. A good steward helps a project become easier to trust and easier to integrate. It does not turn volunteers into a compliance department, and any implementation that tries to will fail in contact with how open source actually works.

Voluntary security attestation, which the CRA also provides for, could become a second bridge of the same kind. Designed well, it would let open-source projects or stewards publish evidence that helps downstream manufacturers satisfy their due-diligence obligations for third-party components, so that the same upstream component does not have to be separately audited by every downstream manufacturer in incompatible ways. Designed badly, it becomes paperwork that only large foundations can afford to produce. The executive director of the Eclipse Foundation made the underlying argument well: doing the bulk of the conformance work once, in the upstream project, rather than repeating it across hundreds of downstream products, is obviously more efficient, and the optimistic hypothesis is that once companies are legally required to meet secure-development practices they will be incentivised to invest in the upstream they depend on. Whether attestation becomes a genuine shared-evidence layer or another cost centre will depend on the implementation, the standards and the funding, which is the recurring theme of everything that follows.

Standards are where the trust stack becomes testable

Standards are the layer where the European trust stack stops being a legal aspiration and becomes something you can demonstrate. Legal text says what must be achieved. Standards describe repeatable ways to show that it has been. This is why the standards section of the keynote is not an appendix, and why the openSUSE community has a direct stake in it.

The CRA standardisation request, M/606, was issued through a Commission implementing decision in early 2025 and accepted by the three European standards organisations, CEN, CENELEC and ETSI. It covers around 41 standards, split into roughly 15 horizontal standards, which set a common framework, methodology and taxonomy applying to every product with digital elements, and the remainder vertical, covering the specific risks of particular product types. The timeline runs on three dates. The two core horizontal standards, on secure development and on vulnerability handling, are targeted for 30 August 2026. The vertical, product-specific standards are targeted for 30 October 2026. The remaining horizontal standards are targeted for 30 October 2027, about a year before full application. It is important to keep two milestones distinct, because the distinction is exactly the kind of thing a standards-literate audience will check. A standard being delivered is not the same as a standard being cited in the Official Journal, and only the citation triggers the presumption of conformity. As of early June 2026, several of the horizontal drafts have closed their public enquiry and an ETSI vertical is at final draft, but none has been ratified or cited, and the first citations are expected no earlier than the second half of 2026 on a timetable the Commission has not confirmed.

Here is where the standards landscape becomes concrete for a distribution audience, and it is worth making the point vividly because it dissolves the abstraction. The vertical standards now in mature draft cover browsers, password managers, antivirus software, virtual private networks, network management systems, security information and event management systems, and boot managers. Every one of those is something a Linux distribution ships, packages, or supports. When the CRA’s vertical standards talk about the security of a password manager or a boot manager, they are talking about software the openSUSE community builds and maintains. This is the opposite of an abstract regulatory exercise happening somewhere else. It is a set of requirements being written, right now, about the exact software this community produces, and the question is only whether the community helps write them.

That question matters because of what happens if the answer is no. If the standards are written around the assumptions of traditional proprietary product manufacturers, open-source development models risk being treated as exceptions or edge cases, and practices that are normal and healthy in open source can end up looking like deviations that have to be explained away. If open-source communities engage early, the standards can instead recognise how open source actually works: public issue tracking, distributed maintainership, signed releases, reproducible builds, package provenance, software bills of materials and exploitability records, coordinated disclosure, downstream distribution channels and transparent advisory processes. The mechanism for that engagement already exists and the door is open. Apache, Blender, OpenSSL, PHP, Python, Rust and Eclipse, seven major foundations, announced joint work in 2024 to establish common secure-development specifications based on open-source best practice, hosted at the Eclipse Foundation and explicitly intended to feed the European standards process. The Open Regulatory Compliance Working Group is producing CRA implementation resources and the steward analysis described above. The CRA Expert Group includes open-source representation. The standards section of the keynote is therefore not a lament that someone should do something. It is an invitation, because the people who will be most affected are already in the room where it is being decided, and there is space for more of them.

There is also a head-start answer for organisations that feel behind. The ENISA standards-mapping study identifies the existing standards with the strongest alignment to the CRA’s requirements, and an organisation that already follows them has meaningful coverage to build on: ETSI EN 303 645 for consumer device security, the IEC 62443 series for industrial and operational-technology systems, ISO/IEC 27002 for information-security controls, and ISO/IEC 30111 with 29147 for vulnerability handling and disclosure. Conformance with these supports CRA work without replacing the CRA-specific conformity assessment, but it means few organisations are starting from zero. The principle to leave the audience with is simple and worth stating as a line: standards without implementation become paper, and open-source code without standards can fragment, and Europe’s opportunity is to connect the two through open specifications, reference implementations, conformance suites and shared evidence tooling.

Evidence discipline is the hinge

The word “evidence” sounds dry, and it is the most important word in this article, because evidence is the hinge between a legal obligation and the technical reality of a running system. Everything upstream of evidence is aspiration. Everything downstream of it is enforcement. The quality of the evidence is what decides whether the trust stack carries load.

It helps to be precise about what evidence means here, because it is a layered thing and the layers answer different questions. A software bill of materials answers what is inside a product. Provenance answers where an artifact came from and through which pipeline. Reproducibility answers whether the artifact can be rebuilt from its source, which is the property that would have caught the xz backdoor, since the backdoor lived in a release tarball that did not match the repository. Exploitability records, in formats such as VEX or CSAF, answer whether a given vulnerability actually applies to a given product, which is what stops a manufacturer from drowning in irrelevant findings. A security advisory answers what happened and what changed. Release signing answers whether an artifact is what it claims to be. Registry governance answers who can publish the next version, which is the question GSD turned into a headline. Succession planning answers what happens when a maintainer disappears, which is the question xz answered badly. Incident records answer what was known and when. No single one of these is sufficient, and the recurring mistake in compliance discussions is to treat the software bill of materials as the whole answer when it is only the first question.

This is where the metric I work with, Mean Time to Evidence, earns its place, because the CRA reporting clocks make it operationally real. Mean Time to Evidence is the time between a security-relevant event and the existence of a defensible, attributable record of what happened, what was affected, what was done, and what downstream users can rely on. Mean Time to Patch has always mattered and still does. But the CRA’s twenty-four-hour and seventy-two-hour clocks turn evidence delay into legal and operational risk, because a manufacturer who cannot reconstruct what happened, when it happened, which versions were affected, and what evidence supports the assessment, cannot meet the deadlines no matter how good its engineering is. Evidence delay becomes reporting delay, and reporting delay becomes exposure. The metric has two dimensions that the keynote should make explicit. Upstream Mean Time to Evidence is how fast a project can produce trustworthy information about a vulnerability’s status, the affected versions, the availability of a fix, and the integrity of a release. Downstream Mean Time to Evidence is how fast a manufacturer or a regulated user can map that upstream information onto its own shipped products and its own reporting obligations. The crucial relationship is that upstream sets the floor for downstream. If an upstream project has no advisory discipline, no clear release identity, no support lifecycle and no maintainer continuity, every downstream manufacturer has to reconstruct the evidence from scratch, under pressure, every time. That is the precise mechanism by which weak upstream maintenance becomes a downstream compliance cost, and it is the argument for funding maintenance that the next section makes.

The companion concept, which I describe as Evidence-In, Trust-Out, is the positioning that ties this together. Trust is not an assertion that enters the market and is then taken on faith. Evidence enters the market, and trust is what emerges from it. The discipline that makes evidence worth trusting is well understood in regulated industries, where it goes by the shorthand ALCOA-plus: a record should be attributable, legible, contemporaneous, original, accurate, and then also complete, consistent, enduring and available. Those properties translate to cybersecurity evidence almost without modification. A vulnerability record is not useful if no one knows who made the decision, when it was made, what data it relied on, whether it maps to the shipped versions, and whether it will still be available when an auditor or a market-surveillance authority asks for it two years later. Trust, in the end, is what remains when the question becomes: show me the record.

Two of the examples in this article illustrate the two ends of the evidence spectrum, and they are worth pairing deliberately. curl is the positive model. It is a small-team upstream project with enormous downstream reach, and its security process is unusually disciplined. It operates as its own vulnerability-numbering authority, it publishes advisories that identify the affected version ranges and the exact commits that introduced and fixed each issue along with credit to the reporter, it provides those records in machine-readable form, and it coordinates disclosure through established channels and notifies the distributions ahead of a release. That is upstream evidence that is directly useful downstream, and it is the reason a distribution can act quickly on a curl advisory. It is also, as of recent confirmation from the Sovereign Tech Agency’s own material, a funded project, which makes it the exact pairing Europe needs more of: upstream evidence discipline backed by sustainable maintenance capacity. GSD is the cautionary counterpart, and its evidence lesson is the one about the continuity announcement: under pressure, the responsible move was to separate what was known from what was inferred and to decline to assert what could not be proven. Confident speculation would have been worse than careful uncertainty. The distance between curl’s advisory discipline and the absence of it in a project run by one exhausted volunteer is the maintenance gap, measured in evidence.

Funding the boring work

Open source will not become sovereign infrastructure because Europe declares it important. It will become infrastructure when the unglamorous work that makes it trustworthy is funded: release engineering, security triage, dependency mapping, build reproducibility, package signing, vulnerability coordination, test infrastructure, maintainer continuity, documentation, migration support and incident response. None of that is exciting, and all of it is what the trust stack stands on.

The scale of the gap is worth stating with figures, because the figures make the argument unanswerable. Open source is present in roughly 96 percent of codebases and contributes a minimum of 65 to 95 billion euros a year to the European economy, according to the feasibility study commissioned to scope a European funding instrument. And yet around a third of maintainers are unpaid, and many critical projects are maintained by teams of three people or fewer. That is the structural condition that produced Heartbleed and Log4Shell and xz, and it is the condition GSD ran into from a different direction. The supply side of the trust market is chronically underfunded, and the cost of that underfunding does not show up as a line item until it shows up as a crisis.

There is a working model for fixing this, and it is German. The Sovereign Tech Agency, which began in 2022 as the Sovereign Tech Fund under the federal innovation agency, is a publicly funded body that invests in the open-source components that other software depends on. As of early 2026 it had invested around 34 million euros across roughly 95 technologies, and the list reads like the dependency graph of a Linux distribution: systemd, PHP, FFmpeg, GNOME, Samba, reproducible-builds work, and many others. Two of its investments matter especially for an openSUSE audience. It funds curl, which is the pairing of evidence discipline and funding described above. And in 2026 it invested about 1.2 million euros in KDE Plasma technologies, covering Plasma, KDE Linux and the underlying frameworks, which connects the funding argument directly to the desktop that a meaningful part of this community ships and that the public-sector migrations described in the next section have chosen. The Agency is also the explicit model for a European instrument: the Digital Commons EDIC is piloting a European Sovereign Tech Fund, and the EU Open Source Strategy names an Open Source Maintenance Instrument, with the feasibility study proposing a minimum European contribution of around 350 million euros from the 2028 to 2034 budget. That figure, set against the Agency’s 34 million and against the chronic underfunding the same study documents, is what makes the gap measurable rather than rhetorical.

The principle should be stated bluntly, because bluntness is what makes it land: funding maintainers is not charity, it is supply-chain risk reduction. And the design of the funding matters as much as the amount. If a maintenance instrument rewards activity, it buys goodwill. If it rewards evidence-producing maintenance, it buys assurance. A funded maintainer should shorten not only the time to patch but the time to evidence. A funded project should become easier to identify, assess, integrate, support, procure and recover. That is the link between maintenance funding and the world of the CRA, NIS2 and the Cybersecurity Act, and it is the argument that turns a community concern about burnout into an industrial-policy and security argument that finance ministries can act on.

Procurement turns strategy into demand

Funding stabilises the supply side of the trust market. Procurement creates the demand side, and without demand the supply side has nothing to sustain it. Strategy documents do not create markets. Purchases do.

The strongest public-sector example for an openSUSE audience is Schleswig-Holstein, the northern German state that has turned open-source strategy into an operational migration rather than a pilot. The state is moving on the order of 30,000 workstations away from the proprietary stack, with tens of thousands of public servants and teachers in scope, replacing the proprietary office suite with LibreOffice, the mail and calendar system with Open-Xchange and Thunderbird, the collaboration platform with Nextcloud, the directory with an open alternative, and the desktop with Linux running KDE Plasma, with the Open Document Format mandated as the administrative standard. The email migration was reported through the Commission’s own open-source observatory as completed, moving more than forty thousand mailboxes and well over a hundred million items off the proprietary platform, with the office migration substantially advanced, license savings in the tens of millions of euros, and a portion of the savings reinvested into the open-source ecosystem. The exact figures should be reconciled against the observatory’s wording at the moment of publication, since the migration is in progress and the numbers move, but the direction is unambiguous and the relevance to this community is direct: the desktop the state has chosen is the one openSUSE ships, and the migration is a live demonstration that public buyers can create real demand for open-source infrastructure and make digital sovereignty operational rather than rhetorical.

The honest caveat is the one that ties procurement back to the rest of the argument: adoption without assurance only relocates dependency. Moving from a proprietary stack onto an underfunded open stack is not sovereignty if the open components are themselves a single exhausted maintainer away from the next xz. The cautionary case is Munich, which migrated to Linux in the 2000s, ran the migration for years, and then reversed course, for reasons that were largely political and organisational rather than technical: weak change management, friction with counterparts still on the proprietary stack, and a loss of political continuity across administrations. The contrast with Schleswig-Holstein is instructive precisely because Schleswig-Holstein built a cross-party consensus designed to survive elections. The lesson is that sovereignty is earned through governance, funding and evidence, and not declared by a single procurement decision, which is the same lesson the whole article keeps arriving at from different directions. The positive durability case is worth naming too: the French national gendarmerie has run its own Linux-based distribution across more than a hundred thousand workstations for close to two decades, which is the standing rebuttal to the claim that public-sector open-source migrations always fail.

The role of the buyer, then, is not only to buy open source but to buy it in a way that builds the assurance layer. Public administrations and regulated entities should not consume open source as free raw material while asking the smallest actors in the chain to provide enterprise-grade assurance for nothing. Procurement should reward open standards, portability, documented support periods, vulnerability-handling processes, release integrity, component transparency, and contribution back to the critical dependencies a buyer relies on. When a buyer requires those things and pays for them, it converts the sovereignty strategy into market demand for maintained, evidenced, portable open systems, which is the only thing that makes the supply side sustainable. The phrase to leave the audience with is that buyers create the market, and that begins with the end in mind: every procurement should ask how the organisation would leave, migrate and verify continuity if the supplier failed, was acquired, changed its terms, or could no longer be trusted.

NIS2 and the Cybersecurity Act widen the frame

The CRA is product law, focused on products with digital elements and on the actors who place them on the market. It is not the whole of the trust stack, and an audience that only hears about the CRA will misjudge its own exposure. Two other instruments widen the frame from product security to operational trust.

NIS2 is the organisational layer. It concerns cybersecurity risk management, supply-chain security, incident handling, business continuity and governance for the essential and important entities across a wide range of sectors. It is a directive, which means it is transposed into national law and its details vary by member state, but its direction is consistent: organisations have to manage their risk, including the risk in their software supply chains, and they have to be able to show that they do. The revision of the Cybersecurity Act, proposed in January 2026, adds a further layer, aiming to strengthen the European cybersecurity certification framework, to develop schemes faster with ENISA in a stronger scheme-management role, to introduce a notion of an entity’s cyber posture, and to build trusted-supplier logic for critical infrastructure. It is a proposal, not yet binding law, and it should be presented as such, but its direction tells you where assurance is heading: toward certification that becomes reusable evidence rather than a slow parallel bureaucracy.

The reason this matters for open source is that it changes who needs evidence and why. A manufacturer needs CRA evidence for its product. But a hospital, an energy company, a cloud provider, a public administration or a digital-service provider needs NIS2-style organisational controls for the environment in which products and open-source systems actually run, even when it is not itself a CRA manufacturer for any particular component. Certification schemes, even where formally voluntary, become procurement signals, because a buyer in a regulated sector will treat a certificate as a trust signal and will ask suppliers for evidence of secure development, vulnerability handling, support periods, supplier risk, continuity and incident readiness. This is the route by which the assurance expectations of the CRA reach organisations that the CRA does not directly regulate, and it is why an organisation that uses open source directly, without placing any product on the market, still has to manage its open-source dependencies as part of its NIS2 risk management, its supplier assurance, and its incident response. The market does not wait for every legal boundary to be litigated. Buyers ask a simpler question, and they ask it of everyone: can we rely on you, and can you prove it.

The Linux distribution as the working model

It is worth drawing the threads together around the openSUSE audience specifically, because the distribution is not only the lens of this talk. It is the working model of what sovereign open-source assurance looks like when it is done well, and the community that builds it is better positioned than almost anyone to lead.

Map the CRA’s roles onto a distribution ecosystem and the picture is clear. A commercial enterprise distribution placed on the market under a company’s name, such as SUSE Linux Enterprise, is a product with digital elements for which that company is the manufacturer, with the full set of obligations: risk assessment, secure-by-design requirements, technical documentation, conformity assessment, support-period determination, vulnerability handling and reporting. A genuinely non-commercial community distribution may sit outside direct manufacturer obligations where it is not made available on the market in the course of a commercial activity, which is the role much of openSUSE’s community work occupies. A legal person that provides sustained support for the open-source software intended for commercial activities, which a foundation or a commercial sponsor may do, can occupy the steward role, with its tailored obligations and its exemption from administrative fines. An integrator that takes the distribution, substantially modifies it, brands it and ships it for commercial downstream use can become the manufacturer for that modified product. The same ecosystem contains all of these roles at once, which is exactly why role clarity is the first compliance control, and why the common mistake, that commercial use of open source makes every upstream contributor a manufacturer, is both wrong and damaging. The keynote should make this triad concrete, because the audience lives inside it, and seeing their own work mapped onto the regulation is what turns the talk from a policy briefing into something they can act on.

The deeper point is that the distribution already implements most of what the regulation is asking for. The Open Build Service produces a controlled, auditable build pipeline. Package signing establishes integrity. Reproducible-build work establishes that an artifact matches its source, which is the property that defends against the xz class of attack. Security advisories, mapped to package versions, are exactly the downstream-consumable evidence the CRA’s reporting regime needs. Long-term-support branch policy is lifecycle governance. Mirrors and repository policy are distribution-channel integrity. None of this was built for a regulation. It was built because distributions learned that trust has to be manufactured. The work that remains is to make this existing engineering evidence legible to the legal, procurement and conformity-assessment systems that are now asking to see it, and to help write the standards so that they recognise these practices rather than treating them as exceptions. That is a translation task and an engagement task, and it is squarely within this community’s competence.

What communities should do now

Open-source communities do not need to become corporate compliance departments, and any advice that pushes them in that direction will be ignored, correctly. What they need to do is make trust inspectable, which is a lighter and more achievable thing.

At a minimum, a strategically important project should be able to answer a short list of questions, and the value is less in any single answer than in the project having thought about them. Who can publish a release. Is release authority shared, or does it rest with one person. Are the registry accounts protected with strong authentication and, where possible, trusted publishing rather than long-lived tokens. Are releases signed, and is provenance available. Is there a security policy and a contact route for reporting vulnerabilities. Is there a coordinated disclosure process. What happens if a maintainer disappears, which is the succession question that xz answered badly. Are the dependencies known. Are downstream users told what changed in a release. Is there a route to publish advisories. And is there any financial entanglement, such as an associated token, that should be disclosed, which is the question GSD raised.

For agentic AI development tools specifically, the checklist has to go further, because the privileges are higher. What can the tool read, write, execute and transmit. Can it install dependencies. Can it edit lockfiles. Are its guardrails advisory or blocking, which was the gap the GSD review found. Can it run safely without access to production secrets. Can it be sandboxed. And can an organisation remove it within twenty-four hours if trust collapses. These are not exotic questions. They are the questions that distinguish a tool you have evaluated from one you have merely adopted.

This points to a small set of maturity dimensions that the classic open-source maturity models, valuable as they were, did not foreground, because they were built for an earlier era. Registry governance: who can publish, transfer, revoke or deprecate. Release-authority distribution: how many independent people control the release flow. Succession and bus factor: what happens when the maintainer is gone. Financial entanglement: whether a token, grant, sponsorship or equity arrangement could distort governance. Build and package provenance: whether releases are signed, reproducible and accompanied by a bill of materials. Agent-privilege transparency: what an AI tool can read, write, execute and install. And dependency-autonomy controls: whether the tool can add dependencies without human approval. For high-privilege development tooling, a bus factor of one should prevent professional adoption unless compensating controls are documented, and a project with an associated tradeable token should be treated as a financially entangled supplier rather than as neutral community infrastructure. None of this is a counsel of perfection. It is a counsel of visible maturity, and the difference between a project that has these answers and one that does not is the difference between a dependency a regulated buyer can trust and one it cannot.

What companies should do now

For the business owners and organisations in the SUSE audience, the response to all of this is not panic and it is not a retreat from open source or from agentic AI, both of which deliver real value and are not going away. The response is professionalisation, and it can be organised into four loops that fit how a company actually operates.

The first is the adoption loop, which runs before a high-privilege tool enters normal engineering use. Write down why the tool is being adopted, what it can access, who controls its package registry, how its releases are published, whether versions are signed, whether provenance exists, whether there is a security policy, whether there is a succession plan, and whether financial incentives could distort its governance. For a small company this is a one-page intake record, not a procurement bureaucracy, but it has to exist, because “everyone was using it” is not a governance position and will not survive an audit.

The second is the runtime loop, which runs while the tool is in use. Pin versions, and do not pull the latest tag for high-privilege tooling, which is the single change that would have neutralised a large share of recent registry-based incidents. Run agentic development tools in constrained environments where possible: containers, virtual machines, or restricted workspaces. Keep production secrets out of the environments where development agents run, so that a compromised tool cannot reach the secure-shell keys, cloud credentials and registry tokens that turn a local incident into a breach. Require human approval for dependency installation and lockfile changes. Record which AI tool, which version and which mode contributed to important artifacts, which is the traceability that the CRA-adjacent and AI-Act-adjacent worlds will increasingly expect. And treat dependencies that an agent introduced as untrusted until a human has checked them.

The third is the response loop, and it is the one most companies do not have, because it is genuinely new. A maintainer-trust-collapse playbook is not the same as a vulnerability playbook. In the GSD case there was no vulnerability identifier, no exploit and no malware signature; the trigger was the loss of trust in maintainer continuity, registry control and project governance. The response to that trigger is its own procedure: freeze updates, identify where the tool is installed across machines and pipelines, inspect lockfiles and global installs and caches and continuous-integration configuration and project templates, rotate credentials if there is any plausible exposure path, compare package versions to see what actually changed, reconstruct the window during which the tool was in use and what it touched, and then decide whether to migrate, fork, replace or retire. A company that has rehearsed this once will handle the next GSD calmly. A company that has not will improvise under pressure, which is how mistakes happen.

The fourth, for any company that is a CRA manufacturer, is the evidence loop, and it has a deadline. Know which products are affected by a given issue. Maintain a component inventory and an upstream-dependency register. Track upstream vulnerabilities and assess their exploitability in your product’s context. Prepare reporting templates and decide in advance who is authorised to make a report-or-no-report decision. Keep records of awareness, decision, mitigation and closure. And test the whole process before 11 September 2026, because the first time you exercise your reporting pipeline should not be during a real incident with a twenty-four-hour clock running.

The openSUSE role, and why this community matters

The openSUSE community sits at exactly the right point in this conversation, and that is not flattery, it is structure. A distribution community understands packaging, reproducibility, signing, update channels, advisories, mirrors, maintainers, upstream relationships and downstream users. It understands that software trust is social and technical at the same time, that a maintainer is a person and a release is a commitment. That understanding is precisely what the European standards and policy process needs and most lacks, because the process is full of people who understand law and procurement and short of people who understand release engineering.

The stakes of participation are concrete. If open-source communities do not engage, the standards that govern browsers and password managers and boot managers will be written around the assumptions of proprietary product models, and open-source practices will be treated as deviations to be justified. If they do engage, they can show how open-source development already implements much of what Europe is asking for: transparent source, public review, reproducible builds, package metadata, shared advisories, dependency transparency, community governance and downstream distribution. The CRA was improved because open-source organisations engaged once already, and the steward concept exists as a direct result. The next stage is implementation, which is guidance and harmonised standards and voluntary attestations and stewardship models and maintenance funding and procurement criteria and evidence tooling, and all of it is being decided now. The pen is still moving, and this community has standing to hold it.

Europe’s third way must be earned

Europe’s third way is attractive because it does not have to be anti-American or anti-Chinese. It can be pro-openness, pro-standards, pro-competition and pro-trust. It can offer European buyers and partner countries a real alternative to closed-platform dependency on one side and state-controlled infrastructure on the other: an open, rights-based, interoperable, security-conscious digital market that other regions might actually want to join.

But that model will not be proven by rhetoric, and the gap between the rhetoric and the reality is where this article has lived. It will be proven by whether small companies can comply without becoming the shock absorber of the software supply chain, by whether stewards and foundations can produce evidence that downstream users can actually rely on, by whether the standards reflect how open-source development really works, by whether procurement rewards portability and maintained dependencies instead of buying closed platforms while praising sovereignty, and by whether Europe funds the unglamorous work that makes strategic software trustworthy. The visible machinery will stay messy. Policy will keep moving asynchronously, because reality keeps moving asynchronously, and new crises will keep producing new instruments. That is unavoidable, and it is not the test. The test is whether the output becomes coherent enough to carry load.

The windows are open now, all of them at once, which is unusual and will not last. The CRA reporting obligations start on 11 September 2026. The harmonised standards are being drafted, with the first citations expected before the year is out. The Cybersecurity Act revision and the Cloud and AI Development Act are still proposal-level architecture that can be shaped. The Open Source Maintenance Instrument is still under-specified, and the budget window that runs from 2028 to 2034 will decide whether open source remains a thin line item in a strategy document or becomes funded infrastructure. The community shaped the CRA once. It can shape the implementation, the standards and the funding, and the people who show up will determine whether open-source reality is recognised or interpreted by others.

The lesson of GSD, in the end, is the lesson of this entire argument. A community audit with passing tests and no backdoor was not the same as a trustworthy tool, and the only reason anyone could tell the difference was that a second, independent pass was run against the same material. That is what assurance is. It is not a clean scan, which is only a timestamp. It is the discipline of producing, and independently checking, the evidence that lets someone else rely on your work under pressure. Open source has won distribution because it could be used everywhere. It will win the next phase only if it can be trusted everywhere, and trust, when the question finally comes, is simply this: show me the record.

That is sovereign open-source assurance, and building it is the work in front of us.

Source notes for final publication

The published version of this article should carry direct citations or endnotes for the following source families. All were verified against primary or strong secondary sources current to June 2026; the items marked for re-check are those most likely to move before publication.

CRA dates and reporting mechanics. European Commission CRA summary and reporting pages, and the ENISA Single Reporting Platform page, for entry into force (10 December 2024), the 11 June 2026 conformity-assessment-body machinery, the 11 September 2026 reporting obligations, the four reporting clocks, and the SRP operational schedule. Re-check the SRP onboarding status and any final guidance Communication at freeze.
CRA conformity and standards status. The CRA harmonised-standards tracker and the cyberresilienceact.eu guidance summary, for the confirmed position as of early June 2026 that no harmonised standard has been cited in the Official Journal, no notified bodies are designated, and the three-date standards model (two core horizontals targeted 30 August 2026, verticals 30 October 2026, remaining horizontals 30 October 2027). The vertical product categories in mature draft (browsers, password managers, antivirus, VPNs, network management, SIEM, boot managers) are from the Hogan Lovells 2026 readiness note and Honeywell supplier guidance. Re-check the OJ citation status at freeze, and keep EN 40000 subpart identifiers out of the text unless re-verified.
CRA open source and stewardship. European Commission CRA open-source page for the FOSS scope, the steward role and the Article 64(10) fine exemption; the Eclipse Foundation Open Regulatory Compliance Working Group November 2025 steward analysis for the steward-as-bridge nuance; the April 2023 Eclipse-led open letters and the December 2023 political agreement for the community-engagement history.
The seven-foundation specification initiative. Eclipse Foundation April 2024 announcement, for the joint secure-development specification work by Apache, Blender, OpenSSL, PHP, Python, Rust and Eclipse.
The GSD incident. The Open GSD continuity announcement and security-audit material, the independent review of that audit (GitHub Discussion #119), and cautious independent reporting (AI Weekly), for the trust-state-inversion pattern, the registry-key finding, the advisory-only guardrail gaps, and the post-incident hardening. Maintain the wording discipline: the dollar figure and the fraud attribution are not formally confirmed; frame the token event as publicly linked rather than proven.
The underfunding arc. Primary and strong secondary sources for Heartbleed (CVE-2014-0160) and the Core Infrastructure Initiative, Log4Shell (CVE-2021-44228) and the OpenSSF response, and xz-utils (CVE-2024-3094).
Slopsquatting. Trend Micro and Socket research on AI-hallucinated package names as a supply-chain vector.
Maintenance funding. Sovereign Tech Agency statements for the approximately 34 million euros across roughly 95 technologies as of early 2026, and for the curl and KDE Plasma investments; the 2025 feasibility study (OpenForum Europe, Fraunhofer ISI, European University Institute) for the 96 percent codebase figure, the 65 to 95 billion euro annual contribution, the maintainer-funding gap, and the proposed approximately 350 million euro European instrument. Use the live Sovereign Tech Agency total at freeze if a more current figure is available.
Procurement. Interoperable Europe and the Open Source Observatory for the Schleswig-Holstein migration figures (reconcile exact numbers at freeze); standard retrospectives for Munich and the French gendarmerie.
NIS2 and the Cybersecurity Act revision. Directive (EU) 2022/2555 for NIS2; the European Commission cybersecurity-package Q&A for the January 2026 CSA revision proposal. Keep the proposal caveat on the CSA revision, CADA and the Chips Act 2.0.

Uyuni Joins openSUSE Project Ahead of Annual Conference

admin@opensuse.org (Douglas DeMaio) — Mon, 22 Jun 2026 08:00:00 +0000

There are moments in open-source history that feel less like announcements and more like finally saying out loud what everyone already knew.

Eight years ago, during the annual openSUSE conference, the story began on news.opensuse.org with the announcement that Spacewalk was being forked. Today, as we gear up for the openSUSE Conference 2026, that circle is finally closing.

“It was a big moment when we decided to fork Spacewalk and move forward with Uyuni on our own,” said Johannes Hahn, who has been around the Uyuni project since the beginning. “Nowadays, we are still enthusiastic about maintaining the project and about further modernizing and improving it. In practice, we’ve been part of openSUSE for years; the infrastructure, the conferences and the people. Making it official just means everyone else now knows what we already did.”

Members of the project are delighted to share that the Uyuni Project has officially joined the openSUSE Project!

While the people have worked alongside each other since that initial fork, this formal integration marks a major milestone. It makes it easier for new contributors to find their way to Uyuni, gives the community a definitive home, and strengthens openSUSE’s tradition of bringing people together to build powerful, open-source tools that benefit the entire ecosystem.

A Partnership Years in the Making

To understand the significance of this homecoming, it helps to look back at the original fork.

By the mid-2010s, the original Spacewalk project (the foundation for Red Hat Satellite and SUSE Manager, which is now known as SUSE Multi-Linux Manager had reached a turning point. The upstream focus had shifted largely toward maintenance and stabilization. While the wider community remained highly engaged and continued submitting valuable code, many of those external contributions began to sit idle. When it was publicly announced that upstream code contributions would decrease and a call was made for other community members to step up and take over the management role, extensive discussions took place.

Ultimately, the community realized that a fork was necessary to inject new life and inspiration into the project. The goal was never just to maintain the status quo, but to build a collaborative space to innovate together-bringing in a modern React UI, container and Kubernetes integration, and utilizing Salt for configuration management.

To reflect this bold new direction, the project was named Uyuni, after the world’s largest salt flats in Bolivia. It was a nod to Salt, but more importantly, a massive statement of shared ambition.

Upstream First: A Community Without Second-Class Citizens

From the very beginning, Uyuni has been much more than just a codebase. It is a thriving, passionate community of system administrators, developers, and open-source enthusiasts dedicated to solving complex infrastructure challenges together.

While Uyuni serves as the upstream project for SUSE Multi-Linux Manager, its development thrives on a strict “upstream first” philosophy. Let’s be clear: Uyuni is not a stripped-down, feature-limited “free version” of an enterprise product. It is the fully-featured, cutting-edge foundation where every piece of innovation happens first. The project operates on the core principle that the community leads the way, ensuring that everyday contributors drive the project’s future. Everyone sits at the same table and there are no second-class citizens.

The heart of Uyuni is driven by the individuals who contribute code, squash bugs, translate documentation, and help answer each other’s questions in chat channels and forums. Over the years, this collaborative spirit has fostered strong relationships with developers across the open-source spectrum, sharing and receiving contributions with communities like Fedora, Alma Linux, and Rocky Linux.

As a configuration and infrastructure management tool, the code allows us to seamlessly deploy patches, manage configurations, and build containers. But it is the community that ensures the tool remains versatile; it supports a massive range of client systems including openSUSE flavors, SUSE Linux Enterprise Server, Red Hat Enterprise Linux (and its derivatives), Ubuntu, Debian, Amazon Linux, AlmaLinux and more.

Constant Innovation: Uyuni 2026.04

The community’s hard work continues to shine in the most recent release, Uyuni 2026.04. This update brings even more power to the platform by adding full support for RHEL 10 and compatible distributions. It also introduces enhanced security auditing integration and features a brand-new reporting dashboard for Grafana, built by and for the people who use it every day.

Celebrate Together at openSUSE Conference 2026!

Just like the original fork announcement at the 2018 event, this new milestone deserves to be celebrated in person, face-to-face with the people who make it all possible.

The openSUSE Conference 2026 runs from June 25-27 at the Z-Bau in Nuremberg, Germany. Attendance is completely free! People are encouraged to attend the live and virtual Uyuni community hours meeting during the event.

For more information and to register, visit events.opensuse.org. We can’t wait to see you there to celebrate the closing of this circle and the beginning of the Uyuni community’s official next chapter with openSUSE!

Planet News Roundup

admin@opensuse.org (Douglas DeMaio) — Fri, 19 Jun 2026 08:00:00 +0000

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog feed aggregator lists the featured highlights below from June 12 to 18.

Blogs this week cover the release of KDE Plasma 6.7 with per-screen virtual desktops and mic test features, KDE Frameworks 6.27, Agama 22 with redesigned UI and VLAN support, Amarok 3.3.3, syslog-ng 4.12.0, and a Tumbleweed weekly review delivering five snapshots. Also featured are GSoC first contributions, Thunderbird improvements, Symless joining KDE sponsorship, and more.

Here is a summary and links for each post:

The return of the Oxygen theme to Plasma

The KDE Blog goes over the release of Plasma 6.7 on June 16. The Oxygen theme from the KDE 4 era has returned as a full global theme for Plasma 6. What began as a restoration project drew a surprisingly large and positive response and attracted new contributors. Oxygen 6.7 arrives updated for full compatibility with current technologies.

Published Amarok 3.3.3

Victorhck shares an update on KDE’s music player Amarok and explains some of code quality improvements and fixes for compiling across different systems.

Preparing for GSoC: My First Contributions to Autogits

Mario Marín shares his initial contributions to the autogits repository as part of Google Summer of Code 2026. His work on obs-status-service included creating a mock Redis client for local development and testing without requiring a real Redis server, and designing a default service landing page where users can enter OBS project parameters to generate SVG status previews and Markdown snippets. The work reduces infrastructure requirements for new contributors.

If you use KDE in openSUSE16, you can not use RDP

The openSUSE Japanese user group reports that RDP (XRDP) does not work with KDE on openSUSE 16, which defaults to Wayland. The server fails with scp_process_msg failed errors, suggesting compatibility issues between XRDP and KDE on Wayland. Users needing RDP access on openSUSE 16 may need to choose GNOME instead. Meetings related to Leap 16 features and feedback can be found on calendar.opensuse.org.

Lanzado Amarok 3.3.3 «Beyond the clouds»

The KDE Blog celebrates the release of Amarok 3.3.3. The update restores system suspend inhibition during playback, fixes main window layout restoration after restart, resolves context applet height saving issues, prevents duplicate tracks when dragging from file manager to the playlist and more.

Thunderbird will make it easier to collaborate on its Android app

Victorhck reports on the Thunderbird team’s efforts to lower the contribution barrier for their Android and iOS email apps. The team is moving documentation, adding pull request templates including AI usage disclosure fields, and encouraging community involvement through testing pre-release builds, translating, and donating.

Things That Last

Jakub Steiner reflects on longevity and repair culture through a personal story about an annual bike trip to Jakuszyce, Poland. The post contrasts the disposable nature of household appliances with the enduring quality of a well-maintained bicycle that has remained a joy to ride for 15 years, serving as a meditation on what it means to make things last.

Lanzado Plasma 6.7, an exceptional productivity tool

The KDE Blog announces the release of KDE Plasma 6.7 on June 16. Key features include per-monitor independent virtual desktops, a microphone volume testing tool, virtual keyboard special character long-press input, a quick light/dark theme toggle, Vietnamese lunar calendar integration and much more.

syslog-ng 4.12.0, syslog-ng PE 8.2.0 and SSB 7.8.0 are now available

Peter Czánik announces coordinated releases across the syslog-ng product line driven by an SQL injection security fix. syslog-ng OSE 4.12.0 brings performance optimizations making the log processor more scalable, along with numerous user-reported bug fixes.

Releasing version 22

The Agama Installer team announces Agama 22 with a redesigned header and toolbar that improves navigation with persistent product logos, breadcrumbs, and relocated installer tools. New features include configurable appearance with dark and light themes, advanced filesystem configuration options in the disk setup UI, VLAN connection support through the web interface and more. A new access section in JSON configuration simplifies setting up SSH or Cockpit on the installed system.

The KDE Blog presents Tiled Menu Prime, the 32nd entry in the Plasma 6 plasmoid series. The Windows 10-style start menu replacement supports pinned applications, resizable tiles in multiple sizes (1x1, 2x2, 4x4, and more), customizable sidebar shortcuts, and letter-jump navigation. It is based on the work of Zren’s original Tiled Menu plasmoid.

Add a keyword so Thunderbird reminds us if we want to add an attachment

Victorhck shares a practical tip for Thunderbird users with customizing attachment reminder keywords. By navigating to Settings → Composition → Attachments, users can add new trigger words like “attached” to ensure Thunderbird prompts them before sending an email without an intended file.

Improvements to stay in the loop

The OBS blog presents two small improvements aimed at helping users stay on top of their workflow. Notification filters are now preserved when returning to the notifications list, so users sifting through large volumes of notifications no longer lose their narrowed-down view. Additionally, global role changes now trigger notifications: users are alerted when one of their global roles is assigned or revoked, and other members of the affected role are notified of the change as well.

The KDE Blog announces that Symless, the company behind the Synergy software for sharing a single keyboard and mouse across multiple computers, has joined the KDE sponsorship program. The sponsorship supports KDE’s ongoing development and community initiatives.

Introducing pkgcli: A nicer command-line interface for PackageKit

Matthias Klumpp introduces pkgcli, a new command-line client for PackageKit built to replace the long-stagnant pkcon tool. Developed as part of his work as a fellow for the Sovereign Tech Agency, pkgcli aims to be pleasant for interactive use and easy to script.

Linux Saloon 207 | LibreWolf Web Browser

Nathan Wolf recaps a Linux Saloon episode that opens with Mike (FullScale4me) discussing older computer systems and “Big Iron.” The panel shares thoughts on LibreWolf, concluding it suits privacy-focused users who prioritize security but may not be ideal for casual users. The conversation about privacy gets passionate, and a little spicy.

Linux Saloon 206 | Early Edition

Nathan Wolf previews a Saturday tech-focused session covering open source, gaming, and Linux. Key topics include the compromise of Arch Linux AUR packages and deprecated Linux commands.

Plasma 6.7 is very close – This Week in Plasma

The KDE Blog translates the “This Week in Plasma” report released ahead of the Plasma 6.7 launch. The preview highlights per-screen virtual desktops, a microphone volume test tool, virtual keyboard special character input by long-press, a quick theme switcher between light and dark modes and more.

Twenty-seventh update of KDE Frameworks 6 and KCalendarCore library

The KDE Blog announces the 27th update of KDE Frameworks 6, which arrived in Tumbleweed on June 16. The release spans all major framework modules with bug fixes across KIO, KConfig, KTextEditor, and Kirigami. The post also profiles the KCalendarCore library, which powers calendar functionality across KDE applications.

Tumbleweed – Review of the Week 2026/24

Victorhck and Dominique Leuenberger report on a productive week with five Tumbleweed snapshots (0604, 0605, 0608, 0609, 0610). Key updates included Linux kernel 7.0.11, Mesa 26.1.2, fontconfig 2.18.0/2.18.1, harfbuzz 14.2.1, PHP 8.5.7, KDE Gear 26.04.2, Mozilla Firefox 151.0.3 & 151.0.4, sqlite 3.53.2, systemd 260.2, and file 5.48. Staging highlights include MariaDB 12.3.2, KDE Frameworks 6.27, Linux kernel 7.0.12, KDE Plasma 6.7.0, Poppler 26.06.0, QEMU 11.0.0 dropping 32-bit host support, and GCC 16 as the system default compiler.

View more blogs or learn to publish your own on planet.opensuse.org.

Planet News Roundup

admin@opensuse.org (Douglas DeMaio) — Fri, 12 Jun 2026 06:00:00 +0000

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog aggregates a list of the featured highlights below from June 5 - 11.

Blogs this week cover a photographer pairing rival AMD and Nvidia GPUs on one openSUSE Leap 16.1 workstation to run Adobe software in a virtual machine, a guide for open-source maintainers on avoiding burnout amid a flood of AI-generated security reports, the release of digiKam 9.1 and second bugfix updates for both KDE Gear 26.04 and Kdenlive. Blogs also highlight a dystopian short story about a web where nothing is free, a talk by KDE e.V. in Barcelona, a Digital Sovereignty event in València, the weekly Tumbleweed snapshot reviews, Plasma 6.7 bugfixing and more.

Here is a summary and links for each post:

The openSUSE News team profiles photographer Klaus Tröger, who recently migrated to the openSUSE Leap 16.1 beta. It talks about the use of Adobe and Photoshop in a Windows 11 virtual machine on a workstation. Performance is nearly native and the passthrough components can be cleanly isolated by IOMMU group.

Digital Sovereignty in the AI Era, New Event Organized by GNU/Linux València

The KDE Blog promotes a new event from the nonprofit association GNU/Linux València titled “Digital Sovereignty in the AI Era,” which takes place June 16 at the Universitat de València. Attendance is free, can be joined online and the session will offer concrete alternatives for regaining technological autonomy.

digiKam 9.1 Released, Making it Easier to Use

The KDE Blog covers the release of digiKam 9.1.0, which arrives after three months of active development focused on database migration, preview improvements, advanced search and general ease of use. The post also recaps the major features of digiKam 9.0 for readers who missed the previous release.

Welcome to the Icon Designer Webring!

Jakub revives a piece of 1990s internet culture. Inspired by Terry Godier’s essay “The Boring Internet,” the post argues that an older, slower, federated web built on open protocols still thrives beneath the commercial layer.

Thirty-Fourth Audio of Podcast Linux – “Maratón Linuxero Live” (Podcast Linux #34)

The KDE Blog continues its index of the now-paused Podcast Linux with episode 34. Host Juan Febles chats with four GNU/Linux veterans Gabriel Viso, Patricio García, Alejandro López and Roberto Ruisánchez about the early days of Linux. The conversation revisits the 1990s and early 2000s.

Kdenlive 26.04.2 Released

The KDE Blog announces the second maintenance release of the Kdenlive 26.04 series. The update fixes issues in rendering, timeline editing and project file management across AppImage and Flatpak packages, including a notable Windows fix that allows exporting videos to a network drive.

Everything Has a Price

Victorhck publishes a Spanish translation of Paul Brown’s dystopian short story “No Such Thing as a Free Lunch,” which is a cautionary tale about a future where every click, app launch and settings change carries a fee and free offerings are outlawed. The fiction follows Joe Bloggs through a world of mandatory hardware upgrades, surveillance AI that taxes productivity and brutal enforcement of software regulations. The story is free to read, which in the tale would be a felony.

Fixing All the Things – This Week in Plasma

The KDE Blog translates the latest “This Week in Plasma” report, which focuses on polishing Plasma 6.7 ahead of its release at the end of the month. Notable fixes include Spectacle’s clipboard behavior during OCR text extraction, low-battery notifications for connected devices appearing over fullscreen apps, and a crash fix when refreshing the list of nearby wireless networks.

Linux Saloon 205 | Open Mic Night

CubicleNate recaps episode 205 of the Linux Saloon podcast. Responding to viewer feedback, the panel shared what they like and dislike about their distributions of choice, covering Tumbleweed’s built-in Snapper rollback and overly aggressive default firewall, a panelist’s switch from GNOME to the Fedora 44 Plasma spin, and praise for MX Linux, CachyOS, Linux Mint and Bazzite, before agreeing to test the LibreWolf browser in an upcoming application appetizer segment.

BuildStream and KDE – New Barcelona Free Software Talk

The KDE Blog announces a new Barcelona Free Software talk taking place on Thursday, June 11 at Akasha Hub in Barcelona. Aleix Pol, president of KDE e.V., will present BuildStream, a powerful software integration tool used to build operating systems and all sorts of packages. Attendees will leave knowing how to build their own operating system and hopefully be ready to contribute to many more projects.

Tumbleweed – Review of the Week 2026/23

Victorhck and Dominique Leuenberger report that Tumbleweed kept rolling through a midweek European holiday with six snapshots published. Key updates included Mesa 26.1.1, Qt 6.11.1, GNOME 50.2, Pipewire 1.6.6, Samba 4.23.8 and 4.24.3, plus a Java packaging migration from update-alternatives to libalternatives. The staging dashboard predicts Linux kernel 7.0.11, KDE Plasma 6.7.0, a rework of Python3 packaging and GCC 16 as the system default compiler arriving soon.

Take it Easy. A Guide to Avoid Burnout During the Vulnpocalypse

Danigm offers open source maintainers a survival guide for the so-called Vulnpocalypse, which refers to the cybersecurity reckoning related to AI-generated security reporting. The post argues that 100 percent secure software doesn’t exist, that the deluge of dubious “high severity” reports is eroding CVE credibility, and that maintainers should learn to recognize and disarm manipulation tactics like queue flooding and gaslighting rather than burn themselves out chasing every cried wolf.

Second Update of KDE Gear 26.04

The KDE Blog highlights KDE Gear 26.04.2. The release resolves a good number of errors across applications, libraries and widgets, including a crash in Akregator on arm64, a startup crash in Skanlite via ksanecore, and a fix for Koko’s move-to-trash action overriding the editor’s delete actions.

View more blogs or learn to publish your own on planet.opensuse.org.

Rival GPUs Share One Linux Desktop

admin@opensuse.org (Douglas DeMaio) — Thu, 11 Jun 2026 11:00:00 +0000

For years, photographer Klaus Tröger built his professional workflow on a quiet contradiction; a Linux workstation running the Adobe software that most people assume belongs on a Mac or a Windows PC.

“I’m not willing to give up Linux, and I’m not willing to give up Adobe,” Klaus said. “So I stopped choosing.”

He has now carried that arrangement onto newer ground. Klaus recently migrated his longtime Debian machine to the beta release of openSUSE Leap 16.1 and has kept editing the whole time, running Adobe Lightroom, Camera Raw and Photoshop inside a Windows 11 virtual machine that never touches the local network directly.

The setup speaks to a small but persistent group of professionals who prefer Linux as their daily environment but cannot abandon Adobe Creative Cloud, whether for client work or long-established editing habits. Open-source alternatives exist, Klaus acknowledges, but they do not always fit an established business.

The hardware behind the system is deliberately dated, and Klaus says that is the point. Rather than chase current components at current prices, he chose Intel’s older LGA-1151 platform, pairing a Core i9-9900K, which is an eight-core, 16-thread chip from Intel’s Coffee Lake generation, with an Asus Z390 WS Pro mainboard. Each was a flagship in its day, he said, delivering strong benchmark performance from the processor and stability from the board. Because the WS Pro has grown rare and expensive, he notes the same approach works with a more common Asus ROG-STRIX Z390-F board and a six-core Core i7-8700K.

The board matters less for speed than for separation. To hand physical hardware to the virtual machine, Klaus relies on the Linux “vfio-pci” driver, which requires that the devices being passed through sit in their own IOMMU group, which is the system the hardware uses to isolate components from one another.

That requirement produces the workstation’s most surprising feature; two graphics cards from rival makers. An AMD Radeon RX 6600 drives the Linux desktop, while an Nvidia RTX 3060 is dedicated entirely to Windows. Contrary to a common assumption, Klaus said, modern Linux handles mixed AMD and Nvidia setups without conflict.

A dedicated graphics card is not optional for the Windows side. Adobe’s software needs a real GPU for post-processing. Software emulation will not do, and the card must clear a modest bar; it needs 1.5 to 2 GB of video memory, DirectX 12 compatibility and a driver no more than seven years old. Passing a qualifying card through to the Windows guest, in its own IOMMU group, lets Adobe applications run with near-native hardware acceleration while Linux remains in charge.

Most consumer mainboards make that separation difficult, Klaus said, because of how they share PCIe lanes and assign IOMMU groups. He offers two ways around it: use the Intel chip’s integrated graphics for the Linux host, the simplest and cheapest option for users with light rendering needs; or run two cards, placing the primary GPU in the CPU-managed first PCIe slot and the pass-through card in a slot managed by the Z390 chipset, which lands them in separate groups.

The rest of the machine follows the same divide-and-isolate logic. A separate USB controller goes to the virtual machine so Windows can have its own keyboard and mouse. Windows lives on its own fast NVMe solid-state drive. Klaus pins 10 processor threads to the host and six to the guest, splits 64 GB of memory evenly between them using huge pages, and swaps the default power daemon for the “tuned” tool set to a virtual-host profile.

He made one deliberate exception. Rather than assign the second NVMe drive straight to Windows, he keeps the guest in a disk-image file on an XFS partition.

“It’s so easy to just copy away the Windows file to get a backup,” he said.

The choice of host operating system was its own deliberation. Klaus had run Debian 13 for its stability. He found openSUSE’s rolling Tumbleweed release too bleeding-edge and Leap 15.6 too dated, which left the Leap 16.1 prerelease as a chance worth taking. The installation, using the Agama installer with an LVM disk layout and a Btrfs root filesystem for snapshots and rollback, produced what he called “zero surprises.”

Performance, he said, is nearly native. Virtualization always carries some overhead, “but it’s fully worth it.” Security is part of the appeal. Windows never sits directly on the local network; it operates behind the Linux host, shielded by the host firewall and additional controls. The arrangement, Klaus said, balances compatibility against exposure. Windows stays available for the few applications that demand it, while Linux runs everything else.

Asked what he would change if he built the machine today, Klaus did not hesitate. “None,” he said. His advice for photographers and power users eyeing a similar build comes down to one decision made early; choose the base hardware carefully, and confirm before buying that the components you intend to pass through can be cleanly separated by IOMMU group. Consumer boards, he warns, often cannot.

openSUSE Asia Summit 2026 Logo Competition Announcement

admin@opensuse.org (openSUSE Asia Summit Team) — Thu, 04 Jun 2026 17:30:00 +0000

openSUSE.Asia Summit 2026 Logo Competition

We are excited to announce the launch of the openSUSE.Asia Summit 2026 Logo Competition!

The Summit logo is more than just a symbol—it represents the energy, creativity, and diversity of our openSUSE community across Asia. This year, we invite you to make history by designing a logo that will become the face of the 2026 Summit.

The Summit will take place at the Teaching Industry Learning Center (TILC), Vocational School, Universitas Gadjah Mada (UGM), Yogyakarta. More event details will be shared soon. The logo competition is now open and will close on 21 July 2026. The winner will receive a special “Geeko Mystery Box” from the organizing team!

Submission Deadline: 21 July 2026 Winner Announcement: 3 August 2026

Contest Guidelines

License: The logo must be licensed under CC-BY-SA 4.0 and allow everyone to use it without attribution if selected. Attribution will be displayed on the Summit website.
Originality: Your design must be original and free from third-party materials
AI: AI generated content is strictly prohibited.
Formats: Submit both monochrome and color versions.
File Format: Only SVG files are accepted.
Community Spirit: The logo should reflect the openSUSE community in Asia.
Prohibited Elements: Do not include trademarks, inappropriate or offensive content, violence, discrimination, political or religious imagery, or any content violating openSUSE values.
Trademark: Follow the openSUSE Project Trademark Guidelines.
Branding: Refer to the openSUSE branding guidelines for inspiration (optional).

How to Submit

Send your design to opensuseasia-summit@googlegroups.com with the following details:

Email Subject: openSUSE.Asia Summit 2026 Logo Design - [Your Name]

Attachments:

Vector File: The logo in SVG format ONLY (Refer to template in Figure 1).
Bitmap File: A PNG version (minimum 256x256 pixels).
Design Philosophy: A short TXT or PDF document explaining your concept.
File Size: Ensure all files are under 512 KB.

Figure 1. Sample SVG Template for the logo

All submissions will be reviewed by the Summit Committee. Note: The final decision will be made by the committee and may not necessarily be the highest-voted design.

Tip: Use Inkscape, a free and open-source vector design tool!

Let your creativity shine and help shape the identity of openSUSE.Asia Summit 2026. Good luck!

TSP Open for Asia Summit

admin@opensuse.org (Douglas DeMaio) — Wed, 03 Jun 2026 11:00:00 +0000

The Travel Support Program (TSP), which is aided through donations to the Geeko Foundation, is now accepting applications for the openSUSE.Asia Summit 2026.

Funds are allocated by the foundation specifically for travel assistance for speakers attending the event.

Applications for the TSP are open now and will run until July 31, which will follow an announcement related the Call for Papers.

People whose talks are accepted can submit a request at tsp.opensuse.org.

The TSP exists to ensure financial constraints don’t prevent passionate contributors and community members from participating.

The openSUSE.Asia Summit 2026 organizers of the summit encourage you to apply early.

For questions about the TSP process, visit the wiki for more information and read the Geeko Foundation’s travel policy.

Further details will be shared later about the event planning, so please pay attention to announcements for the summit.

We look forward to seeing you there!

For more details on openSUSE.Asia Summit 2026, visit events.opensuse.org.

Tumbleweed Monthly Update - May 2026

admin@opensuse.org (Douglas DeMaio) — Mon, 01 Jun 2026 11:00:00 +0000

May delivered a steady cadence of openSUSE Tumbleweed snapshots across the major desktop stacks with KDE Gear 26.04.1, KDE Frameworks 6.26.0, Plasma 6.6.5 and GNOME 50 minor releases. Mesa made a couple leaps with the 26.1 series with the new Vulkan 1.4 Application Programming Interfaces, and the Linux kernel progressed from 7.0.5 through 7.0.9 with significant security and driver fixes. Sysadmins received a major AppArmor 5.0 release and a fresh Apache HTTP Server 2.4.67 carrying many Common Vulnerability and Exposure fixes.

Other notable bumps include libusb 1.0.30, GnuPG 2.5.20, LibreOffice 26.2.3.2, PostgreSQL 18.4, rsync 3.4.3, poppler 26.05.0, and Expat 2.8.1.

Security received heavy attention with Apache HTTP Server, PostgreSQL, rsync, dnsmasq, jq, PHP, OpenEXR, and the Linux kernel all receiving multiple CVE fixes.

As always, be sure to roll back using snapper if any issues arise.

For more details on the change logs for the month, visit the openSUSE Factory mailing list.

New Features and Enhancements

KDE Gear 26.04.1: Akonadi fixes a crash in EntityTreeView when selecting multiple items, and KOrganizer resolves black squares in the todo view and re-enables icons in monthview. Dolphin refines the selection panel and search popup behavior. Kate restores middle-click closing of tabs when the close button is disabled, Konsole prevents QTabBar from closing tabs on stray middle clicks, and Okular hardens fax handling against malformed .g3 inputs. Umbrello gets six bug fixes including diagram-load and Qt6 configuration crashes, and Itinerary adds new Condor PKPass and monbus.es ticket extractors.

KDE Frameworks 6.26.0: KIO adds the Startpage search provider, expands KFilePlacesModel with kdeconnect device support, gains MIME-type detection from text content in the paste flow, and exposes the current folder in the file widget placeholder. KCoreAddons introduces KAboutRelease for listing application release notes, parses AppStream release notes, and switches to libmount for filesystem-type detection where available. KImageFormats corrects EXR loading from Photoshop 2026 saves, plugs JXR memory leaks, and improves EXIF handling. KHolidays introduces HolidayCategories and fixes Philippines Easter holidays.

Plasma 6.6.5: KWin gains numerous DRM backend fixes including correctly updating outputs only on changed GPUs, preserving custom output modes across reboots, setting full color range for RGB planes on NVIDIA, and avoiding multi-GPU copies with unsupported formats. Input handling is hardened by mapping devices to device outputs (not logical ones), processing key repeat before the accessibility monitor, and cleaning up keyboard grabs on shutdown. KScreen hides the DDC/CI option when HDR is enabled and prevents off-by-one gaps when creating replicas. Discover corrects text color inversion in ProgressView, and Plasma Workspace fixes klipper clipboard updates, lockscreen timezone init races on multi-screen, and broken text legibility with the Air and Breeze Light themes. Spectacle keeps the application alive briefly after copying screenshots and fixes magnifier activation during hover events. PowerDevil addresses screen brightness getting stuck at 30 percent after a restart.

GNOME 50.1 and 50.2: These point releases bring stability and usability fixes across the GNOME desktop. GDM 50.1 fixes a failure to properly terminate conflicting graphical sessions started outside of GDM (such as ThinLinc or TigerVNC) by querying logind directly, and resolves Plymouth hanging indefinitely on headless systems or those without monitors. A bug incorrectly setting XDG_SESSION_TYPE=wayland on X11 sessions was corrected, along with XDG_DATA_DIRS construction that could prevent GNOME Shell from finding its files. GNOME Shell 50.2 fixes extending screenshot area selection to monitor edges, adds rate control to VA-API H.264 screencast pipelines, and restores the “Install Updates” checkbox in the power-off/restart dialog. Autorun notifications for USB drives, spinner resets during overview search, and wiggle feedback on non-password auth failures are all corrected, and the audio input icon now only appears when actually recording. GNOME Control Center 50.2 fixes the “Show Content” notification setting, relaxes app-id validation for Global Shortcuts, and improves mobile-width label fitting in Device Security and Wellbeing panels. GNOME Session 50.1 fixes a double-free bug. For Tumbleweed users, these updates improve login reliability, screencast quality, and overall GNOME desktop polish.

KDE Network File Sharing 26.04.0: This update refactors the file properties plugin initialization and now automatically enables and starts the Samba service if needed when sharing folders. Service aliases are handled correctly, the user list in combo boxes is clipped with scrolling disabled for better usability, and a regression in smbd path lookup was fixed.

AppArmor 5.0.0: This major version bump from the 4.1 series is a significant milestone for the mandatory access control framework. The release modernizes the parser and userspace utilities, adopts a new ABI abi/5.0, and introduces broader profile updates. Profiles for samba, dovecot, postfix, wpa_supplicant, and syslog-ng are refined to better handle modern filesystem layouts. The full upstream changelog is available at the AppArmor 5.0 release notes wiki.

GnuPG 2.5.20: This update implements GCM encryption in gpgsm (decryption was already supported in earlier versions), adds the --attribute option and SETATTR server command for including arbitrary signed or unsigned attributes in signatures, and introduces a new system attribute _signingCertificateV2. A possible double free in the CMS parser is fixed, along with a buffer overflow in scdaemon when handling SC-HSM cards with RSA keys larger than 2 kilobits. Several agent and keyboxd fixes correct loopback pinentry caching and PUT_SECRET input handling.

libusb 1.0.30: This update introduces new APIs libusb_get_device_string() and libusb_get_session_data() for accessing device strings without opening the device and retrieving OS-specific handles. Device removal races on non-hotplug builds are fixed and descriptor parsing memory safety is improved.

poppler 26.05.0: This jump from 26.02.0 rolls up three upstream releases. The release improves reconstruction of damaged files, fixes crashes in malformed documents, and removes the PSOutputDev “pipe as filename” feature for security reasons. pdftotext gains a -remove-hyphens option and no longer aborts on empty strings. The qt5/qt6 search APIs receive a fix for inverted continuation rectangles, and the GPG signature backend correctly marks qualified keys.

gpg2 and libksba 1.8.0: The S/MIME-related X.509 and CMS support library jumps from 1.6.8 to 1.8.0. New functions include ksba_cms_add_attribute and ksba_cms_get_attribute, support for building AuthEnvelopedData, and corrections to silent truncation of 64-bit length fields and overflow guard conditions in _ksba_ber_read_tl.

open-vm-tools 13.1.0: This major version bump introduces support for GTK4 alongside continued GTK3 compatibility. The configure script accepts options to restrict the build to either toolkit; otherwise it picks the latest available. Several upstream GitHub issues are resolved as documented in the 13.1.0 Release Notes.

fwupd 2.1.3: This update for the firmware update daemon continues to add features and hardware coverage. New capabilities include Redfish bearer token authentication, support for several XMC SPI chips, parsing of JCat files without libjcat, native CBOR parsing (dropping libcbor2 as a dependency), and an HSI check for AMD SB-7033 (a.k.a. EntrySign). The earlier 2.1.2 release also added native EFI authenticated variable loading with ContentInfo headers and decompression-ratio limits to prevent ZIP-bomb-style emulation parsing. New hardware support spans the SHIFT6mq, SHIFTphone 8, Google Moonstone, Lenovo USB-4 dock, HP 400/405 Mouse, Parade USB hubs with GPIO control, Pixart PLP239 devices, Raydium TP devices, Sunplus cameras, and the LX Semicon SW42101 touch controller.

python-cryptography 48.0.0: A major version bump that drops Python 3.8 support and changes X.509 CRL parsing so that a mismatched inner TBSCertList.signature and outer signatureAlgorithm raises a ValueError. ML-KEM and ML-DSA are now supported when building against OpenSSL 3.5.0 or later (in addition to AWS-LC and BoringSSL), bringing post-quantum algorithms to upstream wheel users.

Key Package Updates

Linux Kernel 7.0.9: The kernel progressed through 7.0.5, 7.0.6, 7.0.7 and 7.0.9 during the month, accumulating a substantial pile of security and stability fixes. The 7.0.5 release fixed a buffer overflow in vrealloc_node_align() along with a deadlock in mmap_prepare error handling when holding rmap. The crypto subsystem received extensive fixes including memory leaks in atmel-aes, ccree, and nx842, a use-after-free in atmel-sha204a removal, and short digest rejection in authencesn. netfilter rejects zero shifts in nft_bitwise, and IPsec (xfrm) avoids in-place decryption on shared skb fragments. NTFS3 receives integer overflow and buffer boundary checks in run_unpack(), and EROFS fixes an unsigned underflow in LZ4 overlap handling. The 7.0.6 follow-up added an rxrpc fix for DATA/RESPONSE packets when paged frags are present and an ALSA fasync state-check serialization. The 7.0.7 release brought multiple CVE fixes detailed below, scsi target configfs bounds tightening in snprintf(), ipmi event/receive message limits, KVM x86 shadow-paging use-after-free protection, smbdirect MR registration fixes for coalesced SG lists, and many wifi mt76 fixes for mt7921/mt7925. The 7.0.9 jump adds HID fixes (PlayStation num_touch_reports clamp, appletb-kbd UAF on inactivity-timer cleanup, pidff integer overflow), drm/gpusvm correctness fixes, and many spi controller deregistration fixes.

curl 8.20.0: This release addresses half a dozen security vulnerabilities. RTMP support is dropped entirely and SMB support is now opt-in. A new thread pool and queue system was added for async resolution, and HTTPS DNS record resolution is made more reliable. Credential handling is hardened across redirects, with digest nonces cleared on cross-origin redirects and proxy credentials cleared on port or scheme changes. The alt-svc and HSTS lists are now capped (at 5,000 entries) and expired entries are skipped when reading from file. HTTP/2 now prevents secure schemes being pushed over insecure connections, and MIME processing limits nesting to 40 levels.

GnuTLS 3.8.13: This major security release addresses more than a dozen vulnerabilities. Three high-severity DTLS reassembly issues are fixed. Medium-severity fixes address a use-after-free in gnutls_pkcs11_token_set_pin(), an overread in RSA key exchange with PKCS#11 keys, CN fallback suppression issues with URI/SRV SANs, and intersecting empty name constraints. Lower-severity fixes cover a multi-entry OCSP response revocation bypass, a timing side-channel in PKCS#7 padding removal, and an off-by-one in PKCS#12 bag bounds checking. HPKE (Hybrid Public Key Encryption, RFC 9180) is available as a technology preview, ML-DSA public key derivation from expanded private keys (RFC 9881) is supported, and building with Nettle 4.0 is now possible. TLS 1.3 client certificate selection is fixed for servers advertising only rsa_pss_rsae_* algorithms, and kTLS ChaCha20-Poly1305 IV handling is corrected for TLS 1.2.

GLib 2.88.1: This update fixes a miscompilation with GCC 16 caused by incorrect function attribute usage. A flag confusion security issue in GRegex when using G_REGEX_RAW is resolved, which could result in unbounded out-of-bounds heap reads off the start of a regex input string. Various minor security issues are also addressed, typically involving small out-of-bounds reads or scenarios relying on discouraged P2P D-Bus configurations.

SQLite 3.53.1: The recovery extension is hardened against SQL injections from the sqlite_schema table of databases being recovered. A crash in sqlite3_deserialize() when overwriting a database with an open transaction is fixed (a bug dating back to version 3.23.0). A single-byte out-of-bounds read in the session module when concatenating patchsets is corrected. The EXISTS-to-JOIN optimization receives fixes for OR-optimization early-exit logic and OFFSET clause handling. A printf() optimization regression causing sqlite3_snprintf() to incorrectly truncate floating-point conversions is resolved, and sqlite3_str_free() no longer crashes when called on objects returned after an out-of-memory condition.

Mesa 26.1.0 to 26.1.1: Version 26.1.1 fixes RADV sample shading with required sample-shaded inputs, VRS with mipmaps on GFX10.3, acceleration structure copies with DAC, and enables a VM map update workaround for Forza Horizon 6. ANV (Intel) adds a SIMD32 requirement heuristic for Dragon Dogma 2, fixes usage flags not propagated to ISL for explicit layouts, bumps the max compute workgroup count, and corrects timebase scale precision loss across 2^32 ticks. The Vulkan 1.4 API is now implemented, with support varying by driver with version 26.1.0. Experimental support for Intel Nova Lake P hardware is introduced. Zink now supports OpenGL ES 2.0 on PowerVR GPUs, expanding its reach to embedded hardware. New Vulkan and OpenGL extensions are supported across drivers including VK_EXT_present_timing, GL_NV_timeline_semaphore (RadeonSI), VK_QCOM_image_processing (Turnip), VK_KHR_present_id, and VK_KHR_present_wait. Rusticl (OpenCL) now requires a static C++ standard library. The update delivers broader Vulkan support, improved virtualization performance, and expanded hardware compatibility.

GStreamer 1.28.3: A bugfix release with security fixes across the framework. Highlights include applemedia vtdec stability, MoltenVK integration and planar video format handling fixes, an audioresample regression fix on armv7hf, bpmdetect corrections for stereo and multi-channel modes, and webrtcsink support for the imx8mp vpuenc_hevc H.265 encoder. Codec parsers receive multiple hardening fixes including a stack buffer overflow in the H.265 buffering period SEI parser, bounds checks in MPEG-TS PES header parsing, and a heap buffer overflow in MXF AES3 audio descriptor write_tags. The mxf and mpegtsdemux plugins receive numerous additional bounds and overflow fixes, and pngparse gets a use-after-free fix. Several memory leaks across decodebin2, subparse, samiparse, baseparse, and others are also addressed.

expat 2.8.1: This update jumps from 2.7.5 and addresses two security issues. A quadratic-runtime attack via attribute name collision checks is corrected, and the SipHash-based hash flooding protection now uses the full 16 bytes of salt instead of 4 to 8. The existing XML_SetHashSalt API is deprecated and a new XML_SetHashSalt16Bytes is introduced for callers that want to provide their own high-quality entropy.

rsync 3.4.3: A security-focused release fixing six CVEs in the file-synchronization tool. Three of the six (CVE-2026-29518, CVE-2026-43617, CVE-2026-43619) require non-default daemon configurations, two (CVE-2026-43618, CVE-2026-43620) are reachable from normal pulls or normal authenticated daemon connections, and the sixth (CVE-2026-45232) requires RSYNC_PROXY to be set with a pathological proxy response. Detailed CVE notes appear in the security section below. The release also adds defence-in-depth hardening on adjacent paths and fixes a regression introduced by the 3.4.0 secure_relative_open().

PostgreSQL 18.4: This point release of the database addresses 10 CVEs covering schema privilege checks, integer overflows in memory allocation calculations, time-zone name handling, path traversal in pg_basebackup and pg_rewind, subscription-name quoting in pg_createsubscriber, marking PQfn() as unsafe, timing-safe string comparisons in authentication, recursion limits in startup packet processing, MCV statistics validation, SQL injection protection in contrib/spi, and quoting of object names in logical replication origin checks. See the official 18.4 release announcement for full notes.

dnsmasq 2.92rel2: A security-focused point release fixing six CVEs in the DNS and DHCP server. Vulnerabilities include cache poisoning that could enable DoS or attacker redirection, DNSSEC validation flaws, a heap out-of-bounds read in DNSSEC validation, a heap out-of-bounds write in DHCPv6 handling, an information disclosure flaw allowing source-check bypass, and a buffer overflow in extract_addresses().

ImageMagick 7.1.2.23 and 7.1.2.24: The 7.1.2.24 version strengthens input validation by rejecting MTV, TGA, Cineon, and Farbfeld image files with zero columns or rows, preventing potential crashes or undefined behavior from malformed files. A new profile fuzzer is added for raw EXIF, XMP, IPTC, and ICC parsing to improve robustness. The 7.1.2.23 version rolls up many GitHub security advisories from upstream and applies an integer overflow fix tracked as CVE-2026-31853.

OpenEXR 3.4.11: A double update from 3.4.9 through 3.4.10 to 3.4.11 closes several additional CVEs in the EXR image format library. Fixes address a shift exponent overflow in readVariableLengthInteger(), an out-of-bounds read in IDManifest::init() during prefix expansion, an integer overflow in ImageChannel::resize, a signed integer overflow in ht_undo_impl() in the HTJ2K decoder, and two missed variants of the earlier DWA-decoder pointer arithmetic overflow.

ncurses 6.6.20260516: Two snapshot patches bring loop limit corrections in lib_twait.c, magic-cookie initialization deferral, terminal database refinements for kitty, contour, screen4/screen5, xterm-utf8, and warp, and a recur_wgetnstr() buffer limit correction.

hplip 3.26.4: A new release of the HP Linux Imaging and Printing project adds support for a broad range of new printers including the HP LaserJet Pro MFP 3106sdw/3105sdw, OfficeJet Pro 9730/9720/8130/8120 series, Envy 6500 series, and several DeskJet Ink Advantage models.

Vulkan SDK 1.4.350: Both vulkan-loader and vulkan-tools jump from 1.4.341 to 1.4.350. vulkaninfo now enables the device groups extension and checks extensions before querying properties, and a wrong extension being used for GGP is corrected.

Security Updates

net-tools 3.14~alpha:

CVE-2024-58251: Fixes a flaw in netstat where a local user could launch a network application and cause a denial of service by locking up the terminal of a victim viewing netstat output.

curl 8.20.0:

CVE-2026-4873: Addresses a flaw where a connection requiring TLS could incorrectly reuse an existing unencrypted IMAP, POP3, or SMTP connection from the pool and cause the subsequent data to be transmitted in clear-text.
CVE-2026-5545: Resolves a vulnerability where HTTP Negotiate connections could be wrongly reused and potentially lead to authentication bypass.
CVE-2026-5773: Fixes a flaw where SMB connections could be reused for transfers to a different share on the same server and potentially lead to the wrong file being downloaded or uploaded.
CVE-2026-6253: Addresses a credential leak where proxy credentials could be exposed across a redirect to a different proxy.
CVE-2026-6276: Resolves a cookie leak caused by stale custom cookie host handling on subsequent requests.
CVE-2026-6429: Fixes a .netrc credential leak when a proxy connection was reused across requests.

update-alternatives 1.22.22:

CVE-2026-2219: Addresses a flaw that could result in denial of service via an infinite CPU-spinning loop.

GnuTLS 3.8.13:

CVE-2026-33845: Resolves an integer underflow that could lead to an out-of-bounds read and potential denial of service or information disclosure.
CVE-2026-42009: Fixes a flaw potentially triggering undefined behavior.
CVE-2026-33846: Addresses a heap buffer overflow that may allow remote denial of service or memory corruption.
CVE-2026-42010: Resolves an authentication bypass in servers configured with RSA-PSK where usernames containing NUL characters wrongly matched ones truncated at the NUL.
CVE-2026-3833: Fixes a name-constraint bypass that could cause certificates that should be rejected to be accepted.

mariadb 11.8.6:

CVE-2026-32710: Addresses a heap-based buffer overflow that allows an authenticated user to crash the server and potentially achieve remote code execution.

krb5:

CVE-2026-40355: Resolves a NULL pointer dereference that allowed an unauthenticated remote attacker to terminate the process when a NegoEx mechanism was registered.
CVE-2026-40356: Fixes an integer underflow that could allow an unauthenticated remote attacker to trigger an out-of-bounds read of up to 52 bytes and potentially terminate the process.

libsndfile:

CVE-2026-37555: Addresses an integer overflow that could lead to a heap buffer overflow or denial of service.
CVE-2025-52194: Resolves a buffer overflow that could potentially lead to memory corruption or code execution.

qt6-svg:

CVE-2026-6210: Fixes a type confusion and heap buffer overflow that results in an application crash.

tar:

CVE-2025-45582: Addresses a directory traversal flaw that allows file overwrite bypassing the standard ../ protection.

Apache HTTP Server 2.4.67:

CVE-2026-34059: Fixes a heap over-read and memory disclosure in mod_proxy_ajp in ajp_parse_data().
CVE-2026-34032: Addresses a heap buffer over-read in ajp_msg_get_string() due to a missing null-termination check.
CVE-2026-33857: Resolves an off-by-one out-of-bounds read in AJP getter functions.
CVE-2026-33523: Patches an HTTP response splitting vulnerability across multiple modules when forwarding malicious status lines.
CVE-2026-33007: Corrects a NULL pointer dereference in mod_authn_socache allowing an unauthenticated remote user to crash a child process in a caching forward proxy configuration.
CVE-2026-33006: Resolves a timing attack against mod_auth_digest that allows a Digest authentication bypass.
CVE-2026-29169: Fixes a NULL pointer dereference in mod_dav_lock allowing a server crash via a malicious request.
CVE-2026-29168: Addresses unrestricted OCSP response handling in mod_md.
CVE-2026-28780: Resolves a heap buffer overflow in mod_proxy_ajp via ajp_msg_check_header() where a malicious AJP server could write 4 attacker-controlled bytes past a heap buffer.
CVE-2026-24072: Fixes an ap_expr privilege escalation in mod_rewrite allowing local .htaccess authors to read files with the privileges of the httpd user.
CVE-2026-23918: Addresses a double free and possible RCE in HTTP/2 on early reset.

PHP 8.5.6:

CVE-2026-7263: Fixes duplicate xmlns declarations from Dom\XMLDocument::C14N() after setAttributeNS().
CVE-2026-6735: Resolves a XSS within the FPM status endpoint.
CVE-2026-7259: Addresses a NULL pointer dereference in php_mb_check_encoding() via mb_ereg_search_init().
CVE-2026-6104: Patches an out-of-bounds access in mbfl_name2encoding_ex().
CVE-2025-14179: Fixes a SQL injection via NUL bytes in PDO_Firebird quoted strings.
CVE-2026-6722: Addresses a stale SOAP_GLOBAL(ref_map) pointer with Apache Map.
CVE-2026-7261: Resolves a use-after-free after SOAP header parsing failure with SOAP_PERSISTENCE_SESSION.
CVE-2026-7262: Fixes a broken Apache map value NULL check.
CVE-2026-7568: Addresses a signed integer overflow of a char array offset.
CVE-2026-7258: Patches inconsistent passing of unsigned char to ctype.h functions.
CVE-2026-42371: Fixes a numeric truncation in URI parsing carried by uriparser.

OpenEXR 3.4.11:

CVE-2026-42217: Fixes a shift exponent overflow in readVariableLengthInteger().
CVE-2026-42216: Addresses an out-of-bounds read in IDManifest::init() during prefix expansion.
CVE-2026-41142: Resolves an integer overflow in ImageChannel::resize that leads to a heap out-of-bounds write via the OpenEXRUtil public API.
CVE-2026-39886: Fixes an HTJ2K signed integer overflow in ht_undo_impl().
CVE-2026-40244: Addresses an integer overflow in DWA setupChannelData planarUncRle pointer arithmetic.
CVE-2026-40250: Resolves an integer overflow in the DWA decoder outBufferEnd pointer arithmetic.

rsync 3.4.3:

CVE-2026-29518: Fixes a TOCTOU symlink race in daemon mode (use chroot = no) allowing local privilege escalation.
CVE-2026-43617: Addresses an authorization bypass via hostname resolution when the daemon chroot tree lacks DNS resolution support, causing the connecting hostname to be set to UNKNOWN.
CVE-2026-43618: Resolves an integer overflow in the compressed-token decoder enabling remote memory disclosure.
CVE-2026-43619: Fixes symlink races on path-based system calls (chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir, lstat) in use chroot = no daemon mode.
CVE-2026-43620: Patches an out-of-bounds read in the receiver’s recv_files() allowing remote DoS of any client pulling from a malicious server.
CVE-2026-45232: Addresses an off-by-one stack out-of-bounds write in establish_proxy_connection() HTTP CONNECT proxy response parsing.

PostgreSQL 18.4:

CVE-2026-6472: Ensures the user has CREATE privilege on the schema specified.
CVE-2026-6473: Fixes integer overflows in memory-allocation calculations.
CVE-2026-6474: Guards against malicious time zone names.
CVE-2026-6475: Prevents path traversal in pg_basebackup and pg_rewind.
CVE-2026-6476: Properly quotes subscription names in pg_createsubscriber.
CVE-2026-6477: Marks PQfn() as unsafe and avoids using it within libpq.
CVE-2026-6478: Uses timing-safe string comparisons in authentication code.
CVE-2026-6479: Prevents unbounded recursion while processing startup packets.
CVE-2026-6575: Detects faulty input when restoring attribute MCV statistics.
CVE-2026-6637: Prevents SQL injection and buffer overruns in contrib/spi.
CVE-2026-6638: Properly quotes object names in logical replication origin checks.

dnsmasq 2.92rel2:

CVE-2026-2291: Fixes cache poisoning that could enable DoS or attacker redirection.
CVE-2026-4890: Addresses a DoS vulnerability in DNSSEC validation.
CVE-2026-4891: Resolves a heap-based out-of-bounds read in DNSSEC validation.
CVE-2026-4892: Patches a heap-based out-of-bounds write in the DHCPv6 implementation.
CVE-2026-4893: Fixes an information disclosure flaw allowing source-check bypass.
CVE-2026-5172: Addresses a buffer overflow in extract_addresses().

expat 2.8.1:

CVE-2026-45186: Fixes a quadratic runtime from attribute name collision checks enabling DoS through moderately sized crafted XML input.
CVE-2026-41080: Resolves limited hash flooding entropy by raising the hash salt size from 4-8 bytes to a full 16 bytes.

GraphicsMagick:

CVE-2026-42050: Fixes a stack buffer overflow in XTileImage.

ImageMagick 7.1.2.23:

CVE-2026-31853: Addresses an overflow check flaw.

Linux Kernel 7.0.7:

CVE-2026-43349: Resolves a use-after-uninitialized-value access in f2fs.
CVE-2026-43350: Addresses an SMB client flaw requiring a full NFS-mode SID before continuing.
CVE-2026-43348: Fixes a vmemmap_shift exceeding MAX_FOLIO_* in mshv_vtl.
CVE-2026-43490: Validates inherited ACE SID length in ksmbd.

glibc:

CVE-2026-5928: Fixes ungetwc operating on a byte stream.
CVE-2026-5450: Addresses a buffer overflow in scanf %mc.

libzypp 17.38.9:

CVE-2026-44933: Prevents configured scripts from escaping the sigcheck directory.

python-Twisted 26.4.0:

CVE-2026-42304: Prevents a DoS attack via resource exhaustion during DNS name decompression.

bind 9.20.23:

CVE-2026-3592: Fixes an amplification vulnerability that could be made to consume disproportionate resources.
CVE-2026-3039: Addresses excessive memory consumption when processing maliciously-constructed packets.
CVE-2026-5950: Resolves a flaw exhausting CPU and memory.
CVE-2026-5947: Fixes a race condition that could allow an unauthenticated remote attacker to crash the server.
CVE-2026-5946: Addresses multiple flaws that could cause assertion failures via recursion, UPDATE, or NOTIFY paths.

python-idna 3.15:

CVE-2026-45409: Closes a bypass of the CVE-2024-3651 mitigation by rejecting oversize inputs up-front.

python-urllib3 2.7.0:

CVE-2026-44432: Closes a decompression-bomb safeguard bypass in the streaming API.
CVE-2026-44431: Fixes HTTP pools created via ProxyManager.connection_from_url not stripping sensitive headers when redirecting to a different host.

perl-libwww-perl 6.83:

CVE-2026-8368: Strips Authorization and Proxy-Authorization headers on cross-origin redirects to prevent credential leakage.

perl-CryptX 0.89:

CVE-2026-41564: Patches a security flaw in the Perl interface to LibTomCrypt.

perl-Net-CIDR-Lite 0.24:

CVE-2026-45190: Rejects Unicode digits and trailing newlines in parser inputs.
CVE-2026-45191: Rejects zero-padded CIDR masks.
CVE-2026-40199: Fixes an IPv4-mapped IPv6 packed length flaw.
CVE-2026-40198: Rejects invalid uncompressed IPv6 addresses.

perl-XML-LibXML 2.0212:

CVE-2026-8177: Prevents an out-of-bounds UTF-8 read in domParseChar by replacing it with libxml2’s xmlValidateName.

hplip 3.26.4:

CVE-2026-8631: Fixes a flaw in the HP Linux Imaging and Printing stack.
CVE-2026-8632: Addresses a second related flaw.

xen 4.21.1_06:

CVE-2025-54518: Mitigates AMD-SN-7052 CPU Op Cache Corruption.

Users are advised to update to the latest versions to mitigate these vulnerabilities.

Conclusion

May 2026 was a steady month for openSUSE Tumbleweed with point releases landing across all three major KDE stacks (KDE Gear 26.04.1, Frameworks 6.26.0, and Plasma 6.6.5). Mesa made the leap to 26.1 with the Vulkan 1.4 API, and AppArmor shipped its first 5.0 release. Sysadmins received headline updates across Apache HTTP Server 2.4.67, PostgreSQL 18.4, rsync 3.4.3, dnsmasq 2.92rel2, GnuPG 2.5.20, and expat 2.8.1 — almost all driven by CVE fixes. The Linux kernel progressed from 7.0.5 to 7.0.9 with broad subsystem hardening, and security was the dominant theme across PHP, OpenEXR, jq, ImageMagick, python-cryptography, python-urllib3, and a long tail of Perl networking modules.

Slowroll Arrivals

Please note that these updates also apply to Slowroll and arrive between an average of 5 to 10 days after being released in Tumbleweed snapshot. This monthly approach has been consistent for many months, ensuring stability and timely enhancements for users. Updated packages for Slowroll are regularly published in emails on openSUSE Factory mailing list.

Contributing to openSUSE Tumbleweed

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Planet News Roundup

admin@opensuse.org (Douglas DeMaio) — Fri, 29 May 2026 07:00:00 +0000

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog aggregates a list of the featured highlights below from May 22 to 27.

Blogs this week cover security vulnerabilities discovered and patched in qSnapper’s privileged D-Bus service, a new GSoC 2026 contributor joining the openSUSE Project, nightly syslog-ng container images now available based on Alma Linux, a new plasmoid Scrolling Clock for KDE Plasma 6, a tip for previewing Markdown in the Kate editor, the April 2026 Krita report, the Mobile Linux Hackday in České Budějovice, Agama 21 and more.

Here is a summary and links for each post:

Whaleshark Opens Knopje

Sébas announces that on June 19 he will open the next edition of Knopje with a 1.5-hour melodic techno set.

Krita April 2026 Report

The KDE Blog covers the April 2026 Krita monthly report, which announces the release of Krita 5.3.2 and 6.0.2 with two months’ worth of bug fixes and improvements including text tool enhancements, performance fixes, and an Android crash fix. The post also highlights upcoming features in development and improves wide-gamut color conversion.

Introducing Shared Canned Responses

The Open Build Service Blog introduces shared canned responses in OBS, expanding a feature that previously only allowed users to create personal canned responses under their own profiles. The update allows canned responses to now be shared across projects and packages, streamlining collaboration and communication in request workflows.

How to Install exeLearning 4.0 on Your Computer

The KDE Blog explains how to install exeLearning 4.0, a free and open-source tool for creating interactive digital educational resources. The post outlines the three available editions.

The KDE Blog presents Scrolling Clock, the 29th widget in their Plasma 6 plasmoid series, which displays an animated clock cycling through all digits for a unique and eye-catching desktop look. Users who enjoy the widget are encouraged to support the developer through ratings, comments, or donations on the KDE Store.

Previewing Markdown Files in the Kate Editor

Victorhck shares a quick tip for enabling live Markdown preview inside the KDE Kate editor by activating the “Document Preview” plugin. The author notes that HTML preview does not work the same way and recommends using a browser for that format instead.

Nightly syslog-ng Containers Based on Alma Linux

Peter Czanik announces that nightly syslog-ng container images based on Alma Linux are now available on Docker Hub. Previously only Debian-based images were provided, but this new Alma Linux offering is built from the latest syslog-ng git snapshot packages.

Accepted into Google Summer of Code 2026 with openSUSE!

Mario Marín announces on his GSoC 2026 blog that he has been accepted into Google Summer of Code 2026 to contribute to the openSUSE project under two mentors. Over 12 weeks, he will work on improving the obs-status-service, including better SVG visualizations, a Gitea bot for Pull Request build information, and an AI-assisted stretch goal using Log Detective to analyze failed builds. He will be posting weekly progress updates on his blog.

qSnapper: Various Security Issues in Privileged D-Bus Service (CVE-2026-41045 through CVE-2026-41049)

The SUSE Security Team blog discloses five CVEs found during a security review of qSnapper, a GUI frontend for the Btrfs snapshot manager snapper. All issues were addressed through coordinated disclosure with the upstream author and fixes were shipped in the qSnapper 1.3.3 released on May 26.

MobileLinux Hackday #1 in České Budějovice

The SUSE Community Blog reports that the first Mobile Linux Hackday held in České Budějovice had a bigger turnout than the well-established Prague series with regard to attendance and synergy. The Prague series had already built a strong following over seven monthly events and the new venue signals growing momentum and geographic expansion for the Mobile Linux hackday movement in Czechia.

How to Use Desktop Icons NG (DING) on openSUSE 16 GNOME

The Geeko Blog provides a fix for the Desktop Icons NG (DING) GNOME extension failing to work on openSUSE 16. The post includes the relevant error message from /var/log/messages to help users identify the problem.

Long-Term Support Doesn’t Mean What You Think

The KDE Blog summarizes a post by KDE developer Nate Graham clarifying that LTS releases promise extended maintenance and security patches, not bug-free software or guaranteed personal support. The post draws a clear distinction between free community LTS distributions and commercially supported products and suggests that Flatpak apps can help bridge the software freshness gap on stable systems.

Haruna 1.8 Released – New Version of This KDE Media Player

The KDE Blog announces the release of Haruna 1.8, an open-source video player built on libmpv with YouTube integration. Haruna continues to be a solid alternative to Dragon Player and Kaffeine within the KDE ecosystem.

Linux Saloon 202 | Early Edition

CubicleNate recaps episode 202 of the Linux Saloon podcast, covering Colin’s use of his Surface Go running Cosmic Desktop, the release of Ubuntu 26.04 LTS, and updates on the Framework Computer Laptop 13 Pro.

Linux Saloon 203 | News Flight Night

CubicleNate recaps episode 203 of the Linux Saloon podcast, during which attendees discuss Collin’s experience with stillOS, the value of operating system rollback features, and notable news including HP sponsoring the Linux Vendor Firmware Service and KDE receiving a significant investment.

Xe Driver Support and Discover Improvements – This Week in Plasma

The KDE Blog translates Nate Graham’s weekly Plasma development summary. A standout community contribution added support for monitoring modern Intel Xe GPUs in System Monitor and its widgets. Discover also received several improvements including safer Flatpak data deletion sending files to the trash, a reorganized front page with the Editor’s Choice section moved higher, and case-insensitive search on the Updates page.

Agama 21 Released

Victorhck summarizes the release of Agama 21. The network configuration interface was redesigned with a new form supporting bond and bridge connections in addition to Ethernet and Wi-Fi. A new boot option inst.remote=0 allows disabling remote installer access for improved security in sensitive environments.

Tumbleweed – Review of the Weeks 2026/21

Victorhck and Dominique Leuenberger’s blog recap week 21 with six snapshots. The releases shipped notable updates including AppArmor 5.0.0, KDE Plasma 6.6.5, Linux kernel 7.0.6 through 7.0.9, GStreamer 1.28.3, Ruby 4.0.4, and PostgreSQL 18.4. Upcoming pipeline changes include Agama 21, GCC 16 as the default system compiler, and a rework of Python 3 packaging.

Workshop: Agentic AI and Total Automation at Linux Center València

The KDE Blog announces a hands-on workshop on agentic AI and automation taking place on June 6 at Slimbook’s Linux Center in Paterna, Valencia. The event features sessions on building intelligent agent systems using OpenClaw, privacy-respecting automation with Hermes, and a practical pair-programming workshop on Slimbook One mini PCs.

View more blogs or learn to publish your own on planet.opensuse.org.

Managing System Extensions with sysextmgrcli

admin@opensuse.org (Stefan Schubert) — Thu, 21 May 2026 08:00:00 +0000

Managing System Extensions on openSUSE MicroOS with `sysextmgrcli`

If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read-only, and transactional updates are the law of the land.

But what happens when you need to add software or system extensions without rebooting or messing with your base OS layers?

E.g. You need strace or gdb to debug a running application, but a reboot to install this tools would change the situation.

Enter System Extensions (sysext images) and the utility designed to make them manageable: sysextmgrcli.

What is `sysextmgrcli`?

At its core, sysextmgrcli is a command-line client for managing systemd-sysext images and has been written by Thorsten Kukuk. It is designed specifically to play nice with the atomic nature of MicroOS.

Instead of forcing you to use sudo for every query, it talks to a background daemon (sysextmgrd) via Varlink. This architecture allows unprivileged users to list existing system extension images without needing root permissions, while the daemon handles the heavy lifting of downloads and verification via systemd-pull. For security reasons, root provileges are still required for installing or updating sysext images.

The Architecture: Smart Snapshots

One of the cleverest things about sysextmgrcli is how it handles storage to be efficient and “rollback-safe”:

/var/lib/sysext-store: This is where the actual image files live. Since /var is a separate subvolume shared across all Btrfs snapshots, you only store the image once, saving disk space. If you have no network available, that’s the location for storing offline or even own build sysext images via e.g. an USB device.
/etc/extensions: This directory contains symlinks to the images in the store. Because /etc is part of your root snapshot, the extensions are tied to your current system state.

Why does this matter? If you perform a system rollback, your symlinks roll back too. This ensures the active sysext images always match the OS version you are currently booted into.

Essential Commands

Getting started is straightforward. Here are the primary commands you’ll use to manage your extensions:

1. Listing and Checking Images

Want to see what’s available or if your images are compatible with your current OS version?

# List all images and report compatibility
sysextmgrcli list

# Check for updates and verify compatibility
sysextmgrcli check

2. Installing New Extensions

You can install by providing a name and a source URL. The tool automatically handles SHA256 verification and checks if it fits your OS.

# --url is optional (default: https://download.opensuse.org/tumbleweed/appliances/ )
sysextmgrcli install [NAME] --url [https://your-image-repo.com](https://your-image-repo.com)

3. Maintenance and Updates

Updates are handled by comparing local files against remote manifests. If a newer version matches your current snapshot, it gets pulled down and symlinked.

# Update existing images to the latest compatible versions
sysextmgrcli update

# Clean up: Remove images in the store that are no longer referenced by any snapshot
sysextmgrcli cleanup

The “Activation” Catch

It is important to note that sysextmgrcli is a manager, not an activator. It handles the logistics: downloading, version checking, and symlinking. To actually “plug in” the extensions to your running system, you still use standard systemd-sysext commands:

Manual activation: systemd-sysext merge
Manual deactivation: systemd-sysext unmerge
Enable at boot: systemctl enable systemd-sysext.service

Available default system extention (sysext) images:

debug (babeltrace, gdb, ltrace, strace, traceroute)
gcc (cpp, gcc, make, patch)
git (git, git-core)

Summary

You need `git` on your openSUSE MicroOS ?

Just call sysextmgrcli install git ; systemd-sysext merge and use it…

You do not need ‘git’ anymore on your system ?

Just call systemd-sysext unmerge and it is not available anymore…

sysextmgrcli bridges the gap between static immutable infrastructure and the need for flexible system additions. By leveraging the Btrfs directory structure of MicroOS, it ensures your system remains clean, version-synced, and easy to manage.

openSUSE News

When the Code Stays Clean and Trust Collapses Anyway

Why Europe’s third way needs sovereign open-source assurance, and what the openSUSE community, the SUSE ecosystem and the businesses built on them should do about it

The same lesson in the classic distribution chain

The sausage factory and the view from orbit

Europe’s third way is a trust market

The CRA turns sovereignty into an evidence problem

The steward is a bridge, not a command structure

Standards are where the trust stack becomes testable

Evidence discipline is the hinge

Funding the boring work

Procurement turns strategy into demand

NIS2 and the Cybersecurity Act widen the frame

The Linux distribution as the working model

What communities should do now

What companies should do now

The openSUSE role, and why this community matters

Europe’s third way must be earned

Source notes for final publication

Uyuni Joins openSUSE Project Ahead of Annual Conference

A Partnership Years in the Making

Upstream First: A Community Without Second-Class Citizens

Constant Innovation: Uyuni 2026.04

Celebrate Together at openSUSE Conference 2026!

Planet News Roundup

Tumbleweed – Review of the Week 2026/24

Planet News Roundup

Tumbleweed – Review of the Week 2026/23

Rival GPUs Share One Linux Desktop

openSUSE Asia Summit 2026 Logo Competition Announcement

openSUSE.Asia Summit 2026 Logo Competition

Contest Guidelines

How to Submit

TSP Open for Asia Summit

Tumbleweed Monthly Update - May 2026

New Features and Enhancements

Key Package Updates

Security Updates

Conclusion

Slowroll Arrivals

Contributing to openSUSE Tumbleweed

Planet News Roundup

Tumbleweed – Review of the Weeks 2026/21

Managing System Extensions with sysextmgrcli

Managing System Extensions on openSUSE MicroOS with sysextmgrcli

What is sysextmgrcli?

The Architecture: Smart Snapshots

Essential Commands

1. Listing and Checking Images

2. Installing New Extensions

3. Maintenance and Updates

The “Activation” Catch

Available default system extention (sysext) images:

Summary

You need git on your openSUSE MicroOS ?

You do not need ‘git’ anymore on your system ?

Managing System Extensions on openSUSE MicroOS with `sysextmgrcli`

What is `sysextmgrcli`?

You need `git` on your openSUSE MicroOS ?