Dépendances Rust obligatoires : introduction prévue dans l’APT de Debian à partir de mai 2026

• Le gestionnaire de paquets APT de Debian devrait intégrer du code écrit en Rust et ses dépendances à partir de mai 2026
• Dans un premier temps, l’intégration concernera le compilateur Rust, la bibliothèque standard et l’écosystème Sequoia
• Les parseurs de fichiers .deb, .ar et .tar, ainsi que le code de vérification des signatures HTTP, constituent les principaux axes d’amélioration en matière de sûreté mémoire et de renforcement des tests unitaires
• Les ports ne disposant pas d’une toolchain Rust devront mettre en place un environnement Rust dans les 6 mois ou être abandonnés (sunset)
• Cette évolution s’inscrit dans une volonté de faire progresser l’ensemble du projet avec des outils et technologies modernes, sans rester bloqué par la compatibilité avec du matériel ancien

---

Projet d’introduction de code Rust dans APT

• Introduction prévue de code Rust et d’une dépendance forte (hard dependency) dans APT après mai 2026
  • Cette introduction n’aura pas lieu avant mai 2026
• Le périmètre initial d’intégration se limite au compilateur Rust, à la bibliothèque standard et à l’écosystème Sequoia

Objectif : améliorer la qualité et la sûreté du code

• Le code d’analyse des fichiers .deb, .ar et .tar, ainsi que le code de vérification des signatures HTTP, sont les principales cibles de l’introduction de Rust
  • Il est précisé que ces domaines devraient bénéficier de manière importante des avantages d’un langage à sûreté mémoire et d’un cadre de tests unitaires renforcé

Exigences pour les mainteneurs de ports

• Les ports sans toolchain Rust devront mettre en place un environnement Rust dans les 6 mois
  • Dans le cas contraire, ces ports pourraient être abandonnés (sunset)

Orientation du projet

• Le projet Debian souligne la nécessité d’évoluer en s’appuyant sur des outils et technologies modernes
  • Il est explicitement indiqué que cette évolution ne doit pas être retardée par des tentatives de prise en charge de matériel ancien ou d’équipements de rétro-informatique

Autres informations

• L’auteur du message est Julian Andres Klode, développeur core de Debian et Ubuntu
• Le message a été publié sur la liste de diffusion des développeurs Debian, debian-devel
• Une signature PGP (signature.asc) est jointe
• Aucune autre précision technique ni modification de calendrier n’est mentionnée

[GN⁺]

Avis Hacker News

• On dirait que le moment est enfin venu. Continuer à garder en C du code d’analyse de données non fiables devient une dette technique qui ne fait que grossir avec le temps
  Rust n’est pas tellement plus difficile à écrire que le C, et si on recréait le C aujourd’hui en tenant compte de ce qu’on sait sur la conception des langages et la sécurité du code, on obtiendrait probablement quelque chose comme Rust
  Si on peut abandonner le support de x86 32 bits pour des raisons pratiques, alors ces architectures aussi. Si on veut vraiment les maintenir, il faut développer soi-même un backend de toolchain Rust

  • À l’heure actuelle, les langages autorisés pour les applications essentielles du système de base sont surtout C, C++, Shell (bash), Perl et Python. Python a été ajouté il y a environ 20 ans, et Rust est le premier langage suffisamment proche pour remplacer le rôle du C
    Go s’en approchait un peu, mais il n’a jamais vraiment été envisagé pour un système central comme systemd. Je me demande s’il y a eu les mêmes débats quand C++, Python et Perl ont été ajoutés à l’époque
  • On dit que « les parseurs de .deb, .ar, .tar et le code de vérification des signatures HTTP bénéficieraient d’un langage memory-safe », mais je me demande quel avantage concret il y a à réécrire dans un nouveau langage des bases de code stabilisées depuis 30 ans
    Est-ce vraiment utile de jeter du code éprouvé au combat pour créer de nouveaux problèmes de compatibilité et de nouveaux bugs ?
  • Il existe une approche plus pragmatique pour résoudre les problèmes de sécurité du vieux code C : le projet Fil-C. L’idée est de transformer le C en quelque chose qui ressemble de fait à un langage managé, afin de réduire le besoin de réécriture
  • Ce n’est pas seulement un problème de sécurité mémoire. Avec le vieillissement de la communauté C, il devient difficile de trouver des personnes pour assurer la maintenance. Dans notre équipe aussi, on migre tout le code C/C++ vers d’autres langages. La plupart des développeurs C/C++ ont la quarantaine et sont peu enclins à changer de poste
  • J’ai du mal à accepter l’idée que Rust serait une réinvention moderne du C. Par exemple, le code du widget horloge du desktop COSMIC est bien plus difficile à lire qu’un code C d’une complexité comparable (GNU coreutils, etc.)

• La tendance à réécrire les systèmes cœur en Rust est forte, mais je doute que la sécurité s’améliore réellement quand on réécrit de vieux outils
  Je comprends qu’il soit difficile d’introduire de nouveaux systèmes, mais on a toujours l’impression de conserver une structure empilée sur des décisions de conception héritées de l’ère du télégraphe

  • On entend généralement deux justifications à ces réécritures.
    Premièrement, presque aucun nouveau contributeur ne veut travailler sur d’anciennes bases de code C/C++. En passant à Rust, il devient plus facile de faire venir de nouveaux développeurs
    Deuxièmement, la fiabilité se valide par l’usage, mais la sécurité ne se valide que par l’attaque. On ne peut pas considérer qu’un vieux code a forcément traversé tous les vecteurs d’attaque. Il y a donc un argument fort en faveur d’un durcissement proactif
  • uutils/coreutils est sous licence MIT, GNU coreutils sous GPL : il y a donc une différence de licence. Pour les entreprises, cela peut être un point important
  • Comme il faut bien que quelqu’un apprenne, je trouve acceptable de réécrire pour s’exercer des projets simples et faciles à tester. En revanche, savoir si le résultat doit remplacer l’original est une autre question

• D’après le fil de discussion Debian, Rust est déjà indispensable sur la plupart des architectures de publication Debian
  Le mail concerné cite seulement alpha, hppa, m68k et sh4 comme exceptions. Je me demande quel sera l’avenir de ces architectures

  • Je me demande sincèrement si quelqu’un utilise encore ces vieilles machines. La plupart reposent sur du matériel vieux de plus de 20 ans.
    Rust propose une cible Tier 3 pour m68k, mais rien pour les autres architectures. J’aimerais connaître les cas d’usage réels
  • Selon Debian Supported Architectures, ces plateformes sont dans un état non officiel.
    Il est surprenant qu’elles soient encore là alors que le x86 32 bits et MIPS ont disparu. J’ai bien une certaine nostalgie, mais je vois mal à quoi elles servent concrètement
  • Il existe déjà un port LLVM pour m68k, donc une implémentation Rust est possible. Des backends LLVM pour alpha, hppa et sh4 auraient aussi une valeur comme matériel pédagogique
    LLVM a d’ailleurs eu un backend DEC Alpha par le passé, mais cela remonte à longtemps
  • Du point de vue d’Ubuntu, ces architectures n’ont aucune valeur commerciale
  • Elles sont totalement obsolètes : autant s’arrêter à la dernière version prise en charge ou faire sa propre distribution. Ajouter le support Rust n’est pas réaliste

• J’aimerais que la communauté Rust, au lieu de s’immiscer dans des projets existants, construise directement des technologies modernes nouvelles pour faire ses preuves
  Un projet indépendant comme Redox en est un exemple, et c’est dommage de ne pas pousser davantage ce genre d’initiative

  • Ici, il s’agit d’une décision officielle de Debian d’ajouter une dépendance à Rust. Ce n’est pas quelque chose imposé de l’extérieur par des fans de Rust
    Bien sûr, il existe des partisans extrêmes du « réécrivons-le en Rust », mais ce n’est pas le sujet ici
  • ripgrep est justement un bon exemple. C’est nouveau, et les gens l’aiment réellement

• Utiliser la bibliothèque standard de Rust ne me dérange pas, mais je n’ai pas envie de tirer 500 paquets cargo pour compiler un simple parseur deb

• Il peut être raisonnable d’attendre que le port Rust-for-GCC se stabilise
  Le noyau non plus ne rendra pas Rust obligatoire tant que le support GCC ne sera pas là.
  S’il existe plusieurs implémentations, le langage paraîtra moins instable
  En revanche, si on coupe maintenant le support de certaines architectures, la procédure de retour pourrait devenir compliquée plus tard lorsqu’une toolchain Rust existera

  • En réalité, ces architectures sont déjà exclues de Debian depuis plus de 10 ans. Cette évolution n’en écarte pas de nouvelles
  • Elles n’ont aucun support officiel et ne sont maintenues que par des particuliers sur leur temps libre. Sans entreprise pour assurer la maintenance à long terme, un retour paraît difficile
  • GCCRS ne compile même pas encore libcore et en est au niveau de Rust 1.50. Il faudra probablement encore des années avant d’en faire un compilateur généraliste
    rustc_codegen_gcc a plutôt des chances d’être stabilisé avant
  • Ces ports ne sont pas intégrés aux versions officielles de Debian, ils ne sont diffusés que via le canal unstable

• Je rappelle que l’auteur du mail sur la discussion Rust de Debian est le mainteneur du paquet keepassxc
  Il existe aussi des fils de discussion plus anciens sur son ton abrupt envers les développeurs upstream et les utilisateurs

  • Moi aussi, j’ai vérifié tout de suite après avoir vu ce mail, et ça m’a fait rire de repenser à l’ancien fil
  • Franchement, sa formulation est rude, mais franche plutôt qu’insultante. Tout cela ressemble à du drame inutile
  • Le post HN lui-même n’est pas agressif, mais certains semblent le prendre de façon excessive
  • Cette culture est répandue dans le monde du logiciel libre. J’ai l’impression qu’on poursuit depuis l’époque de GNOME 3 et Mozilla une figure idéalisée de l’utilisateur plutôt que les vrais utilisateurs

• Il est intéressant d’observer l’évolution de l’opinion d’une personne. Lien vers une déclaration précédente

  • C’est bien de voir quelqu’un capable de changer d’avis avec le temps
  • L’adoption de Rust dans APT pourrait aussi être, comme pour la transition de coreutils, une décision de gestion

• Je pense que Rust n’est qu’un simple effet de mode (hype). Dans le monde de l’embarqué, le C reste roi.
  En pratique, je n’ai jamais vu autour de moi quelqu’un utiliser Rust ou même l’envisager

  • Tirer une conclusion à partir de « personne autour de moi n’en utilise » est excessif. Il existe beaucoup de développeurs embarqués qui utilisent Rust
  • Chez AWS, des services essentiels comme EC2, IAM, DynamoDB et S3 sont écrits en Rust.
    Cela permet de conserver performances et efficacité mémoire tout en accélérant le développement.
    Le seul inconvénient réel est la taille des binaires. Pour moi, l’avenir de Rust est déjà assuré
  • Rust est aussi solide dans l’embarqué, mais faute de support des fabricants, il faut encore beaucoup de travail initial spécifique au matériel
    Cela dit, l’attrait ne vient pas seulement de la sécurité mémoire, mais de la qualité globale du langage et de la toolchain
  • Avec avr-rust, esp-rs, cortex-m et d’autres, l’écosystème embarqué évolue lui aussi lentement
  • Microsoft, Google et d’autres discutent de Rust et l’emploient déjà dans de vrais produits

• Je pense qu’un environnement polyglotte ne fait qu’ajouter des problèmes.
  Il faut des toolchains et des gestionnaires de paquets différents pour Python, Node, Go, Rust, etc., ce qui complique tout
  On a supprimé les buffer overflows avec Node pour voir augmenter les attaques de la chaîne d’approvisionnement.
  Autant repartir de zéro, et si l’on veut vraiment utiliser Rust à fond, il vaut mieux contribuer à Redox OS

  • En pratique, chaque langage a ses avantages et ses inconvénients propres, et Debian, en tant qu’OS pragmatique, doit prendre en charge plusieurs langages
    Réécrire l’ensemble dans une seule langue est irréaliste, et pousser Redox n’est pas forcément plus efficace
    Rust est déjà un langage largement éprouvé, et sa valeur tient aussi au fait qu’en tant que langage compilé, il offre moins de risques d’autodestruction au moment de modifier du code que le C
    Abandonner de vieilles architectures n’a rien de déraisonnable non plus
  • Pour un projet de la taille de Debian, élargir les options est logique. Ajouter Rust est une décision tout à fait compréhensible
    Décider quels langages retirer ou ajouter relève des mainteneurs Debian
  • Linux a déjà abandonné depuis des décennies la lutte contre la complexité