Canonical is not rewriting all of Ubuntu in Rust, but it has begun replacing core system components in areas where it believes the memory-safety and maintenance benefits justify the cost of migration. According to Jon Seager, Canonical’s Vice President of Engineering, during a broadcast organized by JetBrains, the decision is part of a long-term vision for a platform that runs around 15 million deployments across servers, desktops, edge devices, and inside cars.
The approach begins with a question about what Ubuntu will need over the next two decades, rather than with a campaign to reimplement every existing tool. Canonical believes Rust offers a compelling toolkit for systems development, particularly when resistance to memory errors and reliability are important factors in software running inside industrial systems, cars, or sensitive infrastructure.
Selective replacements instead of a wholesale rewrite
The first of these components arrived in Ubuntu 26.04 LTS. uutils coreutils, a Rust reimplementation of the GNU coreutils, became the default option, with a stated goal of achieving full compatibility with GNU tool behavior. This means that a small behavioral difference is not necessarily treated as an improvement; it may be considered a bug if it breaks a script or tool that relies on the old behavior.
sudo-rs is taking a different path. Instead of seeking complete compatibility with sudo, the project rethinks what a privilege-granting tool should look like if it were designed today after decades of security experience. One of the changes that prompted strong reactions is the default display of asterisks when entering a password in the terminal. Canonical says it accepts these intentional changes even when they cause short-term friction, because it views them as part of a new design rather than merely as a compatible replacement.
Time and certificates within the scope of change
The next project is ntpd-rs, which Canonical announced in June 2026 would be funded through the Trifecta Tech Foundation with the goal of making it Ubuntu’s default time-synchronization tool. The plan is to archive it in Ubuntu 26.10, then switch to it fully as the default option in Ubuntu 28.04, gradually replacing chrony and linuxptp through a single tool that supports NTP, NTS, and PTP.
The importance of this change stems from the fact that accurate time synchronization is not limited to network servers. It affects microcontrollers inside aircraft, cars, and robots; cryptographic systems that rotate keys periodically; and systems that rely on location. The article explains that using chrony and linuxptp together may require configuring multiple tools and time sources, while ntpd-rs aims to combine these functions into one tool and one configuration file, while benefiting from memory safety.
The UPKI project differs from these replacements because it is a new project built from scratch in collaboration with the Rustls project, and aims to add certificate-revocation checking to system tools in Linux. Canonical is targeting its initial arrival in Ubuntu 26.10. The idea is connected to tools such as curl, wget, and OpenSSL, which the article says have not incorporated this type of certificate-revocation handling in the same way as browsers.
What is changing for users in practice?
Canonical chose LTS release boundaries for introducing these changes because organizations typically update their systems at these points, and because having a rollback path is important when changing low-level tools. The article says that previous releases will receive managed support for 15 years, and that legacy tools will remain in the archive, so the new behavior will not be imposed on an existing production system without an option to return.
However, compatibility is not uniform across the projects. uutils coreutils encountered a practical example when its head tool returned an error when asked to read a number of bytes from an empty file, whereas GNU coreutils returned zero. This difference broke a script hidden inside the Obsidian snap package, so the behavior was modified to match GNU. The example shows that memory safety does not eliminate the importance of compatibility with assumptions that have accumulated around older tools over 30 years.
The challenge does not end with writing the code
Introducing Rust into a large distribution also requires addressing dependency, build, and distribution chains. Canonical uses an approach that bundles each package’s crates into a single archive instead of packaging every crate as a separate deb package. According to the article, this helps keep the dependency surface manageable and make builds deterministic, although not reproducible in the formal sense.
Earlier in 2026, cargo auditable was rolled out across all Rust packages in the Ubuntu archive. Each Rust binary contains an embedded SBOM recording the names and versions of the crates used in the build, and it is updated automatically when the package is rebuilt. This data does not prevent vulnerabilities, but it makes identifying affected versions when a problem is discovered in one of the dependencies more straightforward.
certi.news analysis: The real change here is not merely replacing tools written in C with tools written in Rust, but introducing a layer of security, maintenance, and dependency tracking to components that are difficult to change once they have become widespread. At the same time, the compatibility examples and the behavior of sudo-rs reveal that the transition may impose design decisions users notice, and that its success will depend as much on managing those differences as on the implementation language. The announced schedules for ntpd-rs and UPKI remain future targets, while the source shows that the scope of change is selective and that legacy tools and rollback options remain part of Canonical’s strategy.