Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.
Peu être parce qu'une avancée n'a pas forcément à être binaire.
Il y a beaucoup, d'avantage à cargo, déjà les lib dynamique, ce n'était pas faisable dans le cas de Rust, demander aux distributions de packager les lib pour un nouveau langage, ça n'est pas faisable, et cargo permet à n'importe qui de créer ça lib, et qu'elle soit facilement utilisable par tout le monde ce qui est un avantage énorme.
Cargo permet de gérer facilement les versions des lib utilisé, quitte à avoir deux fois la même lib à des versions différentes, ce qui pour développer et packager son programme, facilite énormément la chose.
Maintenant dans tous les avantages de cargo que j'ai cité, lesquels à quelques choses à voir avec la choucroute que sont les attaques par supply chaines ? aucun.
Dans le fait qu'une grosse lib, a plus de chances d'avoir des bugs que plusieurs petites lib, et est plus chiant à maintenir, est-ce que ça un rapport avec les attaques par supply-chaines ? toujours pas. (Différents types de vulnérabilité ne sont pas applicables pour les mêmes applications)
Sur une échelle du nombre de dépendances moyenne qui va de C a NPM en passant par pip, au milieu, Rust est quelque part entre pip et NPM.
Et voir cargo et rust, comme quelques d'autre que juste "bien/pas bien",
Ça permet de passer du débat stérile de "30% D'ERREUR MEMOIRE", à quel programme tu es en trains de codée, quel sont les avantages de rust dans un contexte particulier.
Si tu fais un serveur web, alors tu vas surement avoir assez de complexité pour que le nombre de dépendances pose moins de risque que les bénéfices de Rust.
Si tu recodes sudo, là aussi, je suppose qu'éviter les erreurs mémoire reste globalement une bonne chose. (Même si la bonne réponse pour de la sécu reste doas, pas sudo-rs)
Si tu recodes coreutils, qui globalement n'est pas fait pour être utilisé en réseaux, et où la majorité des failles mémoire aussi graves soit elles seront difficilement exploitables, recoder en Rust pour de la sécurité, reste questionnable.
Et si on assume que Rust est plus vulnérable au supply-chain attaque, alors ça reste plutôt négatif en terme d'impact sécuritaire.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 1.
Peu être parce qu'une avancée n'a pas forcément à être binaire.
Il y a beaucoup, d'avantage à cargo, déjà les lib dynamique, ce n'était pas faisable dans le cas de Rust, demander aux distributions de packager les lib pour un nouveau langage, ça n'est pas faisable, et cargo permet à n'importe qui de créer ça lib, et qu'elle soit facilement utilisable par tout le monde ce qui est un avantage énorme.
Cargo permet de gérer facilement les versions des lib utilisé, quitte à avoir deux fois la même lib à des versions différentes, ce qui pour développer et packager son programme, facilite énormément la chose.
Maintenant dans tous les avantages de cargo que j'ai cité, lesquels à quelques choses à voir avec la choucroute que sont les attaques par supply chaines ? aucun.
Dans le fait qu'une grosse lib, a plus de chances d'avoir des bugs que plusieurs petites lib, et est plus chiant à maintenir, est-ce que ça un rapport avec les attaques par supply-chaines ? toujours pas. (Différents types de vulnérabilité ne sont pas applicables pour les mêmes applications)
Sur une échelle du nombre de dépendances moyenne qui va de C a NPM en passant par pip, au milieu, Rust est quelque part entre pip et NPM.
Et voir cargo et rust, comme quelques d'autre que juste "bien/pas bien",
Ça permet de passer du débat stérile de "30% D'ERREUR MEMOIRE", à quel programme tu es en trains de codée, quel sont les avantages de rust dans un contexte particulier.
Si tu fais un serveur web, alors tu vas surement avoir assez de complexité pour que le nombre de dépendances pose moins de risque que les bénéfices de Rust.
Si tu recodes sudo, là aussi, je suppose qu'éviter les erreurs mémoire reste globalement une bonne chose. (Même si la bonne réponse pour de la sécu reste
doas, passudo-rs)Si tu recodes coreutils, qui globalement n'est pas fait pour être utilisé en réseaux, et où la majorité des failles mémoire aussi graves soit elles seront difficilement exploitables, recoder en Rust pour de la sécurité, reste questionnable.
Et si on assume que Rust est plus vulnérable au supply-chain attaque, alors ça reste plutôt négatif en terme d'impact sécuritaire.