Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils »,

Une alternative controversée proposée par le créateur du langage

Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils »
une alternative controversée proposée par le créateur du langage

Le comité du langage C++ travaille depuis plusieurs années sur des moyens d’améliorer la sécurité mémoire du langage, souvent critiqué pour ses vulnérabilités. En parallèle, Rust est devenu un modèle en matière de sûreté grâce à ses propriétés et son système de vérification stricte des accès mémoire. Le projet Safe C++ visait à créer un sous-ensemble du langage garantissant « une sécurité mémoire comparable à celle de Rust ». Mais la proposition vient d'être mise de côté, car elle n'est pas populaire auprès du comité. La priorité est donnée aux « Profils », un projet qui vise aussi à améliorer la sécurité du langage C++, mais sans s'inspirer du modèle de Rust.

La sécurité des logiciels est devenue une priorité pour les développeurs et les organisations du secteur public et privé. Des langages comme Rust, C#, et Go ont gagné en popularité grâce à leurs caractéristiques de sécurité mémoire intégrées. Cependant, le C++ reste un pilier dans le développement de systèmes performants et bas niveau. Pour répondre à cette demande croissante de sécurité, la communauté C++ a élaboré les extensions Safe C++.

Qu’est-ce que les extensions Safe 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++.


Le projet Safe C++ est le fruit d’une collaboration entre la C++ Alliance et des ingénieurs renommés comme Sean Baxter. Cette initiative marque une étape importante dans l’écosystème C++, en répondant aux critiques et en s’adaptant aux exigences de sécurité actuelles. Sean Baxter a déclaré que le projet permettrait aux développeurs C++ d'obtenir la sécurité mémoire de Rust, mais sans nécessiter l'apprentissage d'un nouveau langage.

« Safe C++ empêche les utilisateurs d'écrire du code non fiable. Cela inclut des fonctionnalités d'intelligence à la compilation telles que la vérification des emprunts pour éviter les bogues d'utilisation après libération et l'analyse d'initialisation pour la sécurité des types », a-t-il déclaré. Safe C++ permettrait une migration incrémentielle du code, car il ne s'applique qu'au code dans un contexte sécurisé. Le code non sécurisé existant fonctionnerait comme avant.

Abandon de Safe C++ et le choix des « Profils »

Lors de ses dernières discussions, le comité C++ a décidé de mettre la proposition Safe C++ de côté pour concentrer ses efforts sur une autre approche : les « Profils ». Imaginée par Bjarne Stroustrup, le créateur du C++, cette stratégie consiste à définir différents Profils de garanties (sécurité, performance, contraintes de compilation) que les développeurs pourraient appliquer selon leurs besoins, plutôt que d’imposer un modèle de sûreté unique.

« Le groupe de travail sur la sécurité et la sûreté a voté pour donner la priorité aux Profils plutôt qu'à Safe C++. Demandez aux responsables des Profils de vous tenir au courant. Safe C++ n'est pas poursuivi », a commenté Sean Baxter, auteur du compilateur Circle C++ de pointe, en juin de cette année.

Quelles sont les raisons du rejet du modèle Rust-like ? À en croire les discussions sur le sujet, le modèle inspiré de Rust imposait des contraintes jugées trop lourdes pour l’écosystème C++. L’idée d’annoter les fonctions comme sûres ou pures, avec l’obligation qu’elles n’appellent que d’autres fonctions elles-mêmes sûres, a été perçue comme trop radicale et difficilement compatible avec la base de code existante et l’évolution progressive du langage.

Incertitude quant à l'avenir du projet Safe C++

Bien que Sean Baxter affirme que le projet Safe C++ est abandonné, la question ne semble pas totalement trachée. Erich Keane, membre du comité C++ et coprésident du groupe de travail sur l'évolution du C++ (EWG), a déclaré que « la proposition de Sean Baxter a reçu un vote d'encouragement, environ la moitié (20/45) des personnes ayant encouragé le document de Sean Baxter, et 30/45 ayant encouragé le travail sur les Profils (avec 6 neutres) ».

Il semble donc que Sean Baxter soit invité à poursuivre ses efforts, et de nombreux membres du comité aimeraient le voir poursuivre ses efforts pour normaliser cette question ». En réponse, il a déclaré : « le modèle de sécurité inspiré de Rust n'est pas populaire auprès du comité. Poursuivre mes efforts ne changera rien à cela. Les Profils ont remporté le débat ».

Il a ajouté que les principes d'évolution du C++ adoptés par l'EWG incluent la déclaration suivante : « nous devrions éviter d'exiger une annotation de fonction sûre ou pure qui implique sémantiquement qu'une fonction sûre ou pure ne peut appeler que d'autres fonctions sûres ou pures ». Il s'agit là, selon lui, d'un « désaccord irréconciliable en matière de conception». La coloration des fonctions sûres est au cœur du modèle de sécurité inspiré de Rust.

Qu'est-ce que les « Profils » de Bjarne Stroustrup ?

Les Profils ont pour but de définir des modes de C++ qui imposent des contraintes sur la manière dont vous utilisez le langage et la bibliothèque, afin de garantir certaines propriétés de sécurité. Il s'agit principalement de contraintes au moment de la compilation, bien que dans la pratique, certaines vérifications puissent être mises en œuvre à l'aide de fonctionnalités de bibliothèque qui ajoutent une surcharge d'exécution limitée.


Au lieu d'introduire des constructions de langage entièrement nouvelles, les Profils limitent principalement les fonctionnalités et les utilisations existantes. L'idée est que vous pouvez activer un profil, et tout code qui l'utilise accepte de se conformer aux restrictions. Si vous ne l'activez pas, tout fonctionne comme avant. Il est donc rétrocompatible.

« Je pense que Safe C++ était plus ambitieux : introduction d'une nouvelle syntaxe, de qualificatifs de type, de contextes sûrs ou non sûrs, etc. Certains membres du comité ont estimé que c'était trop lourd, et les Profils sont considérés comme une voie plus pragmatique. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir », souligne l'ingénieur logiciel Simone Bellavia.

« À la lecture des commentaires ici et là, on constate une résistance visible au sein de la communauté à l'adoption du modèle Rust. Si vous voulez écrire comme Rust, écrivez simplement en Rust. Historiquement, le C++ est un langage qui a souvent emprunté des fonctionnalités à d'autres mondes et les a intégrées en lui-même. Dans ce cas, je pense que des sous-ensembles de sécurité du C++ existent déjà de manière informelle », a-t-il ajouté.

Controverses entourant les « Profils »

Pour ceux qui écrivent en Rust, Safe C++ présente de nombreuses similitudes avec Rust, parfois avec des ajustements pour s'adapter à la conception du C++. De plus, comme C++ dispose déjà d'une énorme base de « code non sécurisé », Safe C++ doit fournir des mécanismes permettant de mélanger le code sécurisé et non sécurisé, et de migrer progressivement. En ce sens, toutes les fonctionnalités sécurisées de Safe C++ sont facultatives.

Toutefois, Bjarne Stroustrup, préconise les Profils qui, selon lui, signifient : « je veux cet ensemble de garanties et elles seront alors appliquées ». Selon Bjarne Stroustrup, « ce qui est regrettable, c'est que le comité de normalisation s'est embrouillé et n'a pas garanti que cela serait inclus dans le C++ 26 ».

Cela dit, les Profils sont également controversés, certains se plaignant, par exemple, que « les Profils ne ressemblent à aucune solution établie qui fonctionne, n'ont pas d'implémentation et n'ont pas été intégrés à la norme C++ 26 au début de l'année, le comité ayant préféré demander un autre livre blanc à ce sujet ».

Sean Baxter ne pense pas que les Profils permettront d'atteindre cet objectif. « J'aurais mis en place des Profils s'ils avaient une chance de fonctionner », a-t-il déclaré. Il a ajouté que « toute la bibliothèque standard est dangereuse ». « J'ai proposé une std2 rigoureusement sécurisée, mais elle a été rejetée ».

La controverse autour de la manière de rendre le C++ plus sûr pourrait signifier qu'il vaut mieux se tourner vers un autre langage, qu'il s'agisse de Rust ou d'un autre langage tel que le projet expérimental Carbon de Google, dont la feuille de route indique qu'il pourrait proposer une version 1.0 du langage après 2028.

Conclusion

La proposition Safe C++ visait maintenir le langage C++ pertinent et compétitif face aux nouveaux langages de programmation. L'objectif était de monter que le C++ peut s’adapter et évoluer pour répondre aux besoins modernes de sécurité et de fiabilité des logiciels. Cependant, les personnes impliquées dans le développement du langage se sont mises sur la défensive et le comité des normes C++ a finalement opté pour les Profils comme alternative.

Les Profils semblent moins radicaux et plus faciles à adopter, un C++ plus sûr par défaut sans imposer le modèle Rust qui vise à s'attaquer aux pièges les plus courants du C++. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir.

En somme, le développement du sous-ensemble Safe C++ strict est mis en pause. L’effort se concentrera désormais sur les Profiles, une solution plus pragmatique, même si certains craignent qu’elle n’apporte pas un niveau de sécurité aussi élevé que celui promis par l’approche inspirée de Rust.

Sources : Safe C++, billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la proposition Safe C++ ?
Que pensez-vous des raisons potentielles de l'abandon de la proposition Safe C++ ?
Que pensez-vous des Profils, l'alternative proposée par le créateur du langage Bjarne Stroustrup ?
Selon vous, quelle approche contribuerait à rendre le C++ plus adapté aux besoins modernes de sécurité et de fiabilité des logiciels ?

Voir aussi

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté veut répondre aux défis modernes de la sécurité des logiciels dans un contexte où plusieurs recommandent de le remplacer par des alternatives

C++ sous stéroïdes : Bjarne Stroustrup présente des « profils » renforcés par des lignes directrices pour la sécurité des ressources et des types afin de garantir que le code est contemporain et sûr

Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google