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.
Des CVEs il y en aura toujours, et plus il y aura de code écrit en Rust, par plus de développeur, plus on trouvera de CVE dans les implémentations en Rust.
Alors oui, la nature des CVEs change. 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, ...) ?
Par exemple, l'article cite comme bug absent de l'implémentation Rust:
No data races on shared mutable state.
Pour coreutils spécifiquement, qui est un ensemble de programmes "single threaded", est-ce pertinent ?
No use after free, no double free
Une grande partie des programmes de coreutils n'ont même pas besoin de faire d'allocation dynamique.
[^] # Re: Intéressant !
Posté par David Delassus (site web personnel) . En réponse au lien Les bugs que rust ne détectera pas. Évalué à 4 (+2/-0).
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.
Des CVEs il y en aura toujours, et plus il y aura de code écrit en Rust, par plus de développeur, plus on trouvera de CVE dans les implémentations en Rust.
Alors oui, la nature des CVEs change. 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, ...) ?
Par exemple, l'article cite comme bug absent de l'implémentation Rust:
Pour coreutils spécifiquement, qui est un ensemble de programmes "single threaded", est-ce pertinent ?
Une grande partie des programmes de coreutils n'ont même pas besoin de faire d'allocation dynamique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg