Ma comparaison avec npm, c'est car cargo ressemble plus à npm que make, donc ma remarque, c'est que cargo ajoute aussi une surface d'attaque que make n'a pas.
Je ne vois pas trop la différence dans l'absolu. La gestion des dépendance en C et C++ est pénible, avec beaucoup d'étapes manuelles, maintenir à jour la bibliothèque en cas de compilation statique est loin d'être automatique, les attaques sur des dépendances en C ou C++ n'ont pas attendu cargo pour exister dont xz a été la preuve. Et ce n'est pas pour rien que de nombreuses distributions ont investi dans la compilation reproductible pour justement identifier plus facilement si cela arrivait. Cela concerne tous les langages.
En terme de volume les attaques de supply chains restent moins courants que les soucis de mémoire.
Le nombre de vulnérabilités n'est pas forcément une valeur intéressante parce que la base d'utilisation de programme en C, et les enjeux a introduire des portes dérobées sont plus grandes que ceux pour leur équivalent en Rust.
Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust, statistiquement tu peux réduire de 30% le nombre de failles. Et tu réduis aussi le risque de certains bogues, tu allèges la charge mentale des mainteneurs sur ces questions, etc. À périmètre fonctionnel constant. Ce n'est pas un détail. On ne parle pas de comparer un projet C d'un projet Rust qui n'ont rien à voir car cela n'a pas de sens.
En gros si libc/coreutils/curl devraient se voir remplacer par du rust, on va surement enlevé 29% de faille de sécurités lié à la mémoire, par contre le pourcentage de CVE lier à des attaque par supply chain, il va augmenter, mais vu que des coreutils qui utilise cargos pour build, ça reste quelques chose de marginal aujourd'hui, on ne peu pas prédire l'impact que ça auras.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5.
Je ne vois pas trop la différence dans l'absolu. La gestion des dépendance en C et C++ est pénible, avec beaucoup d'étapes manuelles, maintenir à jour la bibliothèque en cas de compilation statique est loin d'être automatique, les attaques sur des dépendances en C ou C++ n'ont pas attendu cargo pour exister dont xz a été la preuve. Et ce n'est pas pour rien que de nombreuses distributions ont investi dans la compilation reproductible pour justement identifier plus facilement si cela arrivait. Cela concerne tous les langages.
En terme de volume les attaques de supply chains restent moins courants que les soucis de mémoire.
Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust, statistiquement tu peux réduire de 30% le nombre de failles. Et tu réduis aussi le risque de certains bogues, tu allèges la charge mentale des mainteneurs sur ces questions, etc. À périmètre fonctionnel constant. Ce n'est pas un détail. On ne parle pas de comparer un projet C d'un projet Rust qui n'ont rien à voir car cela n'a pas de sens.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.