Il me semble, mais je me trompe peut-être, que les CVEs listées pour uutils sont bien plus facile à exploiter qu'un buffer overflow dans pwd.
Justement je n'en suis pas convaincu pour une bonne part d'entre eux. Beaucoup de choses demandent d'agir dans une fenêtre temporelle faible pour les exploiter.
Mais les problèmes de mémoires en C ne pourraient-ils pas être détecté avec de meilleurs tests (usage de ASan / UBSan, fuzzing, ...) ?
Cela aide mais est rarement suffisant. Je doute que les développeurs de coreutils n'aient jamais employés ces techniques.
En fait Rust réduit les problèmes en invalidant pas mal de programme en théorie valide mais risqué, et malgré tout l'outillage du C, tu dois composer avec ses limitations intrinsèques à cause d'une forte permissivité.
Pour coreutils spécifiquement, qui est un ensemble de programmes "single threaded", est-ce pertinent ?
Déjà je ne pense pas que ce soit vrai pour tous, d'ailleurs sort() fait un appel explicite à pthread. Et il n'y a pas de raisons que d'autres ne puissent pas être parallélisées selon les cas pour des opérations un peu lourde (genre quand les actions sont récursives).
L'usage du C peut être un frein à ce genre d'évolutions.
Une grande partie des programmes de coreutils n'ont même pas besoin de faire d'allocation dynamique.
Mais une bonne partie en a besoin.
Je pense que cette réécriture a plusieurs effets bénéfiques, un peu comme Clang vis à vis de GCC :
Cela force à devoir améliorer la documentation si des informations importantes n'étaient pas explicites
Cela force a décrire l'interface réelle de ces programmes, et d'associer cela à des tests pour s'assurer la compatibilité
Cela peut pousser coreutils à évoluer si par exemple les performances sont moins bonnes que la version Rust
[^] # Re: Intéressant !
Posté par Renault (site web personnel) . En réponse au lien Les bugs que rust ne détectera pas. Évalué à 7 (+4/-0).
Justement je n'en suis pas convaincu pour une bonne part d'entre eux. Beaucoup de choses demandent d'agir dans une fenêtre temporelle faible pour les exploiter.
Cela aide mais est rarement suffisant. Je doute que les développeurs de coreutils n'aient jamais employés ces techniques.
En fait Rust réduit les problèmes en invalidant pas mal de programme en théorie valide mais risqué, et malgré tout l'outillage du C, tu dois composer avec ses limitations intrinsèques à cause d'une forte permissivité.
Déjà je ne pense pas que ce soit vrai pour tous, d'ailleurs sort() fait un appel explicite à pthread. Et il n'y a pas de raisons que d'autres ne puissent pas être parallélisées selon les cas pour des opérations un peu lourde (genre quand les actions sont récursives).
L'usage du C peut être un frein à ce genre d'évolutions.
Mais une bonne partie en a besoin.
Je pense que cette réécriture a plusieurs effets bénéfiques, un peu comme Clang vis à vis de GCC :