The Slow Failure of Ubuntu's Rust Dream

SYNTHÈSE STRUCTURÉE

L’échec retentissant de cp en Rust

En juillet 2026, Canonical a réintroduit la commande cp écrite en Rust dans le paquet coreutils. Résultat immédiat : les builds des images live d’Ubuntu ont cessé de fonctionner. La cause ? Une commande simple utilisée par l’outil livecd-rootfs : cp -afl. Le drapeau -a (archive) est un raccourci qui inclut -r (récursif). Mais la version Rust a mal interprété la combinaison des flags, perdant la récursivité implicite. Le message d’erreur historique est apparu : -r not specified, omitting directory. L’intervenant souligne : « The most famous recursive copy in the Unix world refusing to be recursive. » Canonical a dû revenir en arrière et restaurer le binaire GNU.

Un bug silencieux dans date qui a aveuglé les mises à jour de sécurité

En novembre 2025, Ubuntu 25.10 a adopté Rust coreutils par défaut. Pendant des semaines, le mécanisme unattended-upgrades (mises à jour automatiques) a été incapable de vérifier les mises à jour. La commande date -r (qui lit la date de modification d’un fichier) était reconnue syntaxiquement, mais son implémentation était vide : elle retournait toujours la date courante. Aucune erreur, aucun avertissement. L’intervenant qualifie cela d’« ironie » : « The security update system of a distribution used by millions of people blind because of an argument that was declared and never implemented. »

L’audit de sécurité : 113 vulnérabilités, dont des CVE critiques

Canonical a commandé un audit indépendant à ZELIC. Résultat : 113 problèmes identifiés, dont plusieurs CVE. Parmi les plus graves :

• Une vulnérabilité critique dans cp permettant une injection de code via la résolution de noms avant que les privilèges administrateur ne soient abandonnés.
• Des failles logiques dans rm et chmod permettant de contourner la protection du répertoire racine via des liens symboliques.
• Des races conditions (TOCTOU) où le fichier vérifié et le fichier modifié peuvent ne plus être le même.
• Un bug dans cp qui créait des fichiers de destination avec des permissions trop larges, puis les restreignait après coup, laissant une fenêtre d’attaque.

Ubuntu 26.04 LTS : les trois commandes critiques exclues du rewrite

Face à l’audit, Ubuntu 26.04 LTS (avril 2026) a livré cp, mv et rm fournis par GNU coreutils. L’intervenant précise : « The three commands that touch your files directly, the three commands where a mistake cannot be undone with Control+Z, were excluded from the rewrite because the race conditions were not fixed in time. »

Le vrai problème : la théologie du « tout Rust » plutôt que l’ingénierie

L’intervenant insiste : le problème n’est pas le langage Rust en lui-même, mais la croyance que « réécrire en Rust est en soi un acte de progrès ». Il cite la loi de Hiram : « When a piece of software has enough users, every observable behavior becomes a contract, whether it is documented or not. » Les 30 ans de comportements réels de GNU coreutils constituent une spécification non écrite, incarnée dans le code C. Chaque ligne étrange, chaque condition redondante est une cicatrice d’un bug qui ne se reproduira plus. Réécrire, c’est jeter ces cicatrices.

Un changement de licence sous couvert de sécurité

L’intervenant rappelle que les nouveaux coreutils (uutils) sont sous licence MIT, alors que GNU coreutils est GPL. Il pose une question rhétorique : « When you hear that the license does not matter, that only security counts, ask yourself why security, the real kind, the kind measured by an audit, arrived after the adoption decision and not before. »

CONCEPTS CLÉS

• Hiram’s law : En génie logiciel, quand un logiciel a suffisamment d’utilisateurs, tout comportement observable devient un contrat, qu’il soit documenté ou non.
• TOCTOU (Time of Check to Time of Use) : Classe de vulnérabilités où l’état d’une ressource (fichier, permission) change entre le moment où elle est vérifiée et celui où elle est utilisée.
• Race condition : Situation où le résultat d’une opération dépend de l’ordre d’exécution non déterministe de plusieurs processus ou threads.
• CVE (Common Vulnerabilities and Exposures) : Identifiant unique pour une vulnérabilité de sécurité publique.

CONCLUSION

La leçon principale est que la fiabilité logicielle ne s’obtient pas par une réécriture, même dans un langage plus sûr. Elle s’acquiert par des décennies de tests en conditions réelles, de corrections de bugs et d’accumulation de connaissances sur les cas limites. L’intervenant conclut : « Software does not become reliable when you rewrite it. It becomes reliable when it survives, and surviving, that takes time. 30 years, for example. » Pour un administrateur système, cela signifie qu’il faut évaluer les réécritures avec un scepticisme sain, en exigeant des audits de sécurité indépendants avant l’adoption, et en conservant la possibilité de revenir aux versions éprouvées.