Discussion :

[Anthony]

La fondation Rust signale que 20 % des crates Rust utilisent le mot-clé "Unsafe", qui offre aux développeurs une certaine flexibilité dans les cas où les garanties du compilateur sont trop restrictives

La fondation Rust rapporte que près de 20 % des crates Rust utilisent le mot-clé « unsafe », ce qui met en évidence un aspect critique de la gestion de la mémoire dans la programmation Rust. Alors que Rust est réputé pour ses dispositifs de sécurité robustes, les blocs de code « unsafe » offrent aux développeurs une certaine flexibilité dans les situations où les garanties du compilateur sont trop restrictives. Malgré ces blocs, Rust maintient des protections strictes pour minimiser les vulnérabilités. La fondation Rust continue de mettre l'accent sur la sécurité, en développant des outils et des initiatives pour soutenir l'utilisation sécurisée de « unsafe » dans la programmation Rust.

Rust est un langage de programmation polyvalent multi-paradigme qui met l'accent sur les performances, la sécurité des types et la concurrence. Il assure la sécurité de la mémoire, c'est-à-dire que toutes les références pointent vers une mémoire valide, sans ramasse-miettes. Afin d'assurer simultanément la sécurité de la mémoire et d'éviter les courses aux données, son « vérificateur d'emprunts » suit la durée de vie de toutes les références d'un programme pendant la compilation.

Un billet de blog de la Fondation Rust commence par rappeler aux lecteurs que les programmes Rust « ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution ». Mais le billet poursuit en explorant « Unsafe Rust in the wild » (utilisé pour un petit ensemble d'actions telles que le déréférencement d'un pointeur brut, la modification d'une variable statique mutable ou l'appel à des fonctions non sûres).

« À première vue, il peut sembler que Unsafe Rust compromette les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est accompagné de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées. »

La Fondation énumère dans son billet les mesures de protection disponibles, qui « rendent les exploits rares, mais pas impossibles ». Mais elle analyse également la quantité de code Rust qui utilise réellement le mot-clé unsafe.

Le contenu du billet de blog de la Fondation Rust est présenté ci-dessous :

Les programmes accèdent à la mémoire - ce concept est fondamental en informatique. Selon le langage de programmation utilisé pour écrire le code, il existe différentes manières de gérer l'allocation et l'utilisation de cette mémoire. Chaque approche requiert prudence et précaution.

Un accès involontaire et hors de portée aux zones de mémoire d'un programme peut exposer des données sensibles ou servir de point d'entrée pour l'exploitation, ce qui représente un risque important et peut contribuer à des attaques de type « zero-day ». En résumé, qu'un programmeur gère et alloue la mémoire manuellement ou qu'il compte sur le langage et le compilateur pour le faire à sa place, des pratiques robustes de gestion de la mémoire sont une nécessité.

Les problèmes de sécurité de la mémoire représentent une part importante des vulnérabilités des logiciels. Les acteurs malveillants en sont bien conscients et utilisent un ensemble évolutif de tactiques pour exploiter le code non sécurisé en mémoire dans certaines des attaques logicielles les plus reconnaissables et les plus dommageables de ces dernières années, telles que Heartbleed.

Compte tenu du nombre d'exploits logiciels nuisibles qui hantent notre industrie et de l'importance des enjeux, les fondations de logiciels, les consortiums technologiques et les gouvernements du monde entier prennent conscience de la situation et plaident en faveur de l'amélioration des pratiques et des outils de programmation.

La puissance et la promesse de Rust

Le langage de programmation Rust est souvent cité par les défenseurs de la sécurité de la mémoire comme l'un des langages de programmation les plus sûrs sur le marché aujourd'hui. Langage à mémoire sécurisée par défaut grâce à un concept appelé ownership, Rust fournit des règles et des garanties pour la gestion de la mémoire et considère la sécurité comme un concept de premier ordre.

Les programmes utilisant Rust ne peuvent pas être compilés si les règles de gestion de la mémoire sont violées, ce qui élimine essentiellement la possibilité d'un problème de mémoire au moment de l'exécution. Les développeurs Rust et les utilisateurs d'applications écrites en Rust ont ainsi la certitude que les vulnérabilités de la mémoire ne doivent pas être un sujet de préoccupation.

Safe Rust et « Unsafe Rust »

Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe.

Bien que l'utilisation de Unsafe Rust puisse théoriquement produire des vulnérabilités similaires à celles des langages non sûrs pour la mémoire, il existe quatre mesures de protection principales pour réduire ces risques à près de zéro :

1. L'utilisation du mot-clé unsafe en Rust est un acte explicite, exigeant du développeur qu'il choisisse de le faire. Cela signifie que vous ne pourrez jamais entrer dans un contexte unsafe au sein de votre code Rust sans faire l'effort conscient de le faire ; d'autres langages peuvent vous permettre d'appeler directement du code unsafe ou non géré.
2. Le code unsafe doit être isolé dans ses propres blocs de code. Si un problème survient lors de l'utilisation de Unsafe Rust, le code à l'origine du problème est clairement identifié.
3. Il y a un nombre limité de façons d'utiliser unsafe et tout le code safe Rust continue à avoir ses contrôles de sécurité normaux même à l'intérieur d'un bloc unsafe.
4. Le système de types de Rust fournit toujours des contraintes de sécurité pour les types sûrs de Rust, même à l'intérieur d'un bloc unsafe.

Ces mesures supplémentaires renforçant Unsafe Rust rendent les exploits rares, mais pas impossibles. Pour déterminer le risque posé par Unsafe Rust, il faut examiner combien de code Rust utilise le mot-clé unsafe.

Unsafe Rust en milieu naturel

La façon canonique de distribuer du code Rust est par le biais d'un paquetage appelé crate. En mai 2024, il existe environ 145 000 crates, dont environ 127 000 contiennent du code significatif. Sur ces 127 000 crates, 24 362 font usage du mot-clé unsafe, soit 19,11 % de tous les crates. Et 34,35 % font un appel direct à une fonction dans une autre crate qui utilise le mot-clé unsafe. Près de 20 % de tous les crates ont au moins une instance du mot-clé unsafe, ce qui n'est pas négligeable.

La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++. En fait, la crate qui utilise le plus le mot-clé unsafe est la crate Windows, qui permet aux développeurs Rust de faire appel à diverses API Windows. Cela ne signifie pas que le code de ces blocs Unsafe Rust est exploitable en soi (la majorité ou la totalité de ce code ne l'est probablement pas), mais qu'une attention particulière doit être portée à l'utilisation de Unsafe Rust afin d'éviter les vulnérabilités potentielles.

À première vue, il peut sembler que Unsafe Rust réduit les avantages de sécurité de la mémoire pour lesquels Rust est de plus en plus célébré. En réalité, le mot-clé unsafe est assorti de garanties spéciales et peut être un moyen puissant de travailler avec moins de restrictions lorsqu'une fonction nécessite de la flexibilité, tant que les précautions standard sont utilisées.

Sûreté et sécurité : une responsabilité partagée

Comme cela a été dit, Rust est à la hauteur de sa réputation d'outil excellent et transformateur pour une programmation sûre et sécurisée, même dans un contexte Unsafe. Mais cette réputation nécessite des ressources, une collaboration et un examen constant pour être maintenue correctement. Par exemple, le projet Rust continue de développer des outils comme Miri pour permettre la vérification du code Rust non sécurisé. La Rust Foundation s'est engagée dans ce travail par le biais de son initiative de sécurité : un programme visant à soutenir et à faire progresser l'état de la sécurité au sein de l'écosystème et de la communauté du langage de programmation Rust. Dans le cadre de l'initiative de sécurité, l'équipe technologique de la Fondation Rust a développé de nouveaux outils tels que Painter, TypoMania et Sandpit pour détecter les vulnérabilités dans le code Rust, donnant aux utilisateurs un aperçu des vulnérabilités avant qu'elles ne se produisent et permettant une réponse rapide en cas d'exploitation.

La sûreté est une responsabilité partagée - ce concept est fondamental pour des communautés saines. Entre les développeurs qui utilisent Unsafe Rust, les groupes qui préconisent l'utilisation d'outils d'amélioration de la sécurité comme Rust, et les responsables du langage comme la Fondation Rust, nous avons tous un rôle à jouer dans les pratiques de programmation sécurisée. La collaboration et l'attention constante portée à la sécurité permettront au langage de rester aussi résistant que possible aux vulnérabilités à l'avenir.

Source : "Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust" (Fondation Rust)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Comment Rust améliore la sécurité de son écosystème : la Rust Foundation publie un rapport sur ce que leur initiative de sécurité a accompli au cours des six derniers mois de 2023

Consumer Reports publie un rapport détaillé encourageant l'adoption généralisée de langages sûrs pour la mémoire tels que Rust, et sensibilise sur les risques liés à la sécurité de la mémoire

[Uther]

La plupart de ces utilisations Unsafe Rust sont des appels à du code ou à des bibliothèques de langages tiers non Rust, tels que C ou C++.

C'est dommage qu'il n'y ait pas de chiffre précis là dessus, car pour le coup ça fausse complètement la perception des autres chiffres.
C'est difficile de reprocher a Rust de ne pas assurer la sécurité du code écrit dans d'autre langages.

[Padget]

c'est pour ce mot clé que je considère que rust n'est pas plus sécurisé que le cpp. au final les gens qui font du code sécurisé en rust utilisent juste des sections unsafe bien faites (espérons le) de la std. en gros c'est pareil que les constructeurs/destructeurs en cpp

[Uther]

C'est différent de C++ dans le sens où la quantité de code à risque dont il faut particulièrement surveiller la validité de la mémoire est réduite à de petites sections clairement identifiées. En Rust, on ne peut pas introduire un risque d'insécurité mémoire sans s'en rendre compte.

Les problèmes de sécurité mémoire de C++ ne sont malheureusement pas limités aux constructeurs et même si c'était le cas, ça resterait une quantité de code exposée plus élevée que ce qu'il est normalement nécessaire de mettre en unsafe.

[RenarddeFeu]

Un programme ne peut pas être plus sécurisé que son maillon le plus faible. Il faudra un certain temps avant que Rust ne devienne hégémonique et qu'on puisse se passer totalement des briques tierces en C/C++/Fortran.

[Uther]

Oui le pirate visera toujours le maillon le plus faible, mais la sécurité ne fonctionne clairement pas en mode tout ou rien. En réduisant la quantité de code à risque, on diminue le risque de laisser une erreur exploitable.

Bien sur que Rust ne pourra jamais tout remplacer, et certainement pas du jour au lendemain. D'ailleurs même un code écrit 100% en Rust, sans aucun bloc unsafe ni composants externes, ne garantit pas une absence de failles de sécurité. Cependant, plus Rust permettra de diminuer la surface d'attaque, plus on gagnera en sécurité.

[Patrick Ruiz]

La communauté Rust reconnaît que le langage n’est pas sécurisé au travers d’une récente annonce
De lancement d’une initiative de vérification de 7500 fonctions non sûres de la bibliothèque standard Rust

Amazon Web Services va, dans un effort conjoint avec la Fondation Rust, payer des développeurs pour vérifier 7500 fonctions non sécurisées de la bibliothèque Rust. C’est ce qui ressort d’une récente annonce qui ravive le débat sur la question de savoir si le Rust, initialement présenté comme un meilleur gage de sécurité pour les logiciels que C et C++, est en réalité plus sécurisé.

Rust propose des moyens de contourner ses garanties de sécurité en utilisant le mot-clé "unsafe". La documentation précise à ce propos que « si Rust ne vous permettait pas d'effectuer des opérations non sécurisées, vous ne pourriez pas accomplir certaines tâches, comme interagir directement avec le système d'exploitation, bien qu'elle ajoute que vous utilisez cette possibilité à vos propres risques ». Les risques dont il est question comprennent le déréférencement de pointeurs nuls qui est une source courante de problèmes de sécurité.

C’est aussi ce que rapporte la fondation Rust lorsqu’elle souligne que 20 % des unités de compilation Rust s’appuient sur le mot-clé "unsafe" :

« Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe. »

La récente publication d’AWS va plus loin en soulignant que même si les développeurs n'utilisent que du code sûr, la plupart des applications dépendent toujours de la bibliothèque standard Rust dans laquelle on retrouve environ 7500 fonctions non sécurisées. Grosso modo, la publication d’Amazon suggère qu’une mauvaise utilisation de Rust peut conduire aux mêmes problèmes en matière de sécurisation de la mémoire des logiciels rencontrés avec des langages concurrents comme le C et le C++. En d’autres termes, la faille ultime se trouverait entre la chaise et le clavier et c’est le programmeur.

Verify the Safety of the Rust Standard Library https://t.co/d61FSp6EjR #rustlang #devops #programming

— Dinko Korunic (@dkorunic) November 22, 2024

Des initiatives comme Fil-C et Safe C++ ont vu le jour pour apporter une meilleure réponse aux problèmes de sécurisation de la mémoire des logiciels en C et C++

Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.

« Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games à propos de Fil-C.

« Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »

Ces initiatives font surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux

Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Source : AWS

Et vous ?

Quel est votre expérience avec Rust en tant que langage de programmation et en particuluer avec les cas d'utilisation du mot-clé "unsafe" ? Les garanties de sécurisation de la mémoire qui sont attribuées à ce langage en comparaison au C et au C++ sont elles exagérées ?
Le potentiel problème avec Rust n’est-il pas le même qu’avec C et C++ : la qualité des programmeurs ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[denisys]

En d’autres termes, la faille ultime se trouverait entre la chaise et le clavier et c’est le programmeur.

Sans compter le porte monnaie du Manageur.
Hélas, hélas, hélas !!!!!

[Uther]

Amazon Web Services va, dans un effort conjoint avec la Fondation Rust, payer des développeurs pour vérifier 7500 fonctions non sécurisées de la bibliothèque Rust. C’est ce qui ressort d’une récente annonce qui ravive le débat sur la question de savoir si le Rust, initialement présenté comme un meilleur gage de sécurité pour les logiciels que C et C++, est en réalité plus sécurisé.

Ça ne ravive rien du tout. Le Rust n'a jamais prétendu empêcher tous les problèmes dans toutes les situations. Tous les gens un minimum renseignés savent que la bibliothèque standard contient des blocks unsafe (code non garanti par le compilateur) et c'est parfaitement attendu : elle doit fournir des abstraction sures aux appels systèmes fondamentalement unsafe. Ça reste toujours mieux que les lib standards de C et C++ qui n'ont pas de notion des sécurité intégrées au langage et qui laissent volontairement la possibilité d'utiliser certaines de leur abstractions de manière non sécurisée sans avertissement.

Que l'on essaye de vérifier formellement le code unsafe de Rust, reste quand même un plus pour pour améliorer encore la confiance que l'on peut lui accorder. Par contre, ce qui m'intrigue dans la démarche c'est qu'un code vérifié ne le reste que tant qu'il n'est pas modifié, je serais curieux de voir comment ils prévoient de gérer ça vu que la bibliothèque standard évolue en continu.

[prisme60]

Il n'y a pas photo. La sécurité du code Rust dépasse largement ce que l'on trouve en C et C++. Comme toute chose, il y a des marges d'amélioration, Rust reste un langage jeune, et il ne possède pas encore d'historique lourd à porter.

Le C est trop laxiste sur les appels de fonctions, gestion totalement manuelle des allocations dynamique sur le tas (malloc/free).

Le C++ a comblé quelques manques avec les différentes évolutions (regex, jthread, lambda, async/future, ranges/views), et au passage à rajouter une complexité supplémentaire (opérateur move, démultiplication des constructeurs, constraints/concepts, modules).

[OuftiBoy]

Ça ne ravive rien du tout. Le Rust n'a jamais prétendu empêcher tous les problèmes dans toutes les situations. Tous les gens un minimum renseignés savent que la bibliothèque standard contient des blocks unsafe (code non garanti par le compilateur) et c'est parfaitement attendu : elle doit fournir des abstraction sures aux appels systèmes fondamentalement unsafe. Ça reste toujours mieux que les lib standards de C et C++ qui n'ont pas de notion des sécurité intégrées au langage et qui laissent volontairement la possibilité d'utiliser certaines de leur abstractions de manière non sécurisée sans avertissement.

Je m'intéresse à Rust depuis un petit moment, sans l'avoir encore "adopté" cependant. Effectivement, Rust permet l'écriture d'un code plus "safe", via divers mécanismes (mais ce n'est pas le sujet). Mais comme tout langage, il se doit de posséder une librairie standard. Et comme beaucoup de langages, il s'appuie sur des librairies écritent en 'C'.

Normalement, petit à petit, je pense que l'équipe de Rust tentera de s'affranchir de ces librairies, et c'est un travail énorme qui prendra encore quelques temps. Mais cela ne retire en rien les mécanismes "safe" de Rust.

Que l'on essaye de vérifier formellement le code unsafe de Rust, reste quand même un plus pour pour améliorer encore la confiance que l'on peut lui accorder. Par contre, ce qui m'intrigue dans la démarche c'est qu'un code vérifié ne le reste que tant qu'il n'est pas modifié, je serais curieux de voir comment ils prévoient de gérer ça vu que la bibliothèque standard évolue en continu.

Oui, l'équipe "Rust" n'a pas la main sur tout. Peut-être faudrait-il arrêter l'évolution de la librairie standard, et faire un audit pour savoir ce qui est "safe" et ce qui ne l'est pas. D'après l'équipe "Rust" elle-même, 20 % du code de la librairie standard utilise des parties "unsafe". Ils devraient communiquer et donner la liste de ce qui est "safe" ou pas. (peut-être l'ont-ils fait, mais je n'en ai pas connaissance).

Mais, la question qui pour moi est la plus importante, c'est de savoir si l'utilisation de ces 20% de bloc "unsafe" sont utilisés pour fournir "rapidement" une librairie standard relativement complète, OU s'il est impossible de se passer de ces blocs "unsafe" pour avoir les fonctionnalités contenues dans ces 20%.

S'il s'avère que Rust ne peut pas transformer/fournir/écrire ces 20% "unsafe", ça serait dommage, car Rust a des atouts et il ne faudrait pas jeter le bébé avec l'eau du bain.

BàV et Peace & Love.

[Freem]

Oui, l'équipe "Rust" n'a pas la main sur tout. Peut-être faudrait-il arrêter l'évolution de la librairie standard, et faire un audit pour savoir ce qui est "safe" et ce qui ne l'est pas. D'après l'équipe "Rust" elle-même, 20 % du code de la librairie standard utilise des parties "unsafe". Ils devraient communiquer et donner la liste de ce qui est "safe" ou pas. (peut-être l'ont-ils fait, mais je n'en ai pas connaissance).

Ce qui m'amuse toujours énormément avec le bruit autour de Rust, c'est qu'on dirait que tous les bugs du monde sont des bugs de corruption mémoire... mais c'est loin d'être le cas.

Si la bibliothèque standard de rust évolue encore tant, c'est que le langage est loin d'être mûr, et par conséquent, plein de bugs, et donc, pas safe. Au moins, pour le C et le C++, on dispose de décennies d'expérience, les fonctions dangereuses sont bien identifiées, de nombreux outils (gratuits, donc pas de raison de pas les utiliser, mais malheureusement les systèmes de CI/CD déployés sur `git[a-z]{3}` les intègrent rarement... d'ailleurs ils vérifient jamais que chaque commit passe les tests, juste le dernier de la PR... c'est hors sujet.) aident a en éviter l'usage.

Ces outils existent uniquement grâce à l'expérience accumulée par les utilisateurs de ces langages. Ces fonctions ne peuvent pas être supprimées (du standard), parce que l'historique, c'est important, quand on travaille sur un projet sérieux et pas du code jetable. Typiquement, les programmes `chat` et `pppd` qui sont régulièrement utilisés pour interagir avec des modems étaient encore pleins de morceaux de C K&R encore récemment, par exemple le commit 75870d7b55e36af526a0786fff94912989c73fd1 de https://github.com/ppp-project/ppp.git mentionne K&R, en 2020.

Personnellement, je ne comprendrais pas l'adoption d'un outil si jeune et qui ne cesse de muter pour réaliser un projet qui serait censé être utilisé pour plus de 10 ans. Non, il ne sera plus maintenu super activement quelques années plus tard, s'il juste marche et n'est pas un projet de type "frontal", faut pas rêver. Ce n'est pas parce que c'est rust que la nature de l'humain et de la logique de marché changera: y'a pas le temps de maintenir les vieux trucs qui marchent, ça coûte trop cher et c'est trop chiant, surtout qu'on risque de casser plein de trucs a chaque changement, en pratique. Pour ce genre de points, rien ne vaut un bon vieux XKCD: https://xkcd.com/1172/

Tout ceci étant dit...
Je trouve très amusante cette parenthèse d'un article trouvé après avoir cherché des sources a croiser avec cet article: "if used incorrectly" (https://aws.amazon.com/blogs/opensou...ndard-library/)

Alors, pour info, tout langage est sûr, en fait, tant qu'il est utilisé correctement... Je suis plutôt un détracteur de rust en général, parce que le battage marketing a souvent un effet contraire sur moi, que le langage ne fournit pas les garanties que C++ me donne (stabilité des APIs sur le temps, support de l'historique, plusieurs implémentations, ...) mais la franchement mon détecteur de bullshit a tourné au rouge vif...

Pareil, "y'a des trucs pas safe!" ben oui, c'est la base des I/Os. Les langages fonctionnels sont horribles a utiliser justement parce que les I/Os sont des plaies, justement parce qu'ils veulent être "safe". Il est important de se souvenir que la sécurité impacte systématiquement, directement et négativement l'utilisabilité.
Le rôle d'un ingénieur qui crée un outil (et c'est vrai ailleurs que dans l'informatique, hein) c'est de trouver un équilibre entre les deux, de sorte a ce que les utilisateurs ne virent pas les protections quant ils utilisent l'outil (le pare-étincelles de la meule, exemple typique d'élément de sécurité qui saute. Le truc à la con sur les briquets, encore pire, ne parlons donc pas des sécurités dans les prises, moi, je les défonce systématiquement, c'est tout sauf intelligent).
Il est donc normal que Rust, s'il souhaite rester utilisable, conserve un risque de faire des erreurs. De toute façon, y'a que ceux qui font rien qui font pas d'erreurs.
Franchement, j'accrocherai dans ma chambre le portrait de la personne qui arrive a créer un langage avec lequel il sera possible d'écrire un logiciel qui nécessite l'accès au réseau internet et dont le compilateur garanti qu'aucun incident se produisant sur le médium physique ne puisse affecter l'éco-système ou le-dit logiciel tourne.

[imperio]

Ce qui m'amuse toujours énormément avec le bruit autour de Rust, c'est qu'on dirait que tous les bugs du monde sont des bugs de corruption mémoire... mais c'est loin d'être le cas.

Ce n'est ni l'objet de cet article, ni quelque chose que Rust prétend. Rust supprime les erreurs mémoires et souvent il est rappelé que cela n'impacte pas les bugs de logiques.

Si la bibliothèque standard de rust évolue encore tant, c'est que le langage est loin d'être mûr, et par conséquent, plein de bugs, et donc, pas safe.

On parle pas d'évolution là mais de vérification formelle. Et on ne fait pas de la vérification formelle parce que c'est buggé mais pour s'assurer que dans des conditions données, aucun bug n'a pu être détecté et donc que ce code est sûr. C'est quelque chose qui se fait aussi beaucoup dans certains projets en C.

Au moins, pour le C et le C++, on dispose de décennies d'expérience, les fonctions dangereuses sont bien identifiées, de nombreux outils (gratuits, donc pas de raison de pas les utiliser, mais malheureusement les systèmes de CI/CD déployés sur `git[a-z]{3}` les intègrent rarement... d'ailleurs ils vérifient jamais que chaque commit passe les tests, juste le dernier de la PR... c'est hors sujet.) aident a en éviter l'usage.

Euh ok. Donc si t'es un nouveau qui débarque en C/C++, il faut que tu apprennes tout ça par coeur pour savoir ce que tu peux utiliser. Super.

Ces outils existent uniquement grâce à l'expérience accumulée par les utilisateurs de ces langages. Ces fonctions ne peuvent pas être supprimées (du standard), parce que l'historique, c'est important, quand on travaille sur un projet sérieux et pas du code jetable.

Oui c'est sûr. Mieux vaut se trimballer du code dangereux parce qu'historiquement il a toujours été là.

Personnellement, je ne comprendrais pas l'adoption d'un outil si jeune et qui ne cesse de muter pour réaliser un projet qui serait censé être utilisé pour plus de 10 ans. Non, il ne sera plus maintenu super activement quelques années plus tard, s'il juste marche et n'est pas un projet de type "frontal", faut pas rêver. Ce n'est pas parce que c'est rust que la nature de l'humain et de la logique de marché changera: y'a pas le temps de maintenir les vieux trucs qui marchent, ça coûte trop cher et c'est trop chiant, surtout qu'on risque de casser plein de trucs a chaque changement, en pratique. Pour ce genre de points, rien ne vaut un bon vieux XKCD: https://xkcd.com/1172/

La première release de Rust date de 2015. Donc c'est relativement jeune. Cependant de plus en plus de grosses entreprises paient pour son développement donc les chances que son développement s'arrête s'amenuisent de plus en plus.

Tout ceci étant dit...
Je trouve très amusante cette parenthèse d'un article trouvé après avoir cherché des sources a croiser avec cet article: "if used incorrectly" (https://aws.amazon.com/blogs/opensou...ndard-library/)

Alors, pour info, tout langage est sûr, en fait, tant qu'il est utilisé correctement... Je suis plutôt un détracteur de rust en général, parce que le battage marketing a souvent un effet contraire sur moi, que le langage ne fournit pas les garanties que C++ me donne (stabilité des APIs sur le temps, support de l'historique, plusieurs implémentations, ...) mais la franchement mon détecteur de bullshit a tourné au rouge vif...

C++ ne fournit pas beaucoup de garanties à vrai dire. Le mangling n'est pas défini, chaque compilateur le gère comme il veut (super pour l'intéropérabilité). Il y a un nombre proprement effrayant de undefined behaviour. Et mon petit favori : "c'est copy ou c'est move ?". Je vois pas trop en quoi avoir plusieurs implémentations est un plus non plus. Le code Rust de 2015 compile toujours à ce jour donc pareil, je vois pas trop où est le souci. Pour faire simple : plutôt que de te braquer, si ça ne t'intéresse pas, ne lis pas ? Ou bien dans ce cas regarde ce que Rust fournit vraiment et regarde si ça correspond à tes besoins. Tout le reste c'est juste cracher gratuitement ta bile sur un sujet que tu ne connais pas.

Pareil, "y'a des trucs pas safe!" ben oui, c'est la base des I/Os. Les langages fonctionnels sont horribles a utiliser justement parce que les I/Os sont des plaies, justement parce qu'ils veulent être "safe". Il est important de se souvenir que la sécurité impacte systématiquement, directement et négativement l'utilisabilité.

C'est pas un problème de safety là mais bon... Si une I/O plante, c'est au programme de le vérifier avant d'utiliser les données. En Rust le langage te force à faire cette vérification pour pouvoir accéder à la donnée. En C/C++, c'est un oubli assez commun, même avec tous les meilleurs outils du monde.

Le rôle d'un ingénieur qui crée un outil (et c'est vrai ailleurs que dans l'informatique, hein) c'est de trouver un équilibre entre les deux, de sorte a ce que les utilisateurs ne virent pas les protections quant ils utilisent l'outil (le pare-étincelles de la meule, exemple typique d'élément de sécurité qui saute. Le truc à la con sur les briquets, encore pire, ne parlons donc pas des sécurités dans les prises, moi, je les défonce systématiquement, c'est tout sauf intelligent).
Il est donc normal que Rust, s'il souhaite rester utilisable, conserve un risque de faire des erreurs. De toute façon, y'a que ceux qui font rien qui font pas d'erreurs.
Franchement, j'accrocherai dans ma chambre le portrait de la personne qui arrive a créer un langage avec lequel il sera possible d'écrire un logiciel qui nécessite l'accès au réseau internet et dont le compilateur garanti qu'aucun incident se produisant sur le médium physique ne puisse affecter l'éco-système ou le-dit logiciel tourne.

Encore une fois à côté de la plaque. Dans le cas présent, Rust utilise du code `unsafe` surtout pour utiliser les APIs du systèmes.

Bref, j'ai l'impression que tu ne maitrises pas du tout la "safety" qui est évoquée dans cette article et que tu avais juste envie de venir cracher ta bile sur un outil que tu n'as jamais testé. Encore une fois, si ça ne t'intéresse, hé bien cesse d'interagir avec ces articles ?

[fdecode]

Personnellement, je ne comprendrais pas l'adoption d'un outil si jeune et qui ne cesse de muter pour réaliser un projet qui serait censé être utilisé pour plus de 10 ans. Non, il ne sera plus maintenu super activement quelques années plus tard, s'il juste marche et n'est pas un projet de type "frontal", faut pas rêver.

Rust était certes un projet de recherche de Mozilla, mais a depuis quelques années des soutiens de poids:
https://foundation.rust-lang.org/members/
Je parie plutôt sur une installation progressive et ferme du langage.

Je suis plutôt un détracteur de rust en général, parce que le battage marketing a souvent un effet contraire sur moi

De quel battage marketing parle-t-on? Le langage est gratuit, et tout ce qui tourne autour. Le langage n'appartient pas à une grande marque. Et pour le coup, il n'a certainement pas été créé par une équipe de marketeurs.

[Uther]

Mais comme tout langage, il se doit de posséder une librairie standard. Et comme beaucoup de langages, il s'appuie sur des librairies écritent en 'C'.
Normalement, petit à petit, je pense que l'équipe de Rust tentera de s'affranchir de ces librairies, et c'est un travail énorme qui prendra encore quelques temps.

La bibliothèque standard n'utilise aucune librairie écrite en C en mode core (sans accès à l'OS) et seulement la libc en mode std(avec accès à l'OS).
L'utilisation de la libc n'est pas faite pour économiser du travail : c'est juste parce que la plupart des OS n'ont pas de façon directe et stable de s'interfacer avec eux. La lib C est juste utilisée comme interface stable avec l'OS.

Mais, la question qui pour moi est la plus importante, c'est de savoir si l'utilisation de ces 20% de bloc "unsafe" sont utilisés pour fournir "rapidement" une librairie standard relativement complète, OU s'il est impossible de se passer de ces blocs "unsafe" pour avoir les fonctionnalités contenues dans ces 20%.

En Rust on utilise clairement pas des bloc unsafe par plaisir, s'ils sont utilisés dans la bibliothèque standard, c'est certainement qu'ils sont nécessaire, soit pour accéder a des fonctionnalités bas niveau que les règles de Rust ne peuvent garantir, soit pour des raisons de performance. Et en soi ça n'a rien de problématique pour l'utilisateur de la bibliothèque vu que ce code unsafe est encapsulé dans des abstraction qui elles sont safe.
Le but du projet est de vérifier que ces blocs de code, bien que marqués unsafe, sont corrects et que l'encapsulation est bien réalisée

Ce qui m'amuse toujours énormément avec le bruit autour de Rust, c'est qu'on dirait que tous les bugs du monde sont des bugs de corruption mémoire... mais c'est loin d'être le cas.

Par acquis de conscience je viens de regarder les dernières vulnérabilités reportées sur glibc (pour rester dans le domaine de la lib standard) : quasiment toutes étaient dues à des problèmes de mémoire. Donc, même si Rust ne garantira jamais l'absence totale de bug, c'est clairement un moyen très efficace pour en diminuer la quantité, surtout les plus dangereux pour la sécurité.

Si la bibliothèque standard de rust évolue encore tant, c'est que le langage est loin d'être mûr, et par conséquent, plein de bugs, et donc, pas safe. Au moins, pour le C et le C++, on dispose de décennies d'expérience

Si la bibliothèque standard évolue c'est que le langage évolue, ce qui est aussi le cas du C++. Le Rust aura bientôt 10 ans, et commence a avoir une utilisation assez conséquente pour échapper au procès en immaturité. Les retour sur l'utilisation du Rust montre clairement une amélioration de la sécurité et pas une dégradation.

les fonctions dangereuses sont bien identifiées, de nombreux outils (gratuits, donc pas de raison de pas les utiliser, mais malheureusement les systèmes de CI/CD déployés sur `git[a-z]{3}` les intègrent rarement... d'ailleurs ils vérifient jamais que chaque commit passe les tests, juste le dernier de la PR... c'est hors sujet.) aident a en éviter l'usage.Ces outils existent uniquement grâce à l'expérience accumulée par les utilisateurs de ces langages.Ces fonctions ne peuvent pas être supprimées (du standard), parce que l'historique, c'est important, quand on travaille sur un projet sérieux et pas du code jetable.

Sauf que l'efficacité des outils de vérification du C sont limitées, justement entre autre parce que le code dangereux nécessaire n'est pas correctement isolé du code sûr. Une grosse partie de la sécurité de Rust ressemble a ce que fait un analyseur statique de code C, mais le langage Rust a été conçu pour rendre cette vérification bien plus efficace.

Le C a certes développé des outils suite aux retours d'expérience, mais il ne faut pas croire que Rust serait reparti de zéro en ignorant l'état de l'art sur les autres langages. D'ailleurs, le nom de la toute première conférence qui a présenté Rust était clair là dessus : "Technology from the past come to save the future from itself".
Rust a complètement pris en compte l'expérience accumulée par d'autre langages (notamment le C et le C++). Et justement, le fait qu'il n'ait pas à gérer plusieurs dizaines d'années l'historique à permis de corriger à la racine beaucoup de problèmes qu'on peut juste essayer de mitiger en C et C++.

[fdecode]

La bibliothèque standard n'utilise aucune librairie écrite en C en mode core (sans accès à l'OS) et seulement la libc en mode std(avec accès à l'OS).
L'utilisation de la libc n'est pas faite pour économiser du travail : c'est juste parce que la plupart des OS n'ont pas de façon directe et stable de s'interfacer avec eux. La lib C est juste utilisée comme interface stable avec l'OS.

En l'occurrence, Redox OS développe sa rlibc écrite en Rust:
https://github.com/redox-os/relibc

[NotABread]

En l'occurrence, Redox OS développe sa rlibc écrite en Rust:
https://github.com/redox-os/relibc

Il me semble que me but initial, c'était la portabilité avec les programmes Linux et BSD vers Redox en refaisant la libc en Rust (et avoir en passant une alternative à libc écrit en Rust pour Linux). C'est devenu le medium pour implémenter une ABI stable pour Redox en chemin. Je me demande s'il sera possible pour Redox de passer à une ABI stable Rust lorsque celle-ci sera existera

[d_d_v]

Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois. A chaque sortie ou mise en avant d'un "nouveau" langage, on a droit toujours aux mêmes promesses. J'ai vu la même chose avec DotNet, Java (qui a aussi son mode unsafe si je me souviens bien), pour d'autres promesses mais aussi celle de la gestion mémoire.
La première sécurité, c'est d'embaucher des gens compétents, c'est pareil dans tous les domaines. Vous n'avez pas besoin de fournir un couteau avec une lame en plastique à un pâtissier de peur qu'il se blesse, vous ne placez pas trois contremaîtres pour chaque garagiste de peur qu'il fasse n'importe quoi dans le moteur, etc.
Avec c++26, les contrats logiciels vont (enfin) arriver, c'est ça la vraie sécurité: pouvoir assurer les préconditions/postconditions de chaque fonction, c'est à dire, une partie de son contrat. Il y a trop de code dans tous les langages ou les "ingénieurs" mélangent les erreurs exceptionnelles, les erreurs réelles et les erreurs de programmation (contrat logiciel), avec des if x != null au début de chaque fonction (alors que c'est l'appelant qui doit s'assurer de vérifier les paramètres avant d'appeler la fonction). Mais bon, trop de "codeurs" ici et pas assez d'ingénieurs, je vais encore me prendre une volée de votes négatifs

[fdecode]

Je vois que tous les fanatiques pro-rust sont de sortie ici à ce que je vois.

Je pensais que cette discussion concernait Rust. Serions-nous par mégarde intervenus fanatiquement dans une discussion concernant C++26?

Avec c++26, les contrats logiciels vont (enfin) arriver, c'est ça la vraie sécurité: pouvoir assurer les préconditions/postconditions de chaque fonction, c'est à dire, une partie de son contrat.

Je suis preneur de références à ce sujet. Quelles fonctionnalités de c++26, plus précisément?

À vrai dire, mais on ne parle sans doute pas de la même chose, j'utilise beaucoup les conditionnements de type en Rust (s'assurer qu'un type implémente effectivement un certain nombre de traits et donc de fonctionnalités) pour contrôler l'utilisation de mes fonctions ou de mes librairies.

[remi_inconnu]

Il y a plusieurs décennies, j'ai souvenir d'un langage merveilleux, censé résoudre tous les soucis de sécurité... Java, on connait l'histoire depuis.
Rust ne m'a pas l'air fini et n'est pas évident à prendre en main, et quand on a baigné dans un univers orienté objet, il ne donne pas vraiment envie de devoir s'en passer.
A notre époque on est noyé par des nouveaux langages, tous plus merveilleux que les précédents, et souvent bien éphémère, je ne dis pas que pour Rust sera pareil, mais avant de miser tout sur ce langage, il faut bien réfléchir aux conséquences, et peut être il ne sera qu'une mode passagère, comme beaucoup d'autre avant lui et après lui.
Ne jamais oublier que la première cause de défaillance de sécurité, se situe toujours entre la chaise et le clavier, croire qu'avec un langage, on va tout faire disparaître comme par magie, me fait beaucoup rire, surtout quand c'est des personnes gouvernantes qui disent cela en interview, ces mêmes personnes qui n'ont jamais écrit aucune ligne de code de leur vie.