Une lib dynamique packager par APT donc un mainteneur de ta distro (donc fix sur un apt update), c'est la même chose qu'une lib static tirer par une autre dépendance que tu as utilisé, et maintenue par 1/4 de personnes qui sait même pas que ça lib est utilisé sur ta distro ?
Pas forcément un mainteneur de ta distro, tu peut avoir de multiples sources, tu peut aussi avoir une bibliothèque qui arrive par ailleurs en soit c’est la sécurité de ton système de fichier qui est en jeu.
Parce que en Rust la majorité de tes dépendances sont statiques, et tu peux avoir plusieurs fois la même, mais a des versions diférents dans le même projet. (ce qui arrive à peu près jamais en C).
Dans le même projet ? Tu veut dire qu’une crate aurait linké statiquement une dépendance que tu récupère par ailleurs ? Les crates étant non compilées je ne vois pas comment ça pourrait arriver.
Et si ta dépendance casse, bah, tu gardes la faille tant que ton binaire n'a pas étais packager.
Les usines de build sont la norme, ça n’est plus un si gros problème. Le linkage dynamique élève d’un cran la complexité des problèmes qui peuvent arriver comme l’a très bien montré CVE-2024-3094 sur xz l’an dernier.
Donc cargo est meilleur pour te prendre pleins de dépendances que tu sais même pas que tu les utilises, et qui sont maintenus par personnes.
Je trouve en soit toujours très surprenant quand dans une communauté autour du libre on pointe de doigt le fait de réutiliser du code comme un problème.
L’approche consistant à avoir peu de dépendances et ne pas trop gérer leurs versions en délégant ça aux distributions n’est pas sans conséquence. Il est mathématiquement largement plus simple de sécuriser une supply chain que l’ensemble des machines des utilisateurs.
Mais tout ça pour dire que c’est un problème indépendant du langage et qu’ils sont plus système que des problèmes de programmation. Ils apparaîtront plus si un jour on arrive à supprimer tous les problèmes mémoire, mais on sera bien content de voir ça arriver (tout comme tu es content de ne plus voir d’erreur de collision de hash arriver quand tu passe à une bonne fonction de hash).
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par barmic 🦦 . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3.
Pas forcément un mainteneur de ta distro, tu peut avoir de multiples sources, tu peut aussi avoir une bibliothèque qui arrive par ailleurs en soit c’est la sécurité de ton système de fichier qui est en jeu.
Dans le même projet ? Tu veut dire qu’une crate aurait linké statiquement une dépendance que tu récupère par ailleurs ? Les crates étant non compilées je ne vois pas comment ça pourrait arriver.
Les usines de build sont la norme, ça n’est plus un si gros problème. Le linkage dynamique élève d’un cran la complexité des problèmes qui peuvent arriver comme l’a très bien montré CVE-2024-3094 sur xz l’an dernier.
Je trouve en soit toujours très surprenant quand dans une communauté autour du libre on pointe de doigt le fait de réutiliser du code comme un problème.
L’approche consistant à avoir peu de dépendances et ne pas trop gérer leurs versions en délégant ça aux distributions n’est pas sans conséquence. Il est mathématiquement largement plus simple de sécuriser une supply chain que l’ensemble des machines des utilisateurs.
Mais tout ça pour dire que c’est un problème indépendant du langage et qu’ils sont plus système que des problèmes de programmation. Ils apparaîtront plus si un jour on arrive à supprimer tous les problèmes mémoire, mais on sera bien content de voir ça arriver (tout comme tu es content de ne plus voir d’erreur de collision de hash arriver quand tu passe à une bonne fonction de hash).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll