Canonical ne réécrit pas entièrement Ubuntu en Rust, mais a commencé à remplacer certains composants essentiels du système là où elle estime que les gains en matière de sécurité de la mémoire et de maintenance justifient le coût de la transition. Selon ce qu’a présenté Jon Seager, vice-président de l’ingénierie chez Canonical, lors d’une émission organisée par JetBrains, cette décision s’inscrit dans une vision à long terme pour une plateforme qui fait fonctionner environ 15 millions de déploiements sur des serveurs, des ordinateurs de bureau, des appareils périphériques et dans des voitures.
Cette orientation part d’une question portant sur les besoins d’Ubuntu au cours des deux prochaines décennies, et non d’une campagne visant à réimplémenter chaque outil existant. Canonical estime que Rust offre un ensemble d’outils convaincant pour le développement système, en particulier lorsque la résistance aux erreurs de mémoire et la fiabilité sont des facteurs déterminants pour des logiciels fonctionnant dans des systèmes industriels, des voitures ou des infrastructures sensibles.
Des remplacements sélectifs plutôt qu’une réécriture globale
Les premiers de ces composants sont arrivés dans Ubuntu 26.04 LTS. uutils coreutils, une réimplémentation en Rust des outils GNU coreutils, est devenu le choix par défaut, avec pour objectif déclaré d’assurer une compatibilité totale avec le comportement des outils GNU. Cela signifie qu’une légère différence de comportement n’est pas nécessairement considérée comme une amélioration, mais peut être considérée comme un bogue si elle casse un script ou un outil dépendant de l’ancien comportement.
sudo-rs suit une voie différente. Plutôt que de chercher à reproduire parfaitement sudo, le projet repense la forme d’un outil d’octroi de privilèges s’il était conçu aujourd’hui, après des décennies d’expérience en matière de sécurité. Parmi les changements ayant suscité de fortes réactions figure l’affichage par défaut d’astérisques lors de la saisie du mot de passe dans le terminal. Canonical affirme accepter ces changements intentionnels même lorsqu’ils provoquent une friction à court terme, car elle les considère comme faisant partie d’une nouvelle conception et non comme une simple copie de remplacement.
Le temps et les certificats dans le périmètre du changement
Le projet suivant est ntpd-rs, dont Canonical a annoncé en juin 2026 le financement par l’intermédiaire de Trifecta Tech Foundation, avec pour objectif d’en faire l’outil de synchronisation temporelle par défaut dans Ubuntu. Le plan consiste à l’archiver dans Ubuntu 26.10, puis à en faire complètement l’option par défaut dans Ubuntu 28.04, afin de remplacer progressivement chrony et linuxptp au moyen d’un outil unique prenant en charge NTP, NTS et PTP.
L’importance de ce changement tient au fait que la synchronisation précise du temps ne concerne pas uniquement les serveurs réseau. Elle influence les microcontrôleurs présents dans les avions, les voitures et les robots, ainsi que les systèmes cryptographiques qui renouvellent périodiquement leurs clés et les systèmes dépendant de la localisation. L’article explique que l’utilisation conjointe de chrony et de linuxptp peut nécessiter la configuration de plusieurs outils et sources temporelles, tandis que ntpd-rs vise à regrouper ces fonctions dans un outil et un fichier de configuration uniques, tout en bénéficiant de la sécurité de la mémoire.
Le projet UPKI diffère de ces remplacements, car il s’agit d’un nouveau projet développé depuis zéro en collaboration avec le projet Rustls, visant à ajouter la vérification de la révocation des certificats aux outils système sous Linux. Canonical prévoit sa première arrivée dans Ubuntu 26.10. L’idée concerne des outils tels que curl, wget et OpenSSL, dans lesquels, selon l’article, ce type de gestion de la révocation des certificats n’est pas intégré de la même manière que dans les navigateurs.
Qu’est-ce qui change concrètement pour les utilisateurs ?
Canonical a choisi les limites des versions LTS pour introduire ces changements, car les organisations mettent généralement à jour leurs systèmes à ces moments-là et parce qu’une voie de retour en arrière est importante lors de la modification d’outils de bas niveau. L’article indique que les versions précédentes bénéficieront d’un support géré pendant 15 ans et que les anciens outils resteront dans les archives, de sorte que le nouveau comportement ne soit pas imposé à un système de production existant sans possibilité de revenir en arrière.
La compatibilité n’est toutefois pas uniforme entre les projets. uutils coreutils a rencontré un exemple concret lorsque l’outil head a renvoyé une erreur en cas de demande de lecture d’un certain nombre d’octets depuis un fichier vide, alors que GNU coreutils renvoyait zéro. Cette différence a cassé un script dissimulé dans le paquet snap d’Obsidian, et le comportement a été modifié pour correspondre à celui de GNU. Cet exemple montre que la sécurité de la mémoire n’élimine pas l’importance de la compatibilité avec des hypothèses accumulées autour des anciens outils pendant 30 ans.
Le défi ne s’arrête pas à l’écriture du code
L’introduction de Rust dans une grande distribution nécessite également de traiter la chaîne des dépendances, de la compilation et de la distribution. Canonical utilise une méthode consistant à regrouper les crates propres à chaque paquet dans une seule archive plutôt qu’à empaqueter chaque crate sous la forme d’un paquet deb distinct. Selon l’article, cela contribue à maintenir une surface de dépendances gérable et à rendre les processus de compilation déterministes, sans toutefois être reproductibles au sens officiel.
Plus tôt en 2026, cargo auditable a été généralisé à tous les paquets Rust de l’archive Ubuntu. Chaque binaire Rust contient une SBOM intégrée qui enregistre les noms et les versions des crates utilisées lors de la compilation, et qui est automatiquement mise à jour lors de la recompilation du paquet. Ces données n’empêchent pas les vulnérabilités, mais elles rendent plus directe l’identification des versions affectées lorsqu’un problème est découvert dans l’une des dépendances.
Analyse de certi.news : le véritable changement ne consiste pas seulement à remplacer des outils écrits en C par d’autres écrits en Rust, mais à introduire une couche de sécurité, de maintenance et de traçabilité des dépendances dans des composants difficiles à modifier une fois qu’ils sont largement déployés. En revanche, les exemples de compatibilité et le comportement de sudo-rs montrent que la transition peut imposer des choix de conception perceptibles par les utilisateurs, et que sa réussite dépendra autant de la gestion de ces différences que du langage d’implémentation. Les échéances annoncées pour ntpd-rs et UPKI restent des objectifs futurs, tandis que la source confirme que le périmètre du changement est sélectif et que les anciens outils ainsi que les options de retour en arrière demeurent partie intégrante de la stratégie de Canonical.