Canonical no está reescribiendo Ubuntu por completo en Rust, pero ha comenzado a sustituir componentes esenciales del sistema en puntos donde considera que las ventajas de seguridad de la memoria y mantenimiento justifican el coste de la transición. Según explicó Jon Seager, vicepresidente de ingeniería de Canonical, durante una transmisión organizada por JetBrains, la decisión forma parte de una visión a largo plazo para una plataforma que ejecuta alrededor de 15 millones de implementaciones en servidores, equipos de escritorio, dispositivos periféricos y vehículos.
El enfoque parte de una pregunta sobre lo que Ubuntu necesitará durante las próximas dos décadas, no de una campaña para volver a implementar todas las herramientas existentes. Canonical considera que Rust ofrece un conjunto de herramientas convincente para el desarrollo de sistemas, especialmente cuando la resistencia a los errores de memoria y la fiabilidad son factores importantes en software que funciona dentro de sistemas industriales, vehículos o infraestructuras sensibles.
Sustituciones selectivas en lugar de una reescritura integral
Los primeros de estos componentes llegaron a Ubuntu 26.04 LTS. uutils coreutils, una reimplementación de las herramientas GNU coreutils en Rust, se convirtió en la opción predeterminada, con el objetivo declarado de lograr una compatibilidad total con el comportamiento de las herramientas GNU. Esto significa que una pequeña diferencia de comportamiento no se considera necesariamente una mejora, sino que puede considerarse un error si rompe un script o una herramienta que depende del comportamiento anterior.
sudo-rs sigue un camino diferente. En lugar de buscar una coincidencia total con sudo, el proyecto replantea cómo debería ser una herramienta de concesión de privilegios si se diseñara hoy, después de décadas de experiencia en seguridad. Entre los cambios que provocaron reacciones contundentes está la visualización predeterminada de asteriscos al escribir la contraseña en la terminal. Canonical afirma que acepta estos cambios deliberados incluso cuando causan fricciones a corto plazo, porque los considera parte de un nuevo diseño y no simplemente una copia alternativa idéntica.
El tiempo y los certificados también están dentro del alcance del cambio
El siguiente proyecto es ntpd-rs, cuyo desarrollo anunció Canonical en junio de 2026 mediante financiación de Trifecta Tech Foundation, con el objetivo de convertirlo en la herramienta predeterminada de sincronización horaria en Ubuntu. El plan consiste en archivarlo dentro de Ubuntu 26.10 y después adoptarlo completamente como opción predeterminada en Ubuntu 28.04, para sustituir gradualmente a chrony y linuxptp mediante una sola herramienta compatible con NTP, NTS y PTP.
La importancia de este cambio se debe a que la sincronización horaria precisa no se limita a los servidores de red. Afecta a los microcontroladores de aviones, vehículos y robots, a los sistemas criptográficos que rotan las claves periódicamente y también a los sistemas que dependen de la ubicación. El artículo explica que utilizar chrony y linuxptp conjuntamente puede requerir configurar varias herramientas y fuentes de tiempo, mientras que ntpd-rs pretende reunir estas funciones en una sola herramienta y un único archivo de configuración, aprovechando además la seguridad de la memoria.
El proyecto UPKI se diferencia de estas sustituciones porque es un proyecto nuevo creado desde cero en colaboración con el proyecto Rustls, cuyo objetivo es añadir la comprobación de la revocación de certificados a las herramientas del sistema en Linux. Canonical prevé que llegue inicialmente a Ubuntu 26.10. La idea está relacionada con herramientas como curl, wget y OpenSSL, en las que, según el artículo, este tipo de gestión de la revocación de certificados no se ha integrado de la misma manera que en los navegadores.
¿Qué cambia en la práctica para los usuarios?
Canonical eligió los límites de las versiones LTS para introducir estos cambios, porque las organizaciones suelen actualizar sus sistemas en esos momentos y porque disponer de una vía de reversión es importante al cambiar herramientas de bajo nivel. El artículo afirma que las versiones anteriores recibirán soporte gestionado durante 15 años y que las herramientas antiguas permanecerán en el archivo, de modo que el nuevo comportamiento no se imponga a un sistema de producción existente sin ofrecer una opción para volver atrás.
Sin embargo, la compatibilidad no es uniforme entre los proyectos. uutils coreutils se enfrentó a un caso práctico cuando la herramienta head devolvió un error al solicitar la lectura de un número de bytes de un archivo vacío, mientras que GNU coreutils devolvía cero. Esta diferencia rompió un script oculto dentro del paquete snap de Obsidian, por lo que se modificó el comportamiento para que coincidiera con GNU. El ejemplo muestra que la seguridad de la memoria no elimina la importancia de la compatibilidad con supuestos acumulados alrededor de las herramientas antiguas durante 30 años.
El desafío no termina al escribir el código
Introducir Rust en una distribución grande también exige abordar la cadena de dependencias, compilación y distribución. Canonical utiliza un método que agrupa los crates propios de cada paquete dentro de un único archivo, en lugar de empaquetar cada crate como un paquete deb separado. Según el artículo, esto ayuda a mantener manejable la superficie de dependencias y a hacer deterministas los procesos de compilación, aunque no sean reproducibles en el sentido formal.
A principios de 2026, cargo auditable se generalizó a todos los paquetes de Rust del archivo de Ubuntu. Cada binario de Rust contiene una SBOM integrada que registra los nombres y las versiones de los crates utilizados en la compilación, y se actualiza automáticamente cuando se vuelve a compilar el paquete. Estos datos no impiden las vulnerabilidades, pero hacen más directa la identificación de las versiones afectadas cuando se descubre un problema en una de las dependencias.
Lectura de certi.news: El cambio real aquí no consiste únicamente en sustituir herramientas escritas en C por otras escritas en Rust, sino en introducir una capa de seguridad, mantenimiento y seguimiento de dependencias en componentes que resultan difíciles de cambiar una vez que se han generalizado. Al mismo tiempo, los ejemplos de compatibilidad y el comportamiento de sudo-rs revelan que la transición puede imponer decisiones de diseño que los usuarios notarán, y que su éxito dependerá tanto de la gestión de esas diferencias como del lenguaje de implementación. Las fechas anunciadas para ntpd-rs y UPKI siguen siendo objetivos futuros, mientras que la fuente demuestra que el alcance del cambio es selectivo y que las herramientas antiguas y las opciones de reversión siguen formando parte de la estrategia de Canonical.