Canonical continúa reemplazando componentes críticos de Ubuntu por implementaciones escritas en Rust y ya ha confirmado cuál será uno de los siguientes grandes cambios. Después de avanzar con sudo-rs y las coreutils escritas en Rust, la compañía quiere que Ubuntu 27.04 utilice ntpd-rs por defecto para la sincronización horaria del sistema.
El cambio puede parecer pequeño: sustituir el software encargado de mantener correctamente la hora. Pero detrás existe una estrategia mucho más amplia de Canonical para reducir progresivamente la cantidad de código sensible escrito en lenguajes susceptibles a errores de memoria y trasladar determinados componentes fundamentales hacia Rust.
El plan ha sido reafirmado por Canonical al presentar las mejoras de seguridad de Ubuntu 26.10. Esta versión incorpora ntpd-rs en sus repositorios para pruebas, mientras que el objetivo declarado es convertirlo en la opción predeterminada en Ubuntu 27.04.
No se trata, por tanto, de un experimento aislado. Ubuntu está construyendo progresivamente una nueva base donde más componentes privilegiados o expuestos a datos externos utilicen tecnologías con mayores garantías de seguridad de memoria.
Puede leer también | AerynOS también apuesta por uutils-coreutils y sudo-rs dentro de su sistema Linux
Ubuntu 27.04 tiene un nuevo objetivo: ntpd-rs
Canonical lo expresa claramente en su documentación reciente de seguridad.
Ubuntu 26.10 incorpora una versión actualizada de:
ntpd-rspara que usuarios, desarrolladores y administradores puedan comenzar a probarla.
El objetivo para el siguiente ciclo es:
Ubuntu 26.10
|
v
ntpd-rs disponible para pruebas
|
v
feedback + compatibilidad
|
v
Ubuntu 27.04
|
v
ntpd-rs como opción predeterminada
Si el plan se mantiene, la sincronización horaria será el siguiente componente importante del sistema base de Ubuntu que pasará a una implementación escrita en Rust.
¿Qué es ntpd-rs?
ntpd-rs es una implementación moderna de protocolos de sincronización temporal escrita completamente en Rust.
Forma parte de los proyectos impulsados por la Trifecta Tech Foundation y está orientada tanto a funciones de cliente como de servidor.
Soporta tecnologías como:
- NTP — Network Time Protocol.
- NTS — Network Time Security.
- Funciones de servidor NTP.
- Integración progresiva con PTP.
El objetivo de Canonical va más allá de sustituir una aplicación por otra.
La compañía quiere utilizar ntpd-rs como base para unificar diferentes necesidades de sincronización que actualmente pueden requerir varias herramientas independientes.
¿Por qué la hora de un servidor es un problema de seguridad?
Puede parecer que mantener correctamente el reloj es una función secundaria.
No lo es.
La hora afecta directamente a numerosos sistemas de seguridad.
Por ejemplo:
- Certificados TLS.
- Kerberos.
- Logs.
- Auditorías.
- Firmas digitales.
- Autenticación distribuida.
- Correlación de eventos.
Supongamos que un servidor tiene su reloj adelantado varios meses.
Un certificado perfectamente válido podría aparecer como:
EXPIREDo, si el reloj está atrasado:
NOT YET VALIDEl sistema podría rechazar entonces conexiones legítimas.
Kerberos también depende de una hora precisa
Los sistemas de autenticación Kerberos utilizan ventanas temporales para ayudar a prevenir determinados ataques de repetición.
Conceptualmente:
Cliente Servidor | | |---- ticket + hora ------>| | | | ¿hora válida? | | | |<------ aceptar ----------|
Si existe demasiada diferencia entre los relojes:
Cliente: 10:15 Servidor: 10:32
la autenticación podría fallar aunque las credenciales sean correctas.
Los logs también pierden valor cuando los relojes no coinciden
Imagine un incidente de seguridad distribuido entre cinco servidores.
Servidor A: 12:01 Servidor B: 11:54 Servidor C: 12:08 Servidor D: 11:59 Servidor E: 12:04
Reconstruir exactamente qué ocurrió primero puede convertirse en un problema.
Por esta razón Canonical describe la sincronización horaria como parte importante de la seguridad del sistema y no simplemente como una comodidad.
ntpd-rs apunta a sustituir a chrony en Ubuntu
Ubuntu utiliza actualmente chrony para diferentes funciones de sincronización temporal.
El plan anunciado por Canonical es que ntpd-rs alcance suficiente madurez y compatibilidad como para convertirse progresivamente en su sustituto predeterminado.
Sin embargo, Canonical no quiere limitarse a copiar exactamente lo que hace chrony.
La meta es construir una plataforma capaz de cubrir diferentes escenarios.
| Tecnología | Función |
|---|---|
| NTP | Sincronización horaria convencional por red |
| NTS | Protección criptográfica para NTP |
| PTP | Sincronización de alta precisión |
| GPSd | Uso de fuentes horarias procedentes de GPS |
Canonical quiere unificar NTP, NTS y PTP
Actualmente un sistema avanzado puede terminar utilizando distintas aplicaciones.
Por ejemplo:
chrony | +--> NTP / NTS linuxptp | +--> PTP gpsd | +--> GPS
Canonical quiere que ntpd-rs avance hacia una arquitectura más integrada.
La hoja de ruta contempla una combinación de:
ntpd-rs + Statime | v NTP NTS PTP gPTP
Esto puede simplificar especialmente sistemas empresariales, infraestructura cloud, telecomunicaciones, automoción y escenarios donde se requiere sincronización de alta precisión.
Statime tendrá un papel importante
Uno de los objetivos antes de Ubuntu 27.04 es integrar Statime.
Statime es una implementación de Precision Time Protocol escrita en Rust.
La combinación permitirá avanzar hacia un binario unificado para diferentes protocolos temporales.
Canonical quiere que Ubuntu pueda proporcionar una experiencia coherente tanto para un portátil convencional como para infraestructuras donde la precisión temporal es crítica.
Ubuntu también piensa en automóviles y sistemas industriales
El trabajo financiado por Canonical incluye soporte para gPTP.
Generalized Precision Time Protocol se utiliza en entornos donde diferentes dispositivos necesitan mantener relojes extremadamente coordinados.
Puede ser relevante para:
- Automóviles conectados.
- Sistemas industriales.
- Redes deterministas.
- Dispositivos embebidos.
- Infraestructura de telecomunicaciones.
El proyecto también contempla soporte experimental para futuros perfiles relacionados con PTP.
Pero el verdadero protagonista es Rust
La sustitución de chrony es solamente una parte de una estrategia mucho mayor.
Canonical lleva varios ciclos incorporando componentes escritos en Rust en áreas sensibles de Ubuntu.
La secuencia puede resumirse así:
sudo tradicional
|
v
sudo-rs
GNU coreutils
|
v
uutils coreutils
chrony / sincronización tradicional
|
v
ntpd-rs
La intención no es reescribir Ubuntu completamente en Rust.
Canonical está seleccionando componentes donde considera que la seguridad de memoria puede proporcionar una mejora especialmente importante.
Ubuntu 26.04 LTS convirtió Rust en una apuesta de producción
El cambio dejó de ser experimental con Ubuntu 26.04 LTS.
En esa versión Canonical incorporó como componentes predeterminados implementaciones Rust de herramientas fundamentales.
Entre ellas:
- sudo-rs
- uutils coreutils
GNU coreutils incluye comandos utilizados continuamente por administradores y scripts.
Por ejemplo:
ls
cp
mv
rm
cat
chmod
mkdir
touchSon herramientas extremadamente básicas, pero precisamente por ello se ejecutan millones de veces dentro de sistemas Linux.
Ubuntu 26.10 completa el salto de las coreutils hacia Rust
Ubuntu 26.04 todavía mantenía algunas implementaciones GNU para comandos determinados por motivos de compatibilidad.
Canonical confirma que Ubuntu 26.10 avanza otro paso y migra también esas herramientas restantes.
Entre ellas:
cp
mv
rmDe esta forma, las herramientas centrales predeterminadas pasan a ejecutarse completamente sobre las implementaciones de uutils escritas en Rust.
¿Por qué Canonical quiere reducir código escrito en C?
C es uno de los lenguajes fundamentales sobre los que se construyó Unix, Linux y buena parte de la infraestructura moderna.
Continúa siendo extremadamente importante.
Pero proporciona al programador un control muy directo sobre la memoria.
Eso puede facilitar errores como:
- Buffer overflows.
- Use-after-free.
- Double free.
- Accesos fuera de límites.
- Punteros inválidos.
Muchísimas vulnerabilidades históricas proceden de alguna variante de estos problemas.
Rust intenta eliminar categorías completas de errores
Rust está diseñado para impedir gran parte de esos errores mediante controles realizados durante compilación y mediante su modelo de ownership.
Conceptualmente:
C / C++
--------------------------------
Programador administra memoria
|
v
más libertad
|
+
más posibilidad de determinados
errores de memoria
Rust seguro
--------------------------------
Compilador verifica reglas
|
v
determinados errores
no llegan a compilar
Eso no convierte automáticamente cualquier aplicación Rust en software seguro.
Pero puede eliminar importantes categorías de vulnerabilidades de corrupción de memoria.
Rust no significa “imposible de vulnerar”
Este punto resulta fundamental.
Una aplicación escrita en Rust todavía puede contener:
- Errores lógicos.
- Autorización incorrecta.
- Problemas criptográficos.
- Configuraciones inseguras.
- Errores en dependencias.
- Uso incorrecto de bloques unsafe.
Canonical reconoce expresamente esta diferencia.
El argumento es:
reducir determinadas clases de fallos, no eliminar mágicamente todas las vulnerabilidades.
Un daemon de tiempo es un candidato especialmente interesante para Rust
Un servicio como ntpd-rs cumple dos características que lo hacen atractivo desde el punto de vista de seguridad:
Primero:
funciona durante largos periodosSegundo:
procesa tráfico procedente de la redUn daemon expuesto a información externa y ejecutándose continuamente merece una atención especial.
Reducir las posibilidades de errores de memoria en ese tipo de proceso puede disminuir superficie de ataque.
Canonical no confía solamente en Rust
Otro aspecto importante de la estrategia es que la compañía no considera la seguridad de memoria una sustitución de los mecanismos de confinamiento tradicionales.
Canonical está trabajando también en perfiles:
- AppArmor
- seccomp
para ntpd-rs.
La idea es mantener una arquitectura de defensa en profundidad.
Rust | +--> reduce errores de memoria AppArmor | +--> limita recursos accesibles seccomp | +--> limita llamadas al sistema mínimo privilegio | +--> reduce impacto
La pregunta correcta no es Rust o AppArmor
Un sistema seguro debería utilizar ambos enfoques cuando corresponda.
Rust intenta reducir la probabilidad de que aparezca determinada vulnerabilidad.
AppArmor y seccomp intentan reducir lo que un atacante podría hacer si consigue explotar un error.
Son capas complementarias.
Canonical financia directamente el desarrollo de ntpd-rs
La apuesta tampoco se limita a empaquetar un proyecto creado por terceros.
Canonical se convirtió en Gold Sponsor de la Trifecta Tech Foundation, organización detrás de varios proyectos orientados a reconstruir infraestructura fundamental mediante tecnologías de seguridad de memoria.
Entre los proyectos asociados aparecen:
- sudo-rs.
- ntpd-rs.
- zlib-rs.
- Statime.
Canonical está financiando directamente trabajo relacionado con ntpd-rs para cubrir los requisitos necesarios antes de convertirlo en una opción predeterminada.
La lista de trabajo antes de Ubuntu 27.04 es considerable
Entre los objetivos financiados se encuentran:
| Trabajo | Objetivo |
|---|---|
| GPSd por socket IP | Trabajar con fuentes GPS |
| NTP multithread | Mejorar capacidad como servidor |
| Servidores multi-homed | Múltiples interfaces y redes |
| AppArmor | Confinamiento del servicio |
| seccomp | Restricción de llamadas al sistema |
| gPTP | Entornos de alta precisión |
| Statime | Integración PTP |
| Benchmarks | CPU, RAM y precisión frente a chrony |
Canonical también entró formalmente en la Rust Foundation
La estrategia se reforzó todavía más en marzo de 2026.
Canonical se convirtió en Gold Member de la Rust Foundation.
La compañía explicó que considera Rust una tecnología cada vez más importante para construir sistemas resilientes y fiables.
La participación significa que Canonical ya no es simplemente un usuario corporativo del lenguaje.
También está contribuyendo económicamente a la sostenibilidad, gobernanza e infraestructura del ecosistema.
La cadena de suministro de Rust también preocupa a Canonical
Adoptar Rust no elimina todos los problemas relacionados con seguridad.
Una aplicación moderna puede incorporar decenas o cientos de dependencias procedentes de:
crates.ioCanonical ha señalado específicamente su interés por mejorar la seguridad de este ecosistema.
Entre sus preocupaciones aparecen:
- Seguridad del registro crates.io.
- Dependencias desconocidas.
- Reducción del número de paquetes necesarios.
- Criptografía.
- Entornos regulados.
La seguridad de memoria resuelve solamente una parte de la ecuación.
Menos dependencias también puede significar menos superficie de riesgo
Imagine una aplicación que necesita:
función principal
|
+-- crate A
| |
| +-- crate C
|
+-- crate B
|
+-- crate D
+-- crate E
|
+-- crate F
Una dependencia pequeña puede acabar introduciendo indirectamente muchos proyectos adicionales.
Cada uno representa:
- Código adicional.
- Mantenimiento adicional.
- Actualizaciones adicionales.
- Posibles vulnerabilidades adicionales.
Canonical quiere mejorar también ese aspecto antes de considerar Rust una plataforma de primera clase para infraestructura crítica.
Ubuntu 27.04 será otro paso, no el destino final
Ubuntu 27.04 será una versión intermedia, no LTS.
Eso resulta importante porque Canonical utiliza estos ciclos para introducir cambios importantes y obtener experiencia antes de consolidarlos posteriormente.
El patrón se parece a:
Versión intermedia
|
v
introducir tecnología
|
v
usuarios prueban
|
v
resolver incompatibilidades
|
v
siguiente LTS
El gran horizonte estratégico es Ubuntu 28.04 LTS.
Ubuntu 26.10 ya está preparando el camino hacia 28.04 LTS
Canonical explica que las versiones intermedias le permiten realizar cambios profundos antes de una versión con soporte prolongado.
Ubuntu 26.10 está introduciendo o ampliando tecnologías como:
- Coreutils completamente en Rust.
- ntpd-rs para pruebas.
- GRUB con menor superficie de ataque.
- OpenSSL 4.0.
- dbus-broker.
- Mejoras de cifrado basado en TPM.
- Más seguridad de memoria.
Ubuntu 27.04 será el siguiente laboratorio de esta evolución.
¿Desaparecerá chrony inmediatamente?
No debería interpretarse el plan de esa manera.
Canonical está trabajando explícitamente en una ruta de migración para quienes ya utilizan configuraciones complejas de chrony.
Especialmente en servidores empresariales pueden existir configuraciones con:
- Múltiples fuentes horarias.
- NTS.
- Servidores internos.
- GPS.
- Redes aisladas.
- Políticas específicas.
Convertir ntpd-rs en predeterminado no significa que todas esas configuraciones puedan transformarse automáticamente desde el primer día.
Canonical necesita demostrar que ntpd-rs puede competir con chrony
La hoja de ruta incluye benchmarks específicos.
Se evaluarán aspectos como:
- Consumo de memoria durante periodos prolongados.
- Uso de CPU.
- Precisión de sincronización.
- Comportamiento como servidor.
- Estabilidad.
Este punto resulta importante porque la seguridad no debería obtenerse a costa de degradar significativamente una función básica del sistema.
¿Cómo comprobar qué servicio de tiempo utiliza Ubuntu?
En un servidor actual podemos comenzar con:
timedatectlTambién puede comprobarse chrony mediante:
systemctl status chronyy consultar su seguimiento:
chronyc trackingEn versiones que tengan ntpd-rs disponible puede comprobarse primero el paquete:
apt policy ntpd-rsEn equipos de producción no conviene sustituir el servicio temporal simplemente por experimentar sin revisar previamente la documentación correspondiente a la versión utilizada.
Los administradores deberían comenzar a revisar sus configuraciones NTP
Aunque Ubuntu 27.04 todavía está en desarrollo, quienes administran grandes flotas pueden utilizar este periodo para identificar:
- Servidores con configuraciones personalizadas de chrony.
- Servidores NTP internos.
- Uso de NTS.
- Integraciones GPS.
- Dependencias con PTP.
- Reglas AppArmor asociadas.
Eso permitirá determinar posteriormente qué equipos pueden migrar directamente y cuáles necesitan pruebas específicas.
Las empresas no deberían ignorar la sincronización temporal
En infraestructura pequeña es frecuente encontrar:
servidor 1 -> hora correcta servidor 2 -> 3 minutos adelantado servidor 3 -> 7 minutos atrasado
Mientras las aplicaciones continúan funcionando, el problema puede pasar inadvertido.
Pero durante un incidente aparecen preguntas como:
¿qué evento ocurrió primero?
¿cuándo se inició realmente la sesión?
¿el certificado era válido en ese instante?
¿por qué Kerberos rechazó la autenticación?
Una infraestructura profesional debería disponer de una arquitectura temporal definida.
Rust puede cambiar progresivamente el aspecto interno de Ubuntu
Para el usuario de escritorio, muchas de estas modificaciones serán prácticamente invisibles.
El usuario continuará escribiendo:
sudo apt updatey utilizando comandos como:
cp
mv
rmsin preocuparse de qué lenguaje implementa internamente cada herramienta.
Pero debajo del sistema operativo puede producirse una transformación considerable.
Ubuntu histórico C / C++ predominante en utilidades base Ubuntu en transición C / C++ + Rust | +-- sudo-rs +-- coreutils +-- ntpd-rs
No estamos ante una guerra entre C y Rust
Conviene evitar una interpretación simplista.
Canonical no está afirmando que C deba desaparecer de Ubuntu.
El kernel Linux continúa compuesto mayoritariamente por C.
Muchísimos proyectos fundamentales seguirán utilizándolo durante años.
La estrategia consiste en identificar componentes donde una implementación madura escrita en un lenguaje con seguridad de memoria pueda aportar beneficios suficientes para justificar la transición.
Compatibilidad antes que ideología
El propio enfoque de Canonical demuestra que no está sustituyendo componentes simplemente porque exista una versión Rust.
Los proyectos necesitan alcanzar determinados niveles de:
- Compatibilidad.
- Rendimiento.
- Estabilidad.
- Mantenimiento.
- Confinamiento.
- Soporte empresarial.
Solo entonces se convierten en candidatos reales para ser predeterminados.
El cambio puede beneficiar también a otras distribuciones
Los proyectos financiados por Canonical son open source.
Eso significa que mejoras realizadas para Ubuntu pueden terminar siendo aprovechadas por:
- Debian.
- Fedora.
- Arch Linux.
- openSUSE.
- Distribuciones empresariales.
- Proyectos embebidos.
La inversión de Canonical en ntpd-rs no produce únicamente una herramienta para Ubuntu.
Contribuye a una alternativa disponible para todo el ecosistema Linux.
Ubuntu tampoco está solo en la adopción de Rust
Rust está apareciendo cada vez más en componentes de infraestructura.
El propio kernel Linux admite desarrollo de determinados controladores en Rust.
También existen proyectos que están reconstruyendo herramientas históricas utilizando este lenguaje.
Entre ellos:
- sudo-rs.
- uutils.
- ntpd-rs.
- zlib-rs.
- Rustls.
- Sequoia PGP.
La tendencia trasciende claramente a Canonical.
¿Por qué este cambio importa para Linux empresarial?
Las vulnerabilidades de memoria han sido históricamente responsables de una gran cantidad de incidentes.
Un servidor empresarial expone continuamente componentes a:
red archivos usuarios APIs protocolos datos externos
Si determinadas capas críticas pueden reducir categorías completas de errores sin perder compatibilidad, existe un argumento fuerte para evaluar la transición.
Eso explica que Canonical no esté tratando Rust únicamente como una tecnología para desarrolladores.
Lo está convirtiendo en parte de su estrategia de seguridad del sistema operativo.
Qué cambia de Ubuntu 26.04 a Ubuntu 27.04
| Versión | Avance relacionado con Rust |
|---|---|
| Ubuntu 26.04 LTS | sudo-rs y uutils coreutils entran en la base predeterminada |
| Ubuntu 26.10 | Coreutils completa la transición; ntpd-rs llega para pruebas |
| Ubuntu 27.04 | Objetivo: ntpd-rs como sistema de sincronización predeterminado |
| Ubuntu 28.04 LTS | Destino de consolidación de los cambios probados en ciclos intermedios |
¿Ubuntu será algún día un sistema escrito principalmente en Rust?
No existe actualmente un plan público de Canonical para reescribir Ubuntu completo en Rust.
Y probablemente sería poco realista plantearlo de esa forma.
Ubuntu es una distribución compuesta por decenas de miles de paquetes desarrollados por miles de proyectos diferentes.
Lo que sí está ocurriendo es más concreto:
Rust está ganando posiciones precisamente en algunos componentes donde los errores de memoria pueden tener mayores consecuencias.
Recomendamos
- AerynOS apuesta por uutils-coreutils y sudo-rs dentro de su sistema Linux
- Cómo instalar una versión reciente del kernel Linux en Ubuntu
- Cómo instalar diferentes formatos de paquetes en distribuciones Linux
En resumen
Canonical ha reafirmado que su objetivo es convertir ntpd-rs en el sistema de sincronización horaria predeterminado de Ubuntu 27.04.
Ubuntu 26.10 ya incorpora el paquete actualizado dentro de sus repositorios para realizar pruebas antes de la transición.
ntpd-rs está escrito en Rust y busca proporcionar funciones de NTP y NTS, mientras la integración con Statime permitirá ampliar progresivamente la solución hacia PTP y escenarios de sincronización de alta precisión.
Canonical financia directamente parte del desarrollo mediante su patrocinio Gold de Trifecta Tech Foundation y también se convirtió en miembro Gold de la Rust Foundation durante 2026.
La compañía continúa así una estrategia que ya llevó sudo-rs y uutils coreutils a la base de Ubuntu.
Rust no elimina todos los posibles fallos de seguridad, pero permite evitar importantes categorías de errores de memoria y complementa mecanismos tradicionales como AppArmor, seccomp y mínimo privilegio.
Conclusión editorial
La historia de Ubuntu y Rust empieza a dejar de ser una colección de experimentos para convertirse en una estrategia de arquitectura.
Primero llegó sudo-rs.
Después las coreutils.
Ahora Canonical prepara ntpd-rs.
Y lo especialmente significativo es que estos cambios afectan precisamente a componentes fundamentales del sistema.
Copiar archivos, eliminar archivos, elevar privilegios o sincronizar la hora son funciones aparentemente rutinarias, pero se ejecutan continuamente y pueden operar con permisos importantes.
Canonical parece haber llegado a una conclusión bastante clara: cuando existe una implementación Rust suficientemente madura, compatible y mantenible, vale la pena evaluar si puede reducir parte de la superficie de riesgo histórica de Linux.
Eso no significa que C vaya a desaparecer.
Tampoco significa que Rust convierta Ubuntu automáticamente en un sistema invulnerable.
Un error lógico continúa siendo un error lógico independientemente del lenguaje utilizado.
Pero evitar por diseño determinadas categorías de corrupción de memoria puede elevar el punto de partida de la seguridad.
Ubuntu 27.04 será especialmente interesante porque permitirá observar si esta estrategia puede aplicarse también a un servicio de red de larga duración y utilizado en servidores, escritorios, cloud y dispositivos.
Y el desafío no será simplemente conseguir que ntpd-rs funcione.
Deberá demostrar que puede sustituir a soluciones maduras como chrony manteniendo precisión, rendimiento, configurabilidad y compatibilidad empresarial.
Si Canonical consigue hacerlo, el cambio tendrá una lectura que irá mucho más allá del reloj de Ubuntu.
Significará que Rust ha pasado definitivamente de ser una tecnología prometedora dentro de Ubuntu a convertirse en uno de los pilares con los que Canonical pretende construir partes sensibles de su Linux durante los próximos años.
Fuentes: Canonical — What's new in security for Ubuntu 26.10, Canonical — Gold Sponsor of Trifecta Tech Foundation, Canonical — Rust Foundation Gold Member y documentación de Ubuntu sobre ntpd-rs.
