AHXproject

Archinstall 4.0 Arch Linux Installer Released with New Textual UI



Archinstall 4.0 Arch Linux menu-based installer is now available for download with a new TUI (text-based user interface), new features, and various improvements.

The post Archinstall 4.0 Arch Linux Installer Released with New Textual UI  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Apps, News, Arch Linux, Arch Linux installer, archinstall
Source: https://9to5linux.com/archinstall-4-0-arch-linux-installer-released-with-new-textual-ui Mar 31, 2026, 01:18 AM

Debian-Based Elive Linux Distro Is Back with First Stable Release in Seven Years



Elive 3.8.50 LTS distribution is now available for download based on Debian GNU/Linux 12 "Bookworm" and featuring support for the OpenRC init system and the latest Enlightenment desktop.

The post Debian-Based Elive Linux Distro Is Back with First Stable Release in Seven Years  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Distros, News, Debian, Elive, Enlightenment, Linux distribution
Source: https://9to5linux.com/debian-based-elive-linux-distro-is-back-with-first-stable-release-in-seven-years Mar 31, 2026, 12:54 AM

How to manage Ubuntu fleets using on-premises Active Directory and ADSys



The "hybrid fleet" is today's reality: organizations diversify operating systems while Microsoft Active Directory (AD) remains the dominant identity "source of truth." IT administrators must ensure Linux machines, like Ubuntu desktops and servers, behave as first-class citizens in this environment. Efficient Linux management demands unified identity and policy management, ensuring that local authentication mechanisms and system configuration on Ubuntu endpoints respect the central authority of AD.

AD and the System Security Services Daemon (SSSD)

For Ubuntu, the SSSD acts as the foundational technology for Active Directory integration. Instead of disparate config files or legacy LDAP scripts, SSSD has long provided a modular architecture that abstracts the complexities of backend providers.

When configured with the AD provider, SSSD communicates natively with domain controllers using standard protocols: Kerberos for authentication and LDAP for directory queries. SSSD automatically maps SID-to-UID/GID, translating Windows Security Identifiers (SIDs) into Linux-compatible numeric User IDs (UIDs) and Group IDs (GIDs) for file access. This eliminates the need to manually extend the AD schema with Portable Operating System Interface (POSIX) attributes, cutting deployment friction significantly.

Enterprise fleets, especially mobile workstations, need reliable offline access. SSSD delivers this by caching password hashes locally via cache_credentials and offline_credentials_expiration, keeping users authenticated – even when disconnected from the corporate network.

The power of Group Policy Objects (GPOs) with Active Directory System Services (ADSys)

SSSD handles identity ("who"), but historically couldn't manage configuration ("what") with the same depth as Windows clients. That gap is where ADSys becomes the core value proposition for the enterprise.

ADSys is a native Group Policy Object (GPO) client for Ubuntu, letting IT administrators use existing AD knowledge and infrastructure to manage Ubuntu fleets. Active Directory Policies apply at two points: computer policies at boot, and user policies at login. This mirrors the Windows management experience, ensuring interoperability between Linux and Windows, without requiring parallel infrastructure management tools.

Quick reference: ADSys capabilities

ADSys supports the following management capabilities:

FeatureDescriptionPrivileges managementCentrally grant or revoke sudo privileges for AD users and groups without manually editing local /etc/sudoers files on individual machines.Script executionAutomate configuration by scheduling shell scripts to execute at system startup, shutdown, user login, or user logout to remediate configuration drift.Desktop configurationEnforce specific desktop settings (e.g., screen lock timeouts, wallpaper, application access) via. the dconf settings framework.AppArmor managementEnforce custom AppArmor profiles to restrict application capabilities system-wide, enhancing the security posture of the endpoint.

Learn more in our technical documentation .

Compliance and security with certificate auto-enrollment

Integrating local authentication with Active Directory is not only an enterprise compliance and security requirement, but also a convenience. Centralizing identity enforces security and governance policies, password complexity, and account lockout thresholds, consistently across the entire heterogeneous fleet.

ADSys also supports certificate auto-enrollment from Active Directory Certificate Services (AD CS). Clients enroll for machine certificates, which the certmonger daemon continuously monitors and refreshes, improving the security of communication and supporting compliance with encryption standards within legacy corporate networks.

The Ubuntu Pro advantage

All of ADSys features are provided by Ubuntu Pro . An Ubuntu Pro subscription provides access to the ADSys client and the administrative templates (.ADMX/.ADML) needed to expose Ubuntu-specific settings in the Windows Group Policy Management Console.

SSSD's authentication combined with ADSys's policy enforcement gives Canonical's solution a decisive advantage: it maximizes existing AD infrastructure investment while putting Ubuntu systems on the path to compliance, backed by the long-term support (LTS) enterprise environments demand.

Learn more about identity management 

In our newly released whitepaper we provide actionable blueprints and technical specifications to architect, define, and enforce robust identity management controls across your entire server and desktop fleet, regardless of operating system.

 We provide a technical examination of modern identity paradigms, including detailed configurations for managing access to cloud and on-premise Linux infrastructure, and practical strategies for seamless and secure integration with legacy AD Domain Services. Furthermore, the paper offers a detailed analysis of the advantages and implementation steps for using SSH certificates for frictionless, auditable SSH authentication, moving beyond simple key management. 

Read the Ubuntu Enterprise Identity Management whitepaper .

Further reading

• ADSys documentation
• Authd documentation
• Authd for Entra ID on Snapcraft
• Authd for Google IAM on Snapcraft
• Authd for OIDC on Snapcraft

The "hybrid fleet" is today's reality: organizations diversify operating systems while Microsoft Active Directory (AD) remains the dominant identity "source of truth." IT administrators must ensure Linux machines, like Ubuntu desktops and servers, behave as first-class citizens in this environment. Efficient Linux management demands unified identity and policy management, ensuring that local authentication mechanisms and [...]


Categories: Active Directory, Authentication, Identity Management, Ubuntu, Ubuntu Desktop, Ubuntu Pro, Ubuntu Server
Source: https://ubuntu.com//blog/manage-ubuntu-fleets-active-directory Mar 31, 2026, 11:30 AM

Coreboot 26.03 Open-Source Firmware Adds Full Support for Intel PantherLake SoCs



Coreboot 26.03 open-source firmware is now available for download with full support for Intel PantherLake SoCs and other changes. Here's what's new!

The post Coreboot 26.03 Open-Source Firmware Adds Full Support for Intel PantherLake SoCs  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Drivers, News, Coreboot, firmware, Linux firmware
Source: https://9to5linux.com/coreboot-26-03-open-source-firmware-adds-full-support-for-intel-pantherlake-socs Mar 30, 2026, 07:06 PM

Simplify bare metal operations for sovereign clouds

The way enterprises are thinking about their infrastructure has changed. 

Digital sovereignty of all kinds – data sovereignty, operational sovereignty, and software sovereignty – have begun to dominate the infrastructure discussion. Today, these abstract terms have become practical concerns for platform teams. Changing regulations, geopolitical uncertainty, and growing concerns about vendor dependency are forcing organizations to take a closer look at where their infrastructure runs, and who truly controls it.

We've discussed how to achieve enhanced data security in your sovereign cloud  previously. However, in this blog, we'll be diving into an underexplored topic: the metal underlying sovereign clouds. We'll consider sovereignty and how it relates to infrastructure, highlighting the reasons why avoiding vendor dependence is so important, and how bare metal automation can help to make sovereignty sustainable.

Sovereignty: getting control of your metal

Most enterprises aiming to improve their control over their data and infrastructure begin with data sovereignty. Data residency, encryption, access controls, and compliance frameworks are the most visible requirements, and they are usually the first to be addressed. These measures are necessary, but they only answer part of the question. For a deep dive into the factors driving sovereignty, and why data sovereignty isn't enough, check out our webpage  and our whitepaper, "Sovereign cloud: the essential guide for enterprises."

For sovereign clouds, a specific aspect is often overlooked: the ability to provision, change, and recover infrastructure independently, without relying on vendor-specific tooling. Control on paper does not always translate into control in practice, especially below the operating system.


Operational dependency is a sovereignty risk

The weakest point in many sovereign cloud designs lives beneath the layers that platform teams usually focus on. Firmware, bootloaders, out-of-band management interfaces, and provisioning workflows are frequently invisible to application teams, and often poorly documented.

Having control over your infrastructure is not limited to where your hardware is located, or who owns it; it's also crucial to consider how it is operated. When those processes depend on proprietary tools, vendor-specific interfaces, or undocumented workflows, the operational dependency becomes a real risk.

These dependencies are often invisible until something changes: a vendor contract ends, hardware needs to be upgraded to newer or more capable machines, or key platform engineers leave the organization. Suddenly, the ability to operate the infrastructure independently disappears.

Several common risks show up at the bare metal layer. Firstly, you cannot audit what you do not control. When provisioning is manual or handled by third parties, it becomes difficult to maintain a clear view of what is actually running on each server. Firmware versions, boot settings, network configuration, and management interfaces differ from machine to machine and are outside the scope of most platforms.

Secondly, having unclear foundations makes it harder to manage what is built on top. The reliability of encryption, access policies, and application security relies on a stable and predictable inventory and provisioning process. Because of this, operational dependency becomes a structural risk. Manual workflows, proprietary provisioning tools, or knowledge concentrated in a small team create hidden dependencies that don't scale well.

Finally, slow provisioning makes it harder to maintain sovereignty over time. Sovereign platforms need to scale, recover, and evolve. When bringing new hardware online takes too long or requires manual coordination, maintaining control becomes harder with every change.

When building your sovereign cloud, it is important to avoid these traps. A sovereign platform must be something the organization can operate, evolve, and recover on its own terms, even as people, vendors, and hardware change.

Bare metal automation makes sovereignty sustainable

Bare metal automation addresses these risks by bringing consistency to the lowest layer of the stack. Instead of treating physical servers as special cases, it treats them as flexible programmable assets, establishing the same processes from virtual machines to bare metal.

In particular, bare metal automation provides several specific capabilities that matter for sovereign clouds:

• Transparent hardware inventory: Servers and their internal hardware capabilities are discovered, inventoried and commissioned, providing a single source of truth. This is essential when infrastructure ownership and configuration must be demonstrable to regulators and auditors, supporting robust compliance within a sovereign cloud.
• Repeatable provisioning: Servers are provisioned the same way every time, using defined and versioned processes. This makes the infrastructure easier to rebuild when sovereignty depends on reproducibility instead of trust.
• Clear ownership of the provisioning pipeline: The organization controls how machines are discovered, configured, and brought into service, without relying on vendor-specific tooling or external actors, preserving operational control over the physical layer.
• Faster, more reliable operations: New hardware can be added, replaced, or repurposed quickly, allowing sovereign platforms to scale, recover, and evolve without losing control during routine changes or exceptional events..
• Hardware testing before and after production: Hardware needs to be tested before going into production, helping ensure that only known, compliant machines are part of the sovereign infrastructure.
• Less dependence on tribal knowledge: Operational knowledge is captured in systems and processes rather than living only in people's heads, reducing the risk that sovereignty depends on specific individuals rather than the organisation itself.

Together, these capabilities turn sovereignty into something that can be maintained over time. Control of the physical layer becomes explicit, verifiable, and repeatable, which is exactly what sovereign cloud initiatives depend on as they move from initial deployment to long-term operation.

Closing the gap with MAAS

Bare metal automation platforms exist to address this exact problem. Canonical MAAS  is an open source platform that provides a central control plane for managing and provisioning physical servers using infrastructure-as-code principles. It offers a consistent, cloud-like management experience for pools of physical servers across heterogeneous hardware environments, making it easier for platform teams to apply the same operational practices everywhere.

Deploy any OS on any HW with MAAS

Several aspects of MAAS are particularly relevant in the sovereign cloud context. Together, they address the need for demonstrable control, operational independence, and repeatability at the physical layer, which are crucial for sovereign cloud initiatives:

• End-to-end lifecycle control: MAAS automates the full lifecycle of physical machines, from discovery and commissioning to deployment, reuse, and decommissioning. Using standard out-of-band management interfaces such as IPMI or RedFish, it keeps power control and provisioning across a wide range of certified hardware  without the need of vendor-specific tooling.
• Infrastructure as code for bare metal: A stable, well-defined API allows hardware to be managed programmatically and integrated into existing workflows. Treating physical infrastructure as code makes provisioning repeatable, auditable, and easier to evolve without relying on manual intervention.
• Hardware validation at scale: Built-in diagnostics allow machines to be tested before they enter production and again when they are recycled or repurposed. This helps maintain a healthy and compliant pool of servers, which is essential for predictable operations and reliable recovery.
• Accurate inventory and configuration awareness: Detailed hardware inventory makes it possible to place workloads based on real capabilities.
• Integrated network configuration and services: MAAS configures server network interfaces with bridges, VLANs, bonds and addresses, and it integrates highly available, open source DHCP and DNS services.

Taken together, these capabilities address the gaps that often undermine sovereign cloud efforts at the physical layer, and they give platform teams a way to operate bare metal with the same level of control, visibility, and discipline they expect from higher layers of the stack.

Conclusions and next steps

Sovereign clouds only work if control can be maintained over time. Data protection and application-level controls are important, but they depend on how the infrastructure underneath is built and operated. When the physical layer is opaque or hard to manage, sovereignty is difficult to implement.

Bare metal management is where many of these issues surface. Automating this layer reduces the dependency on vendors and individuals, makes infrastructure easier to audit, and allows platforms to evolve without losing control. 

For organizations serious about sovereign infrastructure, this is not about adding another tool. The core idea is to establish the foundational layer in a way that sustains long-term sovereignty.

MAAS is designed to help teams bring that level of control to physical infrastructure. If you are thinking about your cloud sovereignty strategy and rethinking how you run bare metal today, it is worth taking the time to see how MAAS works  and what problems it can remove from daily operations.You can try MAAS  on your own and decide whether it fits your platform. If you want help designing or running MAAS at scale, Canonical also provides professional support. Reach out  if you would like to discuss your requirements or take the next step.

The way enterprises are thinking about their infrastructure has changed.  Digital sovereignty of all kinds – data sovereignty, operational sovereignty, and software sovereignty – have begun to dominate the infrastructure discussion. Today, these abstract terms have become practical concerns for platform teams. Changing regulations, geopolitical uncertainty, and growing concerns about vendor dependency are forcing organizations [...]


Source: https://ubuntu.com//blog/simplify-bare-metal-operations-for-sovereign-clouds Mar 31, 2026, 12:10 AM

4MLinux 51.0 Released with Improved Support for ZX Spectrum and Atari Music



4MLinux 51.0 distribution is now available for download with improved support for ZX Spectrum and Atari music and other changes. Here's what's new!

The post 4MLinux 51.0 Released with Improved Support for ZX Spectrum and Atari Music  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Distros, News, 4MLinux, independent distro, Linux distribution
Source: https://9to5linux.com/4mlinux-51-0-released-with-improved-support-for-zx-spectrum-and-atari-music Mar 30, 2026, 06:21 PM

How to Harden Ubuntu SSH: From static keys to cloud identity



30 years after its introduction, Secure Shell (SSH) remains the ubiquitous gateway for administration, making it a primary target for brute force attacks and lateral movement within enterprise environments. For system administrators and security architects operating under the weight of regulatory frameworks like SOC2, HIPAA, and PCI-DSS, default SSH configurations are an "open door" that represents an unacceptable risk. As such, accessibility often comes at the cost of security, permitting practices like root login and password authentication that significantly expand the attack surface. At Canonical, we have been focusing on developing solutions to close these gaps, enforcing a "defense-in-depth" strategy that aligns strict access control with centralized identity management.

Linking identity systems to SSH

Traditionally, Linux authentication relied on static credentials stored in /etc/passwd or unmanaged SSH keys scattered across authorized_keys files. At an enterprise scale, this creates massive "identity debt", with orphaned keys remaining on servers long after employees depart, creating shadow access paths.

To eliminate this vulnerability, SSH should integrate directly with authoritative identity sources. For on-premise environments, systems like System Security Services Daemon (SSSD) can serve as the bridge to Active Directory. When Ubuntu systems join a domain, SSSD handles the authentication exchange, validating Kerberos tickets and automatically creating home directories. This ensures that SSH access privileges are dynamically tied to Active Directory group memberships, instantly revoking access when a user is disabled in the central directory.

How can you use IdPs to authenticate SSH sessions?

For organizations transitioning to cloud based identity providers (IdPs) like Microsoft Entra ID or Google Cloud IAM, we developed authd. This service modernizes the Linux desktop and server by utilizing a modular broker architecture to facilitate authentication against cloud IdPs.

For SSH, authd leverages the OAuth 2.0 Device Authorization Grant (RFC 8628). Since SSH sessions often occur on headless servers lacking a web browser, authd initiates a device flow where the user authenticates via a secondary device (such as a smartphone or a laptop) using their IdP credentials. This architecture allows Ubuntu to enforce Multi-Factor Authentication (MFA) and conditional access policies defined at the IdP level for every SSH login. By centralizing SSH authentication through authd, we eliminate the reliance on static public keys, ensuring that every access request generates an audit trail linked to a managed cloud identity.

Meeting your compliance and cryptographic requirements

For tightly regulated sectors, satisfying compliance controls is not optional. Ubuntu Pro, Canonical's comprehensive subscription for open source security, provides the infrastructure required to meet stringent standards such as NIST, DISA-STIG, and PCI-DSS. These frameworks mandate rigorous technical controls regarding authentication assurance levels and session management.

With Ubuntu Pro, organizations can automate the application of security benchmarks and hardening profiles across their fleet. This ensures that the cryptographic exchanges and key management protocols underlying SSH connections adhere to the validated standards required for audits 10. We provide the tools to ensure that your gateway security is not just theoretical, but compliant by design.

Can you enforce policies at scale?

Defining a secure configuration is only half the battle. Enforcing it across thousands of nodes is the real challenge. With Adsys, administrators can extend Group Policy Objects (GPOs) to Ubuntu clients.

Using ADsys, we enable the enforcement of security policies and the execution of scripts at system startup or login. This allows security teams to centrally mandate SSH configurations, such as disabling root login or enforcing protocol versions, ensuring that no machine drifts from the approved security baseline. Through centralized privilege management, we can also grant or revoke sudo rights for specific AD groups without manually editing local files, strictly adhering to the Principle of Least Privilege.

Security checklist: hardening SSH

To reduce the attack surface of your Ubuntu infrastructure, we recommend implementing the following hardening measures.

• Disable root login: set PermitRootLogin no in sshd_config to force user accountability.
• Eliminate passwords: set PasswordAuthentication no and mandate public key or IdP-based authentication.
• Enforce MFA: integrate libpam-google-authenticator or use authd with Entra ID/Google IAM for multi-factor verification.
• Restrict network access: use firewalls to allow SSH connections only from trusted IP ranges or VPNs 15.
• Active monitoring: configure Fail2Ban to monitor authentication logs and automatically ban IP addresses exhibiting brute-force behavior.
• Change default ports: configure SSH to listen on a non-standard port (e.g., 2222) to reduce noise from automated scanners.

Read more in our identity management whitepaper

In our newly released whitepaper we provide actionable blueprints and technical specifications to architect, define, and enforce robust identity management controls across your entire server and desktop fleet, regardless of operating system.

We provide a technical examination of modern identity paradigms, including detailed configurations for managing access to cloud and on-premise Linux infrastructure, and practical strategies for seamless and secure integration with legacy AD Domain Services. Furthermore, the paper offers a detailed analysis of the advantages and implementation steps for using SSH certificates for frictionless, auditable SSH authentication, moving beyond simple key management. 

Read the Ubuntu Enterprise Identity Management whitepaper .

Further reading

• ADSys documentation
• Authd documentation
• Authd for Entra ID on Snapcraft
• Authd for Google IAM on Snapcraft
• Authd for OIDC on Snapcraft

30 years after its introduction, Secure Shell (SSH) remains the ubiquitous gateway for administration, making it a primary target for brute force attacks and lateral movement within enterprise environments. For system administrators and security architects operating under the weight of regulatory frameworks like SOC2, HIPAA, and PCI-DSS, default SSH configurations are an "open door" that [...]


Categories: Active Directory, Authentication, ssh, Ubuntu, Ubuntu Desktop, Ubuntu Server
Source: https://ubuntu.com//blog/how-to-harden-ubuntu-ssh-cloud Mar 30, 2026, 11:57 AM

GNOME 51 "A Coruña" Desktop Environment Scheduled for September 16th, 2026



The development cycle of the upcoming GNOME 51 "A Coruña" desktop environment kicks off with a draft release schedule suggesting the final release is expected later this year on September 16th, 2026.

The post GNOME 51 "A Coruña" Desktop Environment Scheduled for September 16th, 2026  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Desktops, News, desktop environment, GNOME
Source: https://9to5linux.com/gnome-51-a-coruna-desktop-environment-scheduled-for-september-16th-2026 Mar 30, 2026, 09:17 AM

The "scanner report has to be green" trap 

Stability, backports, and hidden risks of the bleeding edge

In the modern DevSecOps world, CISOs are constantly looking for signals in the noise, and the outputs of security scanners often carry a lot of weight. A security scan that returns a "zero CVE" report often unlocks promotion to production; a single red flag can block a release.

This binary view of security has birthed two diametrically opposed philosophies. On one side, we have the long-term support  (LTS) approach: stay on a battle-tested version and backport specific security fixes. On the other hand, we have the push-the-latest approach: stay ahead of the CVEs by constantly moving to the latest version upstream.

In this article, I will compare the pros and cons of the "push the latest" approach and the "LTS approach", and argue that while "rolling forward" makes your scanners happy, it might be making your infrastructure more fragile.

The case for the backport: stability is the security pillar

The LTS model is built on the principle of minimal change. For instance, when a vulnerability is found, Canonical security engineers extract the minimal set of changes required to fix the issue and apply it to the older versions.

The benefit of this model is stability: you get the security fix without the "feature churn." Your APIs don't change, your configuration files don't break, and your application behavior remains predictable. Stability isn't just about APIs. It's about resource consumption. An LTS backport doesn't suddenly double your memory usage or add new background telemetry – something the 'latest' version might do without warning.

However, this approach might be a challenge for vulnerability management because many security scanners rely primarily on version strings. Because some of these tools may not always have immediate visibility into the specific, surgical patches backported to an older version, they might flag a package as vulnerable based simply on its version number alone. This creates "CVE noise" and security teams have to then spend hours writing exceptions and ignore lists, to justify why the scanner's report is a non-issue. 

To bridge this gap, we collaborate with the top security scanner partners to share deep-level vulnerability data. By providing this visibility, we ensure their tools can accurately recognize backported fixes, significantly reducing the manual burden on security teams to investigate and justify these reports.

The flaws of the "push the latest" approach

Some vendors solve the problem by simply using the latest version of everything. As long as you are on the latest version, the scanner sees no known vulnerabilities. It feels like magic: you get a clean report and your auditors are happy. 

However, "push the latest" approach operates on a dangerous assumption: that "newer" is always "safer." Let's examine some of the negative points and risks of this approach.

1. The "Unknown Unknown" risk

A CVE is a known vulnerability. When you use an older, widely-deployed version of a package (like those in Ubuntu LTS), you are likely using code that has been "seasoned" by years of global production use. 

In contrast, when you pull the latest version of a package that was released 48 hours ago, you are the first line of testing of a bleeding edge. You have potentially traded a known vulnerability (which might already be patched and backported) for an unknown, undiscovered, and unfixed vulnerability in the latest version.

2. The XZ Utils cautionary tale

The XZ Utils backdoor (CVE-2024-3094) is the ultimate rebuttal to the "always latest" philosophy. In this infamous example, the malicious code was injected into the latest "bleeding edge" versions of the tool. Every new line of code is a potential new vulnerability.

Users of distributions like Debian Stable or Ubuntu LTS were protected by default, not because they were smarter, but because their reliance on proven, distribution-vetted code acted as a mandatory cooling-off period for the global supply chain. In comparison, the "push the latest" model of rapid ingestion creates a highway for these types of sophisticated attacks to reach production.

3. Introducing breaking changes inadvertently

If you're using the "push the latest" model, the stability of your environment also gets hit, because your dependencies are constantly shifting. A minor version update upstream might include a "fix" that changes how a library handles memory or network timeouts.

If your image rebuilds every morning with the "latest" packages, you may find your application failing in production due to a regression that was never caught in your CI/CD pipeline, simply because the upstream developers changed a default setting you relied on. Furthermore, if you miss even a single update cycle, this fragile house of cards collapses, leaving you to wonder if your environment was ever truly stable to begin with.

Security versus compliance

When you consider the debate of the "LTS approach" vs "push the latest", it becomes clear where the real source of the tension really lies: in the balance between security and naive compliance.

Vendors who champion the "push the latest" model haven't necessarily fixed the problem; they've just shifted the risk. By building custom, rolling-release operating systems stripped of historical stability, they promise instant patching. At the expense of the LTS promise of guaranteed compatibility. 

In the container world, they argue that breaking changes don't matter because containers are ephemeral. However, while containers may be ephemeral, software contracts are not. Your application relies on stable APIs, ABIs, and library behaviors. When you blindly target the latest, you are constantly shifting the ground beneath your application. It doesn't matter how fast a container can restart if the new upstream package it just pulled fundamentally breaks your app's dependencies. A fast crash is still an outage.

Conclusion

The choice comes down to what you value more: a quiet scanner or a quiet night on-call. While chasing upstream versions offers the instant gratification of a green dashboard, it does so by offloading the vetting process to your production environment.

True security requires the vital work of backporting – fixing vulnerabilities without introducing volatility. In a world where supply chain attacks are the new frontier, stable, battle-tested code isn't just a convenience. It is your most critical defensive layer.

Are we actually more secure, or are we just tired of looking at red dots on a dashboard? By backporting CVE fixes, Ubuntu Pro acknowledges that code needs time to be trusted. In a world where supply chain attacks are the new frontier, stable and tested code might just be the most secure feature you have.

Further reading

• Why chasing "Zero CVEs" can be a trap, and how stability is perhaps the best security feature
• Moving beyond the scan: Explore Ubuntu's toolkit for robust, stable vulnerability management.
• Why backporting is the gold standard for maintaining security without breaking production
• Canonical's guide on how to conduct a vulnerability assessment that accounts for backporting and reduces false positives

Stability, backports, and hidden risks of the bleeding edge In the modern DevSecOps world, CISOs are constantly looking for signals in the noise, and the outputs of security scanners often carry a lot of weight. A security scan that returns a "zero CVE" report often unlocks promotion to production; a single red flag can block [...]


Source: https://ubuntu.com//blog/stability-backports-and-hidden-risks-of-the-bleeding-edge Mar 27, 2026, 03:24 PM

9to5Linux Weekly Roundup: March 29th, 2026



9to5Linux Weekly Roundup for March 29th, 2026, brings news about Firefox 149, Krita 6.0, NVIDIA 595, Ubuntu 26.04 LTS Beta, Agama 19, Thunderbird 149, Kali Linux 2026.1, FreeCAD 1.1, LibreOffice 26.2.2, Tails 7.6, Calibre 9.6, Mixxx 2.5.6, SystemRescue 13, GIMP 3.2.2, KaOS 2026.03, and more.

The post 9to5Linux Weekly Roundup: March 29th, 2026  appeared first on 9to5Linux  - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.


Categories: Weekly Roundup, 9to5Linux roundup, Linux roundup, weekly roundup
Source: https://9to5linux.com/9to5linux-weekly-roundup-march-29th-2026 Mar 30, 2026, 01:56 AM