Un bug de fecha en coreutils basado en Rust interrumpe las actualizaciones automáticas en Ubuntu 25.10

• En Ubuntu 25.10, un bug en el comando date de coreutils (uutils) escrito en Rust provocó que la función de actualizaciones automáticas no funcionara en algunos sistemas
• El bug fue detectado en la versión 0.2.2-0ubuntu2 o anteriores del paquete rust-coreutils y fue corregido en la versión 0.2.2-0ubuntu2.1 o posteriores
• El problema afectó a implementaciones en la nube, imágenes de contenedor y entornos de instalación de escritorio y servidor, pero no afectó las actualizaciones manuales mediante el comando apt
• En esta versión, Ubuntu está probando la transición a utilidades basadas en Rust (uutils, sudo-rs) como parte de una evaluación para una posible adopción en la próxima versión de soporte a largo plazo (LTS)
• Este incidente muestra la necesidad de validar la estabilidad durante la transición a Rust y ofrece implicaciones importantes para las futuras estrategias de seguridad y mantenimiento de las distribuciones

---

Resumen de la falla en las actualizaciones automáticas de Ubuntu 25.10

• El proyecto Ubuntu anunció oficialmente que, debido a un bug en el comando date de uutils basado en Rust, algunos sistemas no podían comprobar actualizaciones automáticamente
  • Entre los sistemas afectados estaban entornos de despliegue en la nube, imágenes de contenedor y las instalaciones de Ubuntu Desktop y Server
  • Al fallar la comprobación automática de actualizaciones, existía el riesgo de retrasos en parches de seguridad y actualizaciones de software
• El equipo de seguridad de Ubuntu publicó instrucciones de remediación en su aviso
  • Los usuarios deben actualizar el paquete rust-coreutils a la versión 0.2.2-0ubuntu2.1 o posterior para resolver el problema
  • El bug solo afecta el proceso de actualización automática, y no impacta al comando apt ni a otras herramientas de actualización manual

Causa del bug y alcance del impacto

• Se analizó que la causa del problema fue que el comando date de coreutils reescrito en Rust (uutils) provocaba errores durante el manejo de la hora del sistema
  • Como resultado, el programador de actualizaciones automáticas no podía calcular correctamente la fecha, y la rutina de comprobación de actualizaciones se detenía
• El alcance del impacto abarca todas las formas de distribución de Ubuntu 25.10, con posible afectación operativa especialmente en entornos de servidores automatizados e instancias en la nube
• A partir de este problema, Ubuntu reconoció la necesidad de reforzar los procedimientos de validación de estabilidad para utilidades del sistema basadas en Rust

Transición a utilidades basadas en Rust (proyecto “Oxidize”)

• En la versión 25.10, Ubuntu impulsa el proyecto “oxidize”, un experimento para reemplazar las coreutils tradicionales basadas en C por uutils basado en Rust
  • Al mismo tiempo, también introdujo la versión en Rust del comando sudo (sudo-rs) con el objetivo de mejorar la seguridad y la seguridad de memoria
• Este proyecto es una fase de prueba para evaluar si será posible incluir utilidades basadas en Rust en la versión LTS prevista para abril de 2026
• LWN ya había cubierto este proyecto en marzo de 2025 y analizó el impacto que la adopción de Rust podría tener en la estabilidad estructural de las distribuciones Linux

Versión corregida e instrucciones de respuesta

• Según el aviso de seguridad de Ubuntu, rust-coreutils 0.2.2-0ubuntu2 o versiones anteriores contienen el problema
  • El bug se corrige al actualizar a la versión 0.2.2-0ubuntu2.1 o posterior
• Los usuarios pueden realizar una actualización manual del paquete con el comando apt update && apt upgrade
  • Hasta que se restaure la función de actualización automática, se recomienda realizar revisiones manuales periódicas

Implicaciones y perspectivas a futuro

• Este incidente se considera un ejemplo de inestabilidad inicial en el proceso de transición a Rust
  • Sugiere que la adopción de Rust para mejorar la seguridad de memoria y la seguridad general debe ir acompañada de una validación de estabilidad funcional
• El experimento de Ubuntu podría acelerar la tendencia de adopción de Rust en las distribuciones Linux en general
• Si las utilidades basadas en Rust se integran de forma estable en una futura versión LTS, se espera una mejora en la seguridad del sistema y en la eficiencia del mantenimiento

[GN⁺]

Comentarios de Hacker News

• Me parece bien que detecten problemas temprano de esta manera
  Mientras lo arreglen antes de la versión LTS, no hay problema

  • Como usuario común de Ubuntu, no estoy tan seguro de que esto esté bien
    Si ves el gráfico de compatibilidad de pruebas de uutils/coreutils, todavía no está completo
    En particular, date solo pasa 2 pruebas, omite 3 y falla en 3
    En ese estado, no me parece que se pueda considerar listo para producción
  • Cuando operas varios sistemas, hay componentes en los que confías tanto que ni siquiera sospechas de ellos cuando algo falla
    Un bug así puede ser menor para un usuario individual, pero en entornos grandes es crítico
    Hoy me pasé todo el día depurando hasta descubrir que el sistema estaba enviando datos a un lugar explícitamente prohibido
    Al final, todo el sistema se detuvo, y cuando se rompe una herramienta de la que dependías, administrarlo se vuelve realmente difícil
    Si esto hubiera sido en un lenguaje que no fuera Rust, los desarrolladores habrían recibido una cantidad brutal de críticas
  • Si una utilidad esencial se reemplaza por una versión reescrita sin una razón clara, y esa versión es tan inestable que una distribución estable ni siquiera puede actualizarse bien, no se puede decir que esté bien
  • Eso de “así es como se encuentran los problemas” suena como una respuesta al estilo Microsoft /s

• Me pregunto si el coreutils existente tenía problemas tan graves como para necesitar mejoras

  • Probablemente haya sido por temas de licencia. Ya había esa especulación en este comentario
  • Desde la perspectiva de un mantenedor de OpenBSD, dicen que para evaluar si cierto lenguaje sirve como lenguaje de sistema, es indispensable implementar coreutils en ese lenguaje
    Texto relacionado: lista de correo de OpenBSD
  • También podría ser por problemas de seguridad como CVE-2015-4042
  • Parece que el problema era que no estaba escrito en Rust. Pero entonces me pregunto por qué el borrow checker no detectó el bug de date
  • Si quieres entender el contexto, puedes consultar el texto oficial de Ubuntu: Carefully but purposefully oxidising Ubuntu

• Quiero encontrar el enlace al parche en uutils

  • Está explicado en el artículo de LWN
    El bug central es que no estaba implementado el soporte para date -r <file>, pero Ubuntu integró esa versión de todos modos
    El comando ignoraba en silencio la opción -r y no hacía nada
    Issues relacionados: #8621, PR #8630
  • El reporte de bug de Ubuntu está aquí
  • Creo que la raíz del problema es la mera existencia del proyecto de reescritura en Rust
  • Lástima que falte una explicación más clara del problema real
    El último commit (enlace) era una corrección para que el parseo de date coincidiera con GNU, pero por otros comentarios parece que quizá esa no era la causa

• El comentario principal me dio risa: decía que el nombre de la próxima versión de Ubuntu será Grateful Guinea-Pig

• Si ves el changelog de Ubuntu, el bug está relacionado con date -r
  Según el changelog, el reporte de bug, el issue y el PR,
  date -r debería mostrar la hora de modificación del archivo, pero la versión en Rust simplemente lo ignoraba
  Que falte un comportamiento básico así es decepcionante para un proyecto que se presenta como un “reemplazo seguro”

  • Si esa versión pasó la prueba oficial de coreutils, entonces quizá eso signifique que el test suite está incompleto
  • ¡Pero al menos no hubo buffer overflow!

• Aviso de seguridad de Ubuntu: parece un caso típico

• Ubuntu 25.10 me pareció tan malo que era inutilizable. Es la primera vez que digo eso de una versión no LTS

  • Me gustaría saber si puedes explicar con más detalle qué fue lo tan grave

• Estoy de acuerdo con la idea de que “reescribir en Rust utilidades en C probadas durante décadas puede ser bueno a largo plazo, pero los problemas de corto plazo eran predecibles”
  Pero me pregunto qué tan largo es exactamente ese “largo plazo”
  En una charla de FOSDEM, un desarrollador de uutils afirmó que el rendimiento era mejor usando benchmarks incorrectos, cuando en realidad se debía a la falta de soporte de locale, y eso también fue un problema
  Enlaces relacionados: charla de FOSDEM, hilo 1, hilo 2

  • Pero estas herramientas esenciales también son al final el resultado de múltiples reescrituras a lo largo del tiempo. No hace falta verlo de forma tan extrema
  • También hay un artículo de Phoronix que dice que, después de agregar el manejo de locale, el rendimiento mejoró
  • A veces pienso que, en lugar de una reescritura así, el mismo esfuerzo podría haberse usado para construir un sistema de verificación formal, y eso quizá habría sido mejor para la seguridad
  • A veces los proyectos open source se usan como una forma de construir reputación personal
    Reescribir utilidades esenciales da una gran ventaja para el portafolio

• Tengo curiosidad por el estado del arte en guided state-space exploration y fuzzing
  Si ya existe una implementación previa, parecería posible que un fuzzer compare el comportamiento de ambas versiones para hacer una verificación de caja blanca

  • En casos así, creo que el property testing encaja muy bien
    Escribir proptests para todo el espacio de entrada requiere mucho trabajo, pero si los argumentos del CLI son estables, parece totalmente viable
    Incluso se podría generar automáticamente a partir de materiales como páginas man
    En Rust, usaría el crate proptest, y para verificar diferencias en el CLI, probablemente Hypothesis de Python mediante llamadas externas