AHXproject

AppManager installs AppImages on Ubuntu without needing FUSE

AppImages are designed to be simple. Download one, make it executable and run it. On Ubuntu, though, there's an extra step: Ubuntu ships FUSE 3 by default, but some AppImages still need FUSE 2 (libfuse2t64) to run. AppManager is a new(ish) GTK4/Libadwaita app which fixes that particular annoyance by mounting AppImages through uruntime instead of FUSE. It handles the usual SquashFS-packed AppImages, plus the newer DwarFS-packed ones too. Double-click an .AppImage file and AppManager opens a macOS-style install flow. Drag the app icon to the folder and AppManager moves the file to ~/Applications, or a directory you choose, and creates the app launcher and shortcut [...]

You're reading AppManager installs AppImages on Ubuntu without needing FUSE , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, AppImage, Appmanager
Source: https://www.omgubuntu.co.uk/2026/07/appmanager-appimage-installer-linux Jul 15, 2026, 02:00 AM

MAAS installation: bare metal provisioning is easier than ever

MAAS  brings cloud-like automation to physical servers. It helps teams discover, commission, deploy, and repurpose machines from a central control plane, turning bare metal into a programmable resource.

But to experience that value, users first need to get MAAS up and running. That path is now cleaner and easier to follow. We've created new documentation  to help you get started, providing a more direct installation and configuration workflow, using the MAAS snap and the PostgreSQL snap to simplify the setup of a complete MAAS environment.

This improvement makes it easier to try MAAS in a lab, build a proof of concept, or prepare a small deployment before moving to larger production environments.

In this blog, we'll walk through what has changed, why it matters, and how the new documentation helps users start exploring MAAS faster.

Installing MAAS: where we came from

There are several ways to start with MAAS, depending on what you want to achieve. For a quick first look, the "Build a MAAS and LXD environment in 30 minutes with Multipass" tutorial  provides a fully sandboxed environment that runs on a PC or laptop. This is a great way to understand MAAS, explore the UI, and see the basic machine lifecycle without affecting a real network or connecting physical servers. In this workflow, users rely on the maas-test-db helper – however, this doesn't reflect production workflows.

At some point, users need to experience MAAS with real hardware. Bare metal automation is about discovering, commissioning, deploying, and repurposing physical machines, and that is where a more realistic installation becomes useful.

The new process: a clearer first step into bare metal provisioning

The new documentation focuses on provisioning actual machines through a series of how-to articles. The core installation model remains familiar: users install MAAS, provide a PostgreSQL  database, initialize the service, create an administrator account, and access MAAS through the CLI or the web UI. 

The "Get started" guide  walks you through using the MAAS snap and PostgreSQL snap directly for a single-machine deployment in region+rack mode. This creates something closer to a standard MAAS setup than our previous workflows enabled, as well as being  a practical setup for a homelab, a small proof of concept, or a small production environment. By following the steps, you'll create a complete MAAS environment, without needing to design a more complex topology from the beginning.



This workflow is more direct, reducing the amount of manual package and service setup. The result is a smoother first experience: users can spend less time assembling the platform, and more time exploring what MAAS actually does. 

After installation, users can move directly into the "Configure MAAS" guide , which explains the basic configuration needed to make MAAS useful: logging in, setting up the initial network services, and preparing the environment to manage machines. For a first deployment, this usually means setting an upstream DNS server, identifying the subnet that MAAS will manage, selecting the rack controller that will provide DHCP, defining a dynamic IP range, enabling DHCP on the relevant VLAN, and setting the gateway for the subnet.

This keeps the first deployment focused on learning the MAAS workflow, instead of making early architectural decisions that may only matter in larger environments.

These are foundational steps. They connect MAAS to the network where machines will boot, receive addresses, and later move through discovery, commissioning, and deployment. By presenting them as part of the same getting-started flow, the documentation makes the first real-hardware experience easier to follow from beginning to end.

Start your MAAS journey

Getting started with MAAS is now simpler. The new documentation gives users a clearer path from installation to initial configuration, and from there to the first real experience of managing physical machines.

For many users, this is the right first step: the new documentation is a series of how-to articles, simple enough for a lab or proof of concept, but realistic enough to understand how MAAS works with real hardware. And when the environment needs to grow, the documentation also covers more advanced options, such as configuring PostgreSQL for remote connections .

If you want to try MAAS, start with the new "Get started with MAAS" guide . Install MAAS, configure the basics, connect your machines, and begin exploring bare metal automation.

MAAS brings cloud-like automation to physical servers. It helps teams discover, commission, deploy, and repurpose machines from a central control plane, turning bare metal into a programmable resource. But to experience that value, users first need to get MAAS up and running. That path is now cleaner and easier to follow. We've created new documentation [...]


Categories: installation, MAAS
Source: https://ubuntu.com//blog/maas-installation-bare-metal-provisioning-is-easier-than-ever Jul 14, 2026, 06:00 PM

Januscape vulnerability CVE-2026-53359 mitigations available

Introduction

A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID CVE-2026-53359  and is referred to as Januscape. This vulnerability affects all Ubuntu releases.

Neither NVD nor Kernel.org  have published their own CVSS scores for this issue; we calculated it as CVSS 4 8.4 and have seen others publish CVSS 3 7.8, 8.8, and CVSS 4 9.3.

The vulnerability affects nested virtualization in the KVM system on Intel and AMD x86_64 systems. Other architectures are not affected. A Proof of Concept exploit was published that demonstrates crashing a hypervisor host from a guest. Some reports claim that a full exploit exists.

The fix must be installed in the hypervisor's kernel: if you are using a cloud service provider with a hypervisor based on Linux KVM on Intel or AMD hardware and you can use nested virtualization, your VM or host may be compromised by another tenant. If your cloud service provider does not allow nested virtualization, you are not affected by this issue.

If you run hypervisors yourself, your attack surface is from root in your guest virtual machines.

Linux kernel packages which implement the proposed patch will be released. Until security updates are available, you can disable nested virtualization to prevent abuse of this issue. This might disrupt your legitimate work and you should weigh the pros and cons before using this mitigation.

This post describes how to disable nested virtualization.

Which Ubuntu releases are affected by CVE-2026-53359?
ReleasePackage NameRemediation statusTrusty (14.04)linuxFix pendingXenial (16.04)linuxFix pendingBionic (18.04)linuxFix pendingFocal (20.04)linuxFix pendingJammy (22.04)linuxFix pendingNoble (24.04)linuxFix pendingResolute (26.04)linuxFix pending
How to check if you are impacted by CVE-2026-53359

grep . /sys/module/kvm_{amd,intel}/parameters/nested
# 1 or Y means you are impacted. 0 or N means mitigated.
# One or two "No such file or directory" is expected.
# Two "No such file or directory" does not itself mean
# you are safe -- the module may still be loaded later.
Impact of CVE-2026-53359
Deployments without virtualization workloads

Even if you do not have virtual machines running now, system services such as libvirt, lxd, multipass, incus, etc may allow users to create virtual machines in future. An attacker could use the ability provided by these services to create virtual machines and perform local privilege escalation (LPE) by exploiting this vulnerability. Device node permissions may also allow users the necessary permissions to exploit the vulnerability. Inspect the output of namei -l /dev/kvm and getfacl /dev/kvm to see the permissions on the usual device node. You should ensure that only privileged users can write to the /dev/kvm device. The default on Ubuntu is that /dev/kvm is only writable by the superuser (root) and the kvm group. Only privileged users are added to the kvm group.

Deployments with container workloads

Unprivileged containers do not have sufficient permissions to start KVM-accelerated virtual machines and are thus not a vector for concern. Privileged containers may have sufficient permissions to start KVM-accelerated virtual machines and should not be considered safe. These should be treated as per the 'Deployments without virtualization workloads' section, above.

Deployments with virtualization workloads

Any process or user inside a virtual machine that can cause kernel module loading – or supply a new kernel – can manipulate page tables sufficiently to crash or potentially exploit the host or exploit other guest virtual machines on the host.

How to apply mitigations for CVE-2026-53359

You can disable virtualization nesting on your hosts:

# unload modules, both are harmless
sudo rmmod kvm_amd ; sudo rmmod kvm_intel
# look to see if any configuration file forces nesting on
grep nested /etc/modprobe.d/*
# disable nesting for the implementations of KVM in both AMD and Intel processors
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/nested.conf
echo 'options kvm_intel nested=0' | sudo tee -a /etc/modprobe.d/nested.conf

# reload modules if necessary, both are harmless
sudo modprobe kvm_amd ; sudo modprobe kvm_intel

Further reading

• Technical writeup by exploit author Hyunwoo Kim
• Read Ubuntu's disclosure policy

Introduction A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID CVE-2026-53359 and is referred to as Januscape. This vulnerability affects all Ubuntu releases. Neither NVD nor Kernel.org have published their own CVSS scores for this issue; we calculated it as CVSS [...]


Categories: Security, Vulnerabilities
Source: https://ubuntu.com//blog/januscape-linux-vulnerability-mitigations-available Jul 11, 2026, 11:00 PM

Managing Ubuntu on bare metal at scale

Modern infrastructure teams are expected to deliver cloud-like speed, consistency, and reliability, even when their workloads run on physical servers.

Bare metal remains essential for many environments: private clouds, Kubernetes clusters, AI infrastructure, edge sites, regulated platforms, and large Ubuntu estates. But operating physical infrastructure at scale is difficult when provisioning, patching, monitoring, and lifecycle management are handled by disconnected tools and manual processes.

This blog will explore how Canonical MAAS  and Canonical Landscape  can work together to close that operational gap. MAAS provides cloud-like automation for bare metal provisioning and Day 0 operations. Landscape provides centralized management, monitoring and maintenance for Ubuntu systems throughout their operational life. Together, they help organizations build, operate, and repurpose physical infrastructure with greater consistency and control.


The lifecycle gap in bare metal operations

Provisioning a machine is only the beginning. Many organizations have improved the way they deploy infrastructure, but still struggle to manage what happens after the operating system is installed. A server may be provisioned quickly, but then it must be patched, monitored, inventoried, configured, secured, and kept compliant over time.

When these stages are handled separately, several problems appear, including fragmented infrastructure inventory, reliance on manual workflows for patching and maintenance, inconsistent operational visibility across environments, difficulty coordinating security updates, longer times required to rebuild or repurpose machines, and the loss of a cloud-like experience once the operating system is deployed.

MAAS: cloud-like provisioning for bare metal

Canonical MAAS provides the Day 0 foundation for physical infrastructure. It enables teams to discover, commission, deploy, and repurpose bare metal machines through repeatable workflows and APIs. Instead of treating servers as individually managed assets, MAAS turns them into programmable resources that can be allocated and reused as needed.

With MAAS, infrastructure teams can:

• Discover and inventory physical machines
• Control the servers through out-of-band management interface
• Validate hardware before it enters production
• Deploy operating systems consistently
• Reuse or repurpose machines when requirements change
• Integrate bare metal provisioning into infrastructure-as-code workflows

The result is a cloud-like operational model for physical servers. Bare metal becomes easier to automate, easier to rebuild, and easier to integrate into modern platforms such as Kubernetes, private clouds or AI infrastructure. This means your teams spend less time managing infrastructure, and more time delivering value.

However, once Ubuntu is installed and the machine is running, a new set of operational questions begins. Landscape is the answer.

Landscape: centralized operations for Ubuntu estates

Canonical Landscape provides the Day 2 operations layer for Ubuntu systems.

Once machines are deployed, organizations need a reliable way to manage them over time. Landscape gives teams a centralized view of their Ubuntu estate, whether those systems are running on physical servers, virtual machines or containers.

Landscape helps teams manage common operational tasks such as:

• Software updates and security patching
• Machine inventory
• System monitoring
• Configuration management
• Remote scripting
• Operational reporting
• Integration with third-party tools through an API

This is especially important for organizations managing large Ubuntu estates. Without a central management layer, routine tasks such as patching, auditing, and configuration drift control can become slow, inconsistent, and expensive.

Landscape helps reduce that operational burden by giving teams a single place to see, manage, and maintain their Ubuntu systems.

The operational benefits of using MAAS and Landscape in combination

The real value appears when MAAS and Landscape are used together: MAAS builds the machine, while Landscape manages it once it is live.

A typical lifecycle could look like this:

• A new server is discovered by MAAS
• MAAS commissions the machine and records its hardware inventory via commissioning
• MAAS tests the machine so that it only goes to production if it is in a healthy state
• MAAS deploys Ubuntu with the required configuration
• The deployed machine is enrolled into Landscape
• Landscape keeps the system visible, patched, and manageable
• Operational teams use Landscape for monitoring, scripting, and maintenance
• When the machine is no longer needed, MAAS releases or repurposes it
• The next deployment starts from a clean, repeatable baseline

This closes the gap between Day 0 and Day 2.

Instead of having one process to provision hardware and another disconnected process to operate Ubuntu, teams get a more complete lifecycle model. Physical servers can be built, managed, updated, and reused with greater consistency. This is particularly helpful in environments where physical infrastructure must be provisioned quickly, and Ubuntu systems must be managed consistently over time. For example:

• Private cloud and virtualization platforms: MAAS provisions the physical servers that form the platform foundation, while Landscape helps manage and maintain the Ubuntu systems that support it. Get more detail on our webpage .
• Kubernetes on bare metal: MAAS automates the deployment and reuse of Kubernetes nodes, while Landscape provides visibility, patching, and operational control across the Ubuntu estate underneath the cluster. Learn more about Canonical Kubernetes.
• Edge and distributed infrastructure: MAAS standardizes provisioning across remote sites, while Landscape gives central teams a single place to monitor and manage Ubuntu systems after deployment. Learn more about our solutions for edge and distributed infrastructure .
• Labs, QA and temporary environments: MAAS makes it easier to build, rebuild, and repurpose physical machines, while Landscape keeps those systems visible and manageable while they are in use.
• Security-sensitive and regulated environments: MAAS provides repeatable provisioning and hardware inventory, while Landscape supports consistent patching, system visibility and operational control over time. Learn more about how our solutions offer the foundation for regulated environments on our sovereign cloud webpage .

Conclusion: a complete lifecycle for bare metal and Ubuntu

Bare metal infrastructure does not have to be slow, static or difficult to manage.

With MAAS, organizations can bring cloud-like automation to physical provisioning. With Landscape, they can help to keep Ubuntu systems visible, trusted, and manageable throughout their lifetime. Together, MAAS and Landscape help bridge the gap between Day 0 and Day 2 operations. They allow teams to build infrastructure quickly, operate it consistently, and repurpose it when requirements change.

For organizations running large Ubuntu estates, private clouds, Kubernetes clusters, edge sites or regulated infrastructure, this combination provides a practical path toward more automated and reliable operations.

Learn more in our documentation

• MAAS documentation
• Landscape documentation

Modern infrastructure teams are expected to deliver cloud-like speed, consistency, and reliability, even when their workloads run on physical servers. Bare metal remains essential for many environments: private clouds, Kubernetes clusters, AI infrastructure, edge sites, regulated platforms, and large Ubuntu estates. But operating physical infrastructure at scale is difficult when provisioning, patching, monitoring, and lifecycle [...]


Categories: bare metal, Landscape, MAAS
Source: https://ubuntu.com//blog/managing-ubuntu-on-bare-metal-at-scale Jul 09, 2026, 06:17 PM

Ubuntu Server: a platform made for enterprise scale

A platform is an environment that allows software to run smoothly across the infrastructure, runtime, and application layers. The key word there is "smoothly": a good platform connects those layers so well that you don't notice it. That's what Ubuntu Server has become: the essential layer between bare metal and the apps running on top, continuously optimized across resource management, networking, and security.

Ubuntu 26.04 LTS  represents over 12 years of that work coming together. In this blog, we'll highlight the features that show just how far it's come, and how you can use Ubuntu Server in combination with other Canonical products to deliver solutions for enterprise scale.

Bare-metal automation with MAAS

Enterprise environments rarely run on uniform hardware, and making the most of what you have can be a large manual undertaking. Ubuntu Server goes beyond running standard workloads by enabling full bare metal automation through its integration with MAAS (Metal as a Service).

MAAS automates the full lifecycle of your machines, from discovery, OS deployment, and configuration, to secure decommissioning . Before a server even enters production, integrated diagnostics stress-test the hardware to flag connectivity or component issues, which is vital for maintaining large-scale fleets. You can also tag which servers in your estate are best suited to deploy AI workloads. This enables you to deploy resources efficiently, as GPU workloads become a bigger part of enterprise infrastructure planning. 

By integrating with Infrastructure as Code (IaC) tools like Terraform, MAAS enables you to manage physical hardware using the same automated workflows typically reserved for the cloud. This eliminates the manual overhead that makes bare-metal management difficult at scale, by allowing you to orchestrate a fleet of physical servers as easily as if they were virtual machines. 

As with any platform, the work is always ongoing to make the integration tighter. A particular highlight is instant AI readiness. Enhanced NPU drivers allow MAAS to automatically detect and pre-configure the kernel modules and runtimes for AI accelerators, turning raw silicon into an active AI node instantly.

Virtualization support

Software-defined infrastructure (SDI) relies on the ability to abstract hardware into flexible, digital resources. While virtual machines (VMs) have long been the standard, containers are rising in adoption. Any enterprise server platform needs to support mixed environments.

Ubuntu Server addresses this need through LXD, its native virtualization layer. Traditional approaches to virtualization often force you to choose between a container manager or a hypervisor. LXD allows you to host both system containers and VMs together on a single infrastructure. For smaller-scale private cloud deployments,LXD clustering  lets you extend this unified environment across multiple nodes, giving you a lightweight, flexible option without additional orchestration overhead. For a deeper technical rundown of how this works, I recommend exploring our detailed documentation .

For private cloud infrastructure, OpenStack tends to be the dominant choice. Ubuntu is already the primary OS for around half of all OpenStack deployments,  and Ubuntu Server is the target platform for KVM, the hypervisor most commonly used with OpenStack. Canonical OpenStack  builds on this as an opinionated distribution running on Ubuntu Server, adding structure to what is otherwise a complicated process of deployment, patching, and ongoing maintenance. This combination provides a robust enterprise engine when you need to enforce strict isolation boundaries through virtual machines at large scales using Ubuntu Server infrastructure.

All of this matters as you can select the model that best works for you. System containers deliver near bare-metal performance for workloads where density and efficiency are the priority. VMs provide a stronger hardware-level isolation boundary for environments where that separation is required. Whichever option you select, Ubuntu Server helps you to scale it.

Ubuntu 26.04 LTS also brings updates that strengthen virtualization capabilities of Ubuntu Server, through support for confidential computing. Ubuntu 26.04 LTS adds hardware-level encryption through AMD SEV-SNP and Intel TDX. This means workloads running on Ubuntu Server can remain encrypted and inaccessible even to the host system, strengthening isolation for sensitive enterprise workloads. GPU-passthrough for AI containers: as with prior releases, optimizations in Ubuntu 26.04 LTS now allow you to share a single physical GPU across multiple system containers. This enables you to set up AI factories ,  with independent workloads drawing upon the same powerful hardware simultaneously.

Native orchestration capability

Orchestration illustrates what platform cohesion actually means: the value isn't in any single component, but in how reliably the pieces connect.

Kubernetes is the standard for container orchestration, but it doesn't operate in a vacuum. It needs a solid, well-integrated platform beneath it. Ubuntu Server is that platform, whether you're running on the public or private cloud. Optimized Ubuntu images bring this capability to the public cloud, while bare metal automation through MAAS allows you to do the same on-premises.

This makes orchestration simpler, as the OS experience is the same across platforms. But what about Kubernetes itself? Because the underlying platform is consistent, you have a single baseline regardless of which Kubernetes flavor you run. Canonical Kubernetes  takes this further by integrating with Ubuntu Server. Unlike upstream Kubernetes, where new releases come out every 4 months, Canonical Kubernetes is supported for up to 15 years, as is the rest of the Ubuntu Server stack.  

So what's new in terms of your own container orchestration? Well, Ubuntu 26.04 LTS brings dual-track containers. Administrators can now choose the update velocity that matches their risk profile by selecting between two distinct paths for the container runtime. Opt for the "Stable" track to prioritize production reliability and a consistent 15-year baseline, or the "App" track to access the latest upstream features for development and testing.

Integration with leading AI toolkits and libraries

If AI is to become a truly enterprise-standard tool, then setup needs to become intuitive. The days of it being acceptable for models to require manual compilation and deep hardware expertise are coming to an end. Silicon vendors work directly with Canonical to streamline how Ubuntu interacts with libraries and frameworks like NVIDIA CUDA  and AMD ROCm . In fact, for Ubuntu 26.04 LTS, these packages have beenintegrated directly  into the Ubuntu archive, making hardware enablement a simple, standard package installation.

When it comes to selecting a model,inference snaps  (pre-packaged models and inference runtimes that run on Ubuntu) automatically detect the underlying hardware and deploy a  silicon-optimized inference engine to get the best performance possible on that hardware.

From layers to interconnection

Hopefully this blog has given you a sense of what Ubuntu offers as a cohesive enterprise server platform. Rather than a layered set of tools, Ubuntu functions as an interwoven, interconnected platform. For a closer look at the specific features we released in Ubuntu 26.04 LTS, Christian's blog is the place to go.

What that release represents, though, is something broader. The individual components, such as bare-metal management, virtualization, container orchestration, AI readiness, have always been strong. What Ubuntu Server 26.04 LTS marks is the point at which they fully come together. Years of platform work have brought us to a place where the conversation shifts from capability to optimization. That's a meaningful milestone.

A platform is an environment that allows software to run smoothly across the infrastructure, runtime, and application layers. The key word there is "smoothly": a good platform connects those layers so well that you don't notice it. That's what Ubuntu Server has become: the essential layer between bare metal and the apps running on top, [...]


Categories: confidential computing, LXD, MAAS, Ubuntu Server
Source: https://ubuntu.com//blog/ubuntu-server-a-platform-made-for-enterprise-scale Jul 07, 2026, 07:42 PM

Building an open source chain of trust: new research uncovers key blockers and ways forward

Canonical is pleased to share its latest research report , "The open source chain of trust." Based on a survey of 500 DevOps professionals, the report highlights how organizations approach their open source software supply chains. While many companies are moving toward verifiable provenance and automated security workflows, internal misalignment and disjointed approaches remain serious challenges for most teams.

Read the report

Open source is the fabric of modern IT, but management remains fragmented

Open source powers development toolchains and underpins cloud-native platforms. It runs across on-prem, cloud, and edge environments. While organizations formalize policies and adopt security tools, many rely on fragmented processes with significant visibility gaps in CI/CD process between development and production stages. This research shows that 90% of respondents believe their organization needs to improve cross-team collaboration regarding open source software.



Figure 1: overview of key findings from the research

Organizations often stitch together components from many sources using inconsistent methods and misaligned upgrade cadences. Security teams struggle to manage transitive dependencies in this environment. Meanwhile, operations teams face constant trade-offs between stability and necessary changes.

"Open source is a critical foundation of the enterprise, but managing the dependency sprawl can be an operational and security challenge. On top of these existing supply chain challenges, the cadence of software development is accelerating. Consequently, it is increasingly crucial for organizations to bring automation and cross-team collaboration into their SDLC governance."

– Rachel Stephens, Research Director at RedMonk
Key findings from the research

The report identifies operational challenges and highlights how internal misalignment impacts software supply chains:

• Cross-team tensions stall progress: 71% of respondents report tensions between DevOps and platform engineering teams regarding the scalable use of open source.
• Manual processes hinder maturity: 35% of organizations still rely on manual code reviews for security. Another 21% use manual methods to track vulnerabilities.
• Operational risk drives patching delays: Primary causes for delays include system compatibility concerns (53%) and resource constraints like staff shortages (43%).

Figure 2: Most common causes of delays in organizations' ability to patch vulnerabilities, top 3 combined answers.

Mitigating gaps through a trusted foundation

The research highlights a clear path toward more predictable and secure operations:

• Rely on the operating system as a strategic control plane: 98% of respondents describe the OS as extremely or very important for detecting and applying updates to open source components, suggesting it can serve as a central layer to govern supply chain hygiene.
• Establish verifiable provenance: 48% of respondents state that tracked packages would improve their confidence in software supply chain security.
• Strengthening collaboration: Choosing the right platform as a foundation brings consistent governance and strengthens the working relationship between DevOps, security, and operations.

Discover all the insights from the research

"This new research highlights that scaling open source innovation requires organizations to move beyond fragmented workflows to adopt a stable foundation that can help fast-track security and compliance. At Canonical, we help our customers achieve exactly this by simplifying vulnerability management and providing a single, verifiable stack with trusted end-to-end provenance."

– Lech Sandecki, Product Manager at Canonical

Trusted open source with Canonical

Maturing processes and improving internal alignment are critical for addressing security concerns. Through Ubuntu Pro , Canonical delivers consistent security maintenance for the operating system and thousands of upstream open source packages.

By streamlining vulnerability management and committing to up to 15 years of platform stability through backporting, Canonical helps resolve the inherent tension between rigorous security and operational uptime. This shift moves organizations from a state of fragmented visibility and complex management to one of securely designed architecture, ensuring the open source fabric they depend on remains a source of innovation and not of risk.

About the research

The report is based on a global survey of 500 IT professionals conducted by Vanson Bourne. Respondents represent organizations across the Americas, EMEA, and APAC.

Further resources on open source security

Read our latest research into software supply chains. Canonical offers in-depth guides to help you secure open source ecosystems and navigate supply chain complexities.

• The state of software supply chains: Explore IDC research detailing why software supply security remains a challenge despite greater patching efforts, and how AI is making the compliance landscape more challenging. Download the research report  
• A guide to open source vulnerability management: Discover the main challenges with open source security vulnerabilities, best practices for effective vulnerability management and how to apply cybersecurity frameworks like the NIST framework with Ubuntu Pro. Download the guide

Canonical is pleased to share its latest research report, "The open source chain of trust." Based on a survey of 500 DevOps professionals, the report highlights how organizations approach their open source software supply chains. While many companies are moving toward verifiable provenance and automated security workflows, internal misalignment and disjointed approaches remain serious challenges [...]


Categories: security & compliance, software supply chain
Source: https://ubuntu.com//blog/open-source-security-research Jul 06, 2026, 05:39 PM

Beyond safety and security: Why automotive open source demands dependability 

In the traditional automotive world, teams often work in silos: the cybersecurity experts lock down the ports, the quality assurance teams hunt for bugs, and the functional safety engineers track the ISO 26262 compliance. At Canonical, we believe this fragmented workflow causes friction rather than collaboration. You cannot have a safe vehicle that isn't secure, and you cannot have a secure vehicle running on poor quality code. This friction results in a slow and rigid development process

Automotive manufacturers are shifting away from proprietary, legacy stacks. To keep pace with consumer expectations, OEMs are relying on open source software (OSS) to drive in-vehicle software, modern cloud development, continuous integration (CI/CD), and virtual ECU (vECU) testing. The "cloud to road" paradigm promises rapid deployment and unprecedented agility.

The "Bazaar" model of open source thrives on rapid innovation and community collaboration, which often collides with the rigid, documentation heavy compliance structures of the automotive world. Standard open source projects do not inherently provide the traceability or 15 year liability that Tier 1 suppliers and OEMs demand.

Bridging the gap between the upstream velocity of Linux and the downstream rigor of automotive standards requires more than just a repository: it requires a new framework capable of bridging open source with the high standards of mission-critical systems.

The three pillars of dependable Ubuntu

To solve this gap, Canonical introduces a unified framework where dependability is not an afterthought, but a native property of the OS. We define dependability as the ability to deliver service that can justifiably be trusted. We do not view security, quality, and safety as isolated tasks; Instead, they form the three integrated pillars of the automotive platform.

• Security: Hardened against intrusion. The ability of the system to protect itself against accidental or deliberate intrusion. We align with ISO/SAE 21434 to ensure the vehicle is hardened against external threats.  

• Quality: Predictable over a 15-year lifecycle. The measure of the correctness of the software. This involves internal metrics like maintainability and code complexity. Verification and traceability are crucial to ensure that the system behaves predictably over a 15-year vehicle lifecycle.

• Safety: The absence of unreasonable risk. Guided by ISO 26262, safety ensures that even if a component fails, it does so in a "fail safe" manner. A critical component of this is maintaining freedom from interference (FFI). 

Transform open source agility into automotive rigor

Canonical steps in as the player capable of redesigning rigid compliance processes to natively adapt to open source paradigms. We were the first to achieve the ISO/SAE 21434 cybersecurity certification for our security process.  We take the raw speed of the open source community and wrap it in the structure, continuous patching, and strict process isolation required for homologation. The result is a dependable foundation that allows you to innovate at the speed of software without ever compromising on compliance.

Join our mission

If you are passionate about bridging the gap between open source agility and automotive rigour, and you want to work on a platform that powers millions of devices from the cloud to the car, we want to hear from you. Join us in our mission to make Ubuntu the dependable global standard for every vehicle on the planet.

Work with us

Further Reading

• Learn how to run Ubuntu for specific security standards
• Canonical achieves IEC 62443-4-1 compliance
• Canonical achieves ISO 27001 certification  

In the traditional automotive world, teams often work in silos: the cybersecurity experts lock down the ports, the quality assurance teams hunt for bugs, and the functional safety engineers track the ISO 26262 compliance. At Canonical, we believe this fragmented workflow causes friction rather than collaboration.


Categories: Automotive
Source: https://ubuntu.com//blog/beyond-safety-and-security-why-automotive-open-source-demands-dependability Jul 06, 2026, 05:12 PM

Ubuntu 26.04 fixes Papers bug that sent PDF links to wrong page

Ubuntu 26.04 LTS is prepping a bug fix update to Papers, the document viewer that replaced Evince in 25.04, resolving several annoyances – including internal PDF links that jumped to the wrong page. The internal link snafu only occurred in some PDFs, not all, and typically took you to a page one off the actual target. Annoying. The fix stops two separate bits of code that both tried to set the zoom level when links jumped to fit-width or fit-page view. A knock-on quirk also saw the alt + p shortcut (which will jump back to the previous page) wouldn't [...]

You're reading Ubuntu 26.04 fixes Papers bug that sent PDF links to wrong page , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, App Updates, Bug Fixes, Papers, PDF, Ubuntu 26.04 LTS
Source: https://www.omgubuntu.co.uk/2026/07/ubuntu-26-04-papers-pdf-viewer-bug-fixes Jul 13, 2026, 07:31 PM

Changing Night Light's colour temperature during the day

Night Light Scheduler is a new GNOME Shell extension that lets you control how warm your screen is throughout the evening (or day). GNOME's built-in Night Light feature offers a customisable daily schedule, and lets you pick a colour temperature that's more or less orange (which will reduce blue light emitted by your device's display). But that temperature you set holds the entire time Night Light is switched on. It eases in and out at each end but it never changes in between. For most of us, the default behaviour is fine. It's set-and-forget to a fixed schedule. But if [...]

You're reading Changing Night Light's colour temperature during the day , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, GNOME Extensions, night light
Source: https://www.omgubuntu.co.uk/2026/07/night-light-scheduler-gnome-extension Jul 13, 2026, 01:48 AM

Ubuntu 26.10 retires dbus-daemon after 22 year run as default

Ubuntu 26.10 is replacing its D-Bus implementation for the first time since 2004, swapping dbus-daemon for dbus-broker – a change end-users are unlikely to notice. Processes on your desktop talk to each other and to the host system using D-Bus, a 'message' bus. This is what the Ubuntu Dock uses to show unread-count badges for apps, what tells your desktop a USB drive has been plugged in, and so on. Two buses are in play. There's aa system bus, shared across the whole device, handling hardware and background services, and a user session bus to handle desktop and app integrations [...]

You're reading Ubuntu 26.10 retires dbus-daemon after 22 year run as default , a blog post from OMG! Ubuntu . Do not reproduce elsewhere without permission.


Categories: News, dbus, Ubuntu 26.10
Source: https://www.omgubuntu.co.uk/2026/07/ubuntu-26-10-dbus-broker Jul 11, 2026, 04:56 AM