Un bug de date dans les coreutils basés sur Rust interrompt les mises à jour automatiques d’Ubuntu 25.10

• Sur Ubuntu 25.10, un bug de la commande date dans coreutils (uutils) écrit en Rust provoque un dysfonctionnement des mises à jour automatiques sur certains systèmes
• Ce bug a été identifié dans le paquet rust-coreutils version 0.2.2-0ubuntu2 et antérieures, et corrigé dans la version 0.2.2-0ubuntu2.1 et suivantes
• Le problème a touché les déploiements cloud, les images de conteneurs, ainsi que les installations desktop et serveur, mais n’affecte pas les mises à jour manuelles via la commande apt
• Avec cette version, Ubuntu teste la transition vers des utilitaires basés sur Rust (uutils, sudo-rs) afin d’évaluer une éventuelle adoption dans la version à support à long terme (LTS) de l’an prochain
• Cet incident montre la nécessité de valider la stabilité pendant la transition vers Rust et apporte des enseignements importants pour les futures stratégies de sécurité et de maintenance des distributions

---

Aperçu de la panne des mises à jour automatiques dans Ubuntu 25.10

• Le projet Ubuntu a annoncé officiellement qu’un bug de la commande date dans uutils basé sur Rust empêchait certains systèmes de vérifier automatiquement la disponibilité de mises à jour
  • Parmi les systèmes touchés figurent les environnements de déploiement cloud, les images de conteneurs, ainsi que les installations Ubuntu Desktop et Server
  • L’échec de la vérification automatique des mises à jour crée un risque de retard dans l’application des correctifs de sécurité et des mises à jour logicielles
• L’équipe sécurité d’Ubuntu a fourni des instructions de remédiation dans son annonce
  • Les utilisateurs peuvent résoudre le problème en mettant à jour le paquet rust-coreutils vers la version 0.2.2-0ubuntu2.1 ou ultérieure
  • Le bug n’affecte que le processus de mise à jour automatique et n’a aucun impact sur la commande apt ni sur les autres outils de mise à jour manuelle

Cause du bug et étendue de l’impact

• La cause du problème a été attribuée à une erreur dans le traitement de l’heure système par la commande date de coreutils (uutils) réécrit en Rust
  • En conséquence, l’ordonnanceur des mises à jour automatiques échoue à calculer correctement la date, ce qui interrompt la routine de vérification des mises à jour
• L’impact concerne toutes les formes de distribution d’Ubuntu 25.10, avec un risque particulier de perturbation dans les environnements serveur automatisés et les instances cloud
• Ubuntu a reconnu, à travers cet incident, la nécessité de renforcer les procédures de validation de la stabilité des utilitaires système basés sur Rust

Transition vers des utilitaires basés sur Rust (projet « Oxidize »)

• Dans la version 25.10, Ubuntu mène le projet « oxidize », une expérimentation visant à remplacer les coreutils historiques en C par uutils basé sur Rust
  • En parallèle, Ubuntu introduit également la version Rust de la commande sudo (sudo-rs) afin d’améliorer la sécurité et la sûreté mémoire
• Ce projet constitue une phase d’évaluation pour déterminer s’il sera possible d’inclure des utilitaires basés sur Rust dans la version LTS prévue pour avril 2026
• LWN avait déjà traité ce projet en mars 2025, en analysant l’impact potentiel de l’adoption de Rust sur la stabilité structurelle des distributions Linux

Version corrigée et consignes de réponse

• Selon l’avis de sécurité d’Ubuntu, rust-coreutils 0.2.2-0ubuntu2 et les versions antérieures contiennent le problème
  • Une mise à jour vers la version 0.2.2-0ubuntu2.1 ou ultérieure corrige le bug
• Les utilisateurs peuvent effectuer une mise à jour manuelle des paquets via la commande apt update && apt upgrade
  • Tant que la fonction de mise à jour automatique n’est pas rétablie, des vérifications manuelles régulières sont recommandées

Enseignements et perspectives

• Cet incident est considéré comme un exemple de l’instabilité initiale possible lors de la transition vers Rust
  • Il montre que l’adoption de Rust pour améliorer la sûreté mémoire et la sécurité doit s’accompagner d’une validation rigoureuse de la stabilité fonctionnelle
• L’expérimentation d’Ubuntu pourrait accélérer l’adoption de Rust dans l’ensemble de l’écosystème des distributions Linux
• Si les utilitaires basés sur Rust sont intégrés de manière stable dans une future version LTS, on peut s’attendre à des gains en sécurité système et en efficacité de maintenance

[GN⁺]

Commentaires Hacker News

• Je trouve acceptable de détecter les problèmes tôt de cette façon
  Tant que tout est réglé avant la version LTS, ça me va

  • En tant qu’utilisateur Ubuntu ordinaire, je ne sais pas vraiment si c’est acceptable
    Quand on regarde le graphique de compatibilité des tests de uutils/coreutils, ce n’est pas encore abouti
    En particulier, date ne passe que 2 tests, en ignore 3 et échoue sur 3
    Dans cet état, ça ne me semble pas prêt pour la production
  • Quand on administre plusieurs systèmes, on finit par faire tellement confiance à certains composants qu’on ne pense même plus à les soupçonner en cas de problème
    Ce genre de bug peut sembler mineur pour un utilisateur isolé, mais il est critique à grande échelle
    J’ai passé toute la journée à déboguer avant de découvrir que le système envoyait des données vers un endroit explicitement interdit
    Au final, tout le système s’est arrêté, et quand l’outil dont on dépend casse, c’est vraiment difficile à gérer
    Si ce n’était pas Rust mais un autre langage, les développeurs se feraient démolir
  • Si des utilitaires essentiels sont remplacés par des versions réécrites sans raison claire, et qu’elles sont tellement instables qu’une distribution stable n’arrive même plus à se mettre à jour correctement, on ne peut pas dire que ce soit acceptable
  • Dire « c’est comme ça qu’on trouve les bugs » ressemble à une réponse à la Microsoft /s

• Je me demande si les coreutils existants avaient vraiment des problèmes au point de nécessiter des améliorations

  • C’est peut-être lié à des questions de licence. Il y avait déjà cette hypothèse dans ce commentaire
  • Du point de vue d’un mainteneur OpenBSD, implémenter les coreutils dans un langage donné est indispensable pour juger si ce langage convient comme langage système
    Article lié : liste de diffusion OpenBSD
  • Cela peut aussi venir de problèmes de sécurité comme CVE-2015-4042
  • On dirait que le problème était surtout que ce n’était pas écrit en Rust. Mais alors, on peut se demander pourquoi le borrow checker n’a pas détecté le bug de date
  • Pour le contexte, on peut lire le billet officiel d’Ubuntu : Carefully but purposefully oxidising Ubuntu

• J’aimerais trouver le lien vers le correctif dans uutils

  • C’est expliqué dans l’article de LWN
    Le bug principal est que la prise en charge de date -r <file> n’était pas implémentée, et Ubuntu a intégré cette version quand même
    La commande ignorait silencieusement l’option -r et ne faisait rien
    Tickets liés : #8621, PR #8630
  • Le rapport de bug Ubuntu est ici
  • Je pense que le vrai problème, c’est l’existence même du projet de réécriture en Rust
  • C’est dommage que la description concrète du problème manque de précision
    Le dernier commit (lien) corrigeait l’analyse de date pour l’aligner sur GNU, mais à en croire d’autres commentaires, ce n’était peut-être pas la cause

• Le commentaire du dessus m’a fait rire — « la prochaine version d’Ubuntu s’appellera Grateful Guinea-Pig »

• En regardant le changelog d’Ubuntu, le bug concerne date -r
  En consultant le changelog, le rapport de bug, l’issue et la PR,
  date -r est censé afficher l’heure de modification d’un fichier, mais la version Rust l’ignorait purement et simplement
  Une absence d’un comportement aussi basique est décevante pour un projet qui se présente comme un « remplacement sûr »

  • Si cette version passait les tests officiels de coreutils, cela pourrait plutôt vouloir dire que la suite de tests est incomplète
  • Au moins, il n’y avait pas de buffer overflow !

• Annonce de sécurité Ubuntu — ça ressemble à un cas assez classique

• Ubuntu 25.10 m’a semblé inutilisable. C’est la première fois que je dis ça d’une version non LTS

  • J’aimerais savoir plus précisément ce qui était si grave

• Je suis d’accord avec l’idée que « réécrire en Rust des utilitaires C éprouvés depuis des décennies peut être bénéfique à long terme, mais les problèmes à court terme étaient prévisibles »
  Mais je me demande ce que signifie exactement « long terme »
  Lors d’une conférence à FOSDEM, un développeur de uutils a affirmé que les performances étaient meilleures avec des benchmarks erronés, alors qu’en réalité cela venait de l’absence de prise en charge des locales
  Liens liés : conférence FOSDEM, fil 1, fil 2

  • Cela dit, même ces outils essentiels sont le résultat de plusieurs réécritures au fil du temps. Pas besoin de voir les choses de manière trop extrême
  • Après l’ajout de la gestion des locales, il y a même eu une amélioration des performances, comme l’indique un article de Phoronix
  • Au lieu de ce type de réécriture, le même effort aurait peut-être été mieux investi dans la mise en place d’un système de vérification formelle du point de vue de la sécurité
  • Il arrive aussi que des projets open source servent à se construire une réputation
    Réécrire des utilitaires fondamentaux, c’est très valorisant dans un portfolio

• Je suis curieux des techniques récentes de guided state-space exploration ou de fuzzing
  S’il existe déjà une implémentation de référence, un fuzzer pourrait comparer le comportement des deux versions pour faire une vérification en boîte blanche

  • La property testing semble bien adaptée dans ce cas
    Écrire des proptests couvrant l’ensemble de l’espace d’entrée demande beaucoup d’efforts, mais si les arguments CLI sont stables, c’est tout à fait faisable
    On pourrait même en générer automatiquement à partir de ressources comme les pages de man
    En Rust, le crate proptest semble indiqué, et pour vérifier les écarts entre CLI, utiliser Hypothesis en Python via des appels externes paraît une bonne approche