Rust in Ubuntu
In a Nutshell
Canonical, the company behind Ubuntu, has begun replacing core system utilities with Rust implementations—starting with uutils coreutils and sudo-rs in the 25.10 release—to improve memory safety and reduce the attack surface that drives their security patching revenue. The shift prioritizes resilience (the intersection of security and reliability) over perfect compatibility, with projects like NTPDRS for time synchronization and UPKI for browser-grade certificate handling demonstrating broader ambitions. Canonical funds upstream development and security audits rather than writing the code themselves, using their market position to drive ecosystem-wide adoption while addressing crates.io supply chain risks through vendoring and SBOM embedding.
These notes were generated by AI and may contain inaccuracies.
Orhun, Rust developer advocate at JetBrains and open-source maintainer, hosts a Rust Rover live stream discussing Ubuntu's adoption of Rust. Ubuntu is the most widely deployed Linux distribution with 15 million deployments worldwide. The 25.3 release marked the beginning of Rust's integration into Ubuntu's core tooling.
John Seager serves as VP of Engineering at Canonical. He joined Canonical over five years ago, initially focusing on cloud automation with the Guju control plane and operators. Two years ago, he took leadership of Ubuntu. His decision to adopt Rust was driven by a reflection on Ubuntu's 20-year history and what would ensure its success for the next 20 years.
Seager emphasized security and resilience as critical for all users, ranging from students to Fortune 500 companies. He views Rust as providing the most compelling tools for advancing this agenda, along with performance benefits and attracting developers interested in solving systems programming problems.
Memory safety is the primary driver for choosing Rust. While other memory-safe languages exist, Rust's borrow checker forces developers to think more carefully about code safety. Canonical generates most revenue from patching security vulnerabilities and support, making fewer vulnerabilities beneficial.
Seager defines resilience at the intersection of security and reliability. Memory safety provides better security but also better reliability, as panics can lead to both security vulnerabilities and system failures. This is particularly important for safety-critical systems including automotive and industrial applications where Ubuntu runs.
Core Utils and Sudo RS
The latest LTS ships uutils coreutils and sudo-rs. The uutils coreutils project aims for 100% bug-for-bug compatibility with GNU alternatives. Initial deployment occurred in 25.4 with subsequent polishing cycles. Some esoteric differences were discovered, including one that temporarily halted daily ISO image builds.
Sudo-rs takes a different approach, not aiming for 100% compatibility. Instead, it reimagines sudo as it would appear in 2026 with 30 years of security lessons applied. This has broken some workflows, though Canonical provides mechanisms to revert to original utilities if needed.
NTPDRS Replacement for Chrony
The upcoming release introduces the first components of NTPDRS to replace Chrony. Full replacement of all time syncing is planned for 28.04. The Trifecta Tech Foundation is funded to create a single application handling NTP, NTS, and PTP client/server with full AppArmor integration.
UPKI Project
UPKI is a Greenfield project in collaboration with the Rustls project, bringing browser-grade cryptography to low-level system utilities. It addresses certificate revocation and intermediate pre-loading, capabilities currently missing from curl, wget, and OpenSSL. MacOS and Windows have implemented similar solutions, but Linux has lacked an answer.
Accurate timekeeping becomes safety-critical in real-time systems including aircraft, automobiles, and robotic systems. Time synchronization has security implications for frequently rotating cryptographic keys and is essential for positional systems.
PTP (Precision Time Protocol) configuration has historically been complex, requiring Chrony, Linux PTP, and potentially external time sources. NTPDRS aims to consolidate all time synchronization functions into a single utility with one configuration file, offering improved efficiency and memory safety.
UPKI responds to an LWN.NET article highlighting missing certificate revocation capabilities in Linux. Traditional certificate revocation used Certificate Revocation Lists (CRLs), with OCSP (Online Certificate Status Protocol) as an interim solution that was ultimately sunsetted due to privacy concerns.
Mozilla developed CRLite, a binary format for efficient revocation data storage. UPKI fetches CRLite data daily or weekly from a mirroring service and caches it locally. The project includes upstream contributions to SSL libraries (libssl, curl, libcurl, gnutls) using callback mechanisms to check certificate revocation status.
Future capabilities may include intermediate pre-loading for websites that don't provide complete certificate chains, Merkle tree certificates for next-generation cryptography, and certificate transparency enforcement.
The Rust tools are not Ubuntu-specific. uutils coreutils and sudo-rs existed before Canonical's interest. NixOS allows using these tools, and Fedora packages some components. The key contribution was Canonical being the first major distribution to make these the default and fund necessary work, potentially easing adoption for other distributions.
Oxidizer was developed as a preview tool allowing users to test the packages before the default switch, identifying potential breaking changes.
GNU coreutils has been maintained for 30 years but still contains bugs, including occasional memory safety issues. The argument that Rust replacements have bugs is considered invalid since the original tools also have bugs. The goal is to remove low-hanging fruit for maintenance while making the platform more secure and resilient by default.
The uutils coreutils project progressed from 80%+ test compatibility to 90%+ through increased usage and funded bug fixes. Performance improvements have been achieved, with word count utility moving from 11% slower to 9% faster than GNU implementation through community optimization.
Rust's optimization primitives are more accessible to developers, and the language attracts more contributors, particularly junior developers, ensuring long-term project sustainability beyond the original 30-year maintainer base.
Both uutils and sudo-rs projects maintain regular contact with original projects, contributing patches upstream. Sylvest, uutils project lead, ranked in the top 10 contributors to the latest GNU coreutils release. When security issues are found in sudo-rs affecting original sudo, both projects collaborate on fixes.
An example incompatibility discovered: GNU head command returns zero when reading bytes from an empty file, while uutils correctly returns an error. The uutils implementation was changed to match GNU behavior for compatibility despite the counterintuitive result.
Pseudo RS makes breaking changes with explicit reasoning about security improvements. One notable change was displaying asterisks when typing the sudo password, providing visual feedback. Many users expressed strong opinions about this feature.
Internally, team members raised questions and concerns. The approach was to acknowledge the desire to implement changes while committing not to damage Ubuntu's reputation. Throughout the 2604 LTS development cycle, decisions were made about whether to continue when issues arose. Each decision required informed judgment and involved calculated risk.
The major external concern centered on licensing differences. GNU core utils uses GPL licensing, while the Uls project uses MIT licensing. The response emphasized that GPL has been crucial for Linux and open source success, and Canonical's own projects use GPL derivatives. However, the decision was about selecting an existing project whose values aligned with Canonical's, rather than writing new code. If alignment ceased, an alternative would be shipped.
Concerns about Canonical profiting from this change were addressed by noting the implausibility of monetizing commands like CP through licensing changes. The license of distributed utilities was deemed irrelevant to the core decision.
Canonical has demonstrated long-term investment in upstream contributions. The company funded significant development work and contributed patches openly, encouraging others to do the same. License questions are considered valuable to raise, but decisions require nuance based on what serves users best.
The Rust ecosystem typically prefers MIT plus Apache 2 licenses, while the Linux ecosystem generally uses GPL 2 or GPL 3. Canonical's internal projects are mostly GPL or AGPL, with AGPL used for network-based services like Lex and Guju. Apache licensing is used in ecosystems like cloud-native operators where it's the community standard. This is not a policy shift away from GPL or Linux, but rather selecting the most appropriate project for each use case.
Ubuntu's changes are expected to influence other distributions. Fedora proposed adopting Pseudo RS by default several months after Ubuntu's implementation. Nexos tends to be forward-leaning in adoption. The goal is to use Ubuntu's position to make adoption easier for others, viewing this as ecosystem benefit rather than competitive advantage. More distributions are expected to adopt similar changes.
The hardest challenges included bugs discovered when replacing 60-70 commonly used commands. Memory safety from Rust does not eliminate all code bugs. Packaging proved difficult with modern languages using crates.io package managers. Ubuntu takes a vendoring approach similar to Nix, collecting all crates into a tarball rather than creating separate debs for each crate.
Debian policy requires copyright files for every open source project shipped, necessitating tooling development. One maintainer faced excessive burden near the 2604 release, creating stressful weeks as user adoption increased.
Two independent security audits were funded for core utils projects. Sudo was not audited because it had already received formal audits and internal security review was satisfactory. Core utils lacked full security audits, so two rounds of funding and fixes were conducted. Funding alone proved insufficient without adequate personnel to distribute work.
Crates.io presents similar challenges to npm and pip, allowing untrusted code uploads. Canonical joined the Rust Foundation partly to participate in crates.io security discussions and supply chain security improvements. The left-pad incident from JavaScript serves as a cautionary example that could apply to Rust.
Ubuntu maintains parallel systems: the archive packages specific Rust compiler versions and crates for each release, while snaps and container images allow different version shipping. The Starcraft team develops generalized build systems supporting snaps, container images, VM images, and other formats using a single grammar.
Ubuntu implements cargo auditable for all deb-packaged software in the archive, embedding SBOMs with crate versions. Packages build in offline ephemeral instances pulling from known sources, providing determinism though not traditional reproducible builds branding.
Rust has strong FFI capabilities. The UPKI project created a C library for external calls. Foundational C libraries are expected to be rewritten in Rust eventually. Python examples include cryptography and Pydantic, which use Rust under the hood for cryptographic primitives while maintaining Python interfaces.
Rust's compiler provides guardrails beneficial for AI agents, preventing memory safety mistakes. A notable example is the Bun JavaScript runtime rewrite from Zig to Rust, where one developer using agents rewrote a million lines. Initial unsafe code was refined through iterative rules and bots into well-tested Rust code.
A UK university project will pair LLMs with formal methods to rewrite C code into Rust while proving behavioral equivalence and absence of certain bug classes. This makes previously infeasible rewrites viable with proper discipline and planning.
Canonical uses LLMs extensively but remains early in adoption. The approach avoids token-maximizing metrics that don't motivate good outcomes. Engineers receive tools and encouragement to become proficient users. Engineering judgment remains essential, as LLMs require human oversight to catch unintended actions.
Excellent software engineers will combine grassroots engineering skills with product thinking. Code writing becomes less expensive, making problem identification and architectural decisions more valuable. Those focused solely on traditional programming without product or architectural thinking will struggle, while those with deep architecture and engineering principles will benefit from AI as a force multiplier.
LLMs can hinder learning if used to complete work without understanding, but can serve as encyclopedia partners for exploring trade-offs. Core engineering skills remain crucial: data structures, algorithms, distributed systems, software seams, contracts, interfaces, command lines, and APIs all require human judgment. LLMs can handle painting by numbers, but outlines require human placement.
With LLM acceleration in agentic programming, deeper Rust concept understanding becomes more important. Developers can write Rust using LLMs but cannot judge code quality without understanding borrow checker mechanics, lifetimes, and other fundamental concepts.
Current funding includes work with the Trifecta Foundation on NTPDRS, which is beginning implementation. UPKI funding is nearing completion of the first round. Canonical joined the Rust Foundation as gold members with a $150,000 contribution and attends board meetings to influence direction. The Trifecta Tech Foundation also received gold membership with a 40,000 euro annual commitment to support increased maintenance from broader adoption.
Compression algorithms represent the next major category for investigation, particularly those offering efficiency improvements at Ubuntu's scale.
Making a very common compression algorithm 3 or 4% more efficient could have a meaningful impact on worldwide power consumption. This creates a side effect of making software faster and nicer to use while also having a wider environmental effect. Canonical is looking at shipping Bzip2 in Rust by default this cycle.
Canonical is investigating Zstandard (zstd-rs) and another compression library for Rust implementation. There are interesting trade-offs with these libraries. Zstandard is safer and catches certain unsafe operations that the current library allows, but it's also slower. The safety checks can be turned off to improve speed, but this raises questions about what set of defaults should be presented to users.
Canonical is not responsible for the actual rewrites of upstream projects in the Rust migration campaign. For example, UPKI didn't exist before and Canonical funded it, but they are not responsible for much of the code. They work with the Rust maintainers who are writing that code.
While packaging is the next focus for Rust adoption, Canonical does write Rust code. Current work includes boot processes, FPGA control from Linux, and compositor development. However, the big headline-making rewrites are not Canonical's Rust code - their role as a distribution is to integrate these projects into Ubuntu and ship them.
Snaps work on distributions beyond Ubuntu. They have been run on Arch Linux for years, SUSE, and NixOS through creative approaches. Canonical employs people specifically to make snaps and snapd run properly on other distributions, though Ubuntu remains the primary platform.
Canonical acknowledges that going too soon with graphical snaps years ago created a bumpy experience that left a bad taste for some users. However, snaps are particularly well-suited for low-level systems agents, observability agents, and browsers due to increased sandboxing capabilities.
Ubuntu releases a long-term support distribution every two years supported for 15 years. Backporting and maintaining compatibility on old versions can be challenging. Snaps solve this by bringing their own runtime, allowing modern capabilities to run on very old Linux systems easily.
The Snapcraft build language is now portable across Rockcraft and Charmcraft. Getting a snap in the Snap Store is contributing to Ubuntu without requiring direct involvement with the Ubuntu community. This contrasts with landing something in the archive, which requires working with the Ubuntu community for vetting.
JetBrains distributes its IDEs as snaps for Ubuntu, allowing them to control the release lifecycle. This enables shipping one version of software like RustRover that works across Ubuntu 26.04, 24.04, and 22.04. Snaps serve as a mechanism for software vendors to distribute on the world's most deployed platform.
Security confinement in snaps can make some operations difficult. While engineering work can improve this, there are inherent trade-offs with security. The packaging format solves specific problems that Canonical faces, even if it's not universally applicable.
It's possible to get snaps with elevated privileges, but these aren't granted automatically. When someone requests classic confinement for the first time, the answer is typically no because it essentially grants root access on every Ubuntu machine installing that snap. However, established vendors like JetBrains can receive these permissions after trust is established.
The consideration process involves determining whether an application can be confined, and if it cannot, whether trust can be established with the vendor. This involves evaluating whether the requested permissions are legitimate or potentially malicious.
Releasing Rust-based applications as snaps on Ubuntu is accepted practice. The speaker has personally released Rust applications as snaps.
Snaps address the challenge of high Minimum Supported Rust Versions (MSRV) because a snap with a core 26 base (based on Ubuntu 26.04) can be installed on any Ubuntu version, even very old ones. While each Ubuntu release pins users to specific Rust versions in the archive, snaps circumvent this by bringing their own modern runtime.
Even if MSRV requirements increase dramatically in 10 years, snaps from the future would be able to run on today's Ubuntu because they bring the modern runtime with them.
John will be speaking at RustConf in Montreal on the first day as keynote speaker. Canonical is hiring across multiple roles remotely worldwide.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
