IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mars 2017
    Messages
    1 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2017
    Messages : 1 177
    Points : 78 774
    Points
    78 774
    Par défaut Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles
    Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles
    Mais peu de développeurs s’en soucieraient

    Un bogue affecte les iPhone, un autre touche Windows et un troisième affecte les serveurs tournant sous Linux. À première vue, ces bogues n’ont rien en commun puisqu’ils concernent des plateformes différentes : Android, iOS, macOS, Windows, Linux. La réalité serait cependant toute autre à en croire Alex Gaynor, ingénieur en sécurité logicielle chez Mozilla précédemment en poste chez USDS (United States Digital Service).

    Lors de la troisième édition du « Weakest Link », le rendez-vous annuel organisé par Motherboard Vice sur le thème de l’avenir du piratage informatique et de la cybersécurité, Alex Gaynor a évoqué un problème sérieux qui, selon lui, menacerait Internet, mais qui semble paradoxalement laisser les développeurs complètement indifférents.

    Gaynor a expliqué que les trois bogues évoqués précédemment existent parce que les logiciels qu’ils affectent sur les différentes plateformes ont été codés avec des langages de programmation qui ont la fâcheuse tendance de favoriser la survenue d’erreurs de type « memory unsafety », en autorisant l’accès aux régions invalides de la mémoire. Cette catégorie d’erreurs peut causer des bogues et des vulnérabilités de sécurité lors des procédures d’accès en mémoire.

    En autorisant la survenue d’erreurs de type « memory unsafety », des langages de programmation tels que C et C++ auraient ainsi contribué à la dissémination d’un flux presque sans fin de failles de sécurité critiques pendant de nombreuses années. Comme exemple de ces vulnérabilités, on peut citer : les confusions de type, le dépassement de tampon, le dépassement de capacité d’entier et la vulnérabilité « use after free ».

    Les confusions de type peuvent survenir lorsqu’une portion de code ne vérifie pas le type d’objet qui lui est passé et l’utilise à l’aveuglette. Ce genre de situation peut s’avérer dangereuse dans la mesure où un type est exprimé comme une disposition dans l’implémentation de bas niveau d’un logiciel. De plus, avec les confusions de type, les mauvais pointeurs sur les fonctions ou les mauvaises données sont assignés à la mauvaise portion du code, ce qui peut dans certains cas conduire à une exécution du code.

    Le dépassement de tampon (ou buffer overflow en anglais) est une faille de sécurité critique qui se produit lorsque l’utilisateur entre une chaine de caractères qui va se retrouver dans un tableau de caractères de taille insuffisante. Cela entraine l’écriture de données en dehors de la zone mémoire allouée pour le tableau. L’exploit HeartBleed, par exemple, qui a eu un impact sur 17 % des serveurs Web sécurisés sur Internet, était une vulnérabilité de dépassement de tampon permettant de lire 60 Ko après la fin d’une liste, y compris les mots de passe et autres données des utilisateurs.

    Le dépassement de capacité d’entier, une faille difficile à détecter qui utilise le fait que les nombres ne peuvent dépasser une certaine valeur qui dépend du nombre de bits utilisés pour leur représentation et de leur méthode de codage.

    La vulnérabilité « use after free » se présente, en général, dans le cas où on utilise un pointeur ou des données en mémoire, alors que le pointeur (ou le bloc mémoire) a déjà été libéré.

    Nom : ghj.png
Affichages : 45884
Taille : 336,4 Ko

    Ensemble, ces vulnérabilités représenteraient les exploits les plus fréquemment rencontrés dans des logiciels populaires tels que Firefox, Chrome, Windows, Android ou encore iOS. Gaynor en dénombre déjà au moins 400 et affirme : « Je suis les avis de sécurité pour ces projets depuis plus d’un an et, dans presque toutes les versions de ces produits, plus de la moitié des vulnérabilités sont de type memory unsafety. Plus troublant encore, les vulnérabilités sévères et critiques […] sont presque toujours de type memory unsafety ».

    Malgré les risques importants liés à la sécurité qu’ils font planer en permanence sur les logiciels qu’ils soutiennent, les langages de programmation « memory unsafety friendly » comme le C ou le C++ ont toujours la côte auprès des développeurs, alors que des alternatives éprouvées telles que Rust, Swift, pouvant être considérées comme des langages « memory safe » semblent à la traine.

    Cette situation serait peut-être due au fait que, dans le cadre d’un nouveau projet, les développeurs ont tendance à opter pour un langage de programmation en fonction des langages que leur équipe connait, des performances et de l’écosystème de bibliothèques qui peuvent découler de ce choix. Le volet sécurité qu’implique ce choix n’est presque jamais considéré, ou du moins pas suffisamment, lors de la prise de décision estime Gaynor.

    De plus, la plupart des projets logiciels, même les plus importants pour la sécurité d’Internet, ne sont pas nouveaux. Ils ont été lancés il y a une décennie ou plus. Linux, OpenSSL et le serveur Web Apache par exemple ont tous plus de vingt ans. Pour des projets d’envergure comme ceux-ci, réécrire tout le code dans un nouveau langage n’est pas une option. Ils ont besoin d’être transférés progressivement, ce qui implique que les projets devront être écrits et maintenus dans deux langages différents au lieu d’un seul. Cela suppose également qu’il faudra former une grosse équipe, ce qui prend beaucoup de temps et nécessite plus de moyens.

    Le plus gros problème serait enfin lié au fait que beaucoup de développeurs ne croient pas du tout qu’il y a un problème. Ils ne croient pas que les langages comme C ou C++ facilitent ces vulnérabilités, mais que ce sont simplement d’autres ingénieurs qui écrivent du code bogué. Ils ne pensent pas qu’il y aurait un quelconque problème avec ces langages prétendument « memory unsafety friendly », car aucun code n’est parfait, mais simplement des personnes qui ne savent pas correctement les utiliser.

    Source : Motherboard Vice

    Et vous ?

    Qu’en pensez-vous ?

    Quel est ou quels sont vos langages de prédilection ?

    Partagez-vous la théorie des langages « memory unsafety friendly » comme C ou C++ mise en avant dans cet article ? Expliquez votre point de vue.

    Êtes-vous d’accord avec Gaynor lorsqu’il déclare que le volet sécurité est trop souvent négligé au moment du choix d’un langage ?

    Voir aussi

    Les pièges du C
    Google publie des détails sur une faille non corrigée d'IE et Microsoft Edge qui a été signalée en fin novembre
    C2 : un langage qui se présente comme une évolution de C plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements
    Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    498
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 498
    Points : 1 148
    Points
    1 148
    Par défaut
    Je pense c'est juste penible de reinventer la roue. Refaire tout en Rust. Sans compter que les developpeurs avec les capacites pour developper ce genre d'appalication est rare de nos jours.
    Gerer un projet Open Source demande beaucoup de volonte.

  3. #3
    Membre du Club
    Inscrit en
    Novembre 2012
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : Novembre 2012
    Messages : 23
    Points : 43
    Points
    43
    Par défaut
    "des alternatives éprouvées telles que Rust, Swift, pouvant être considérées comme des langages « memory safe » semblent à la traine"

    Je trouve que Rust se développe très bien : de plus en plus de cas usuels se retrouvent pris en charge par des libraries de plus en plus matures, je vois plus d'offres d'emploi passer, Rust est toujours le language le plus apprécié par ses adeptes selon StackOverflow, etc. Pour sûr l'écosystème pourrait connaitre une croissance plus rapide, mais c'est toujours le cas avec n'importe quelle technologie.

    Je me demande quels arguments ont forgé cette opinion d'un lagnuage "à la traine".

  4. #4
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Non mais c'est un mystère pour personne en fait. Tous les acteurs du domaine le savent depuis genre 30 ou 40 ans.

    Cependant, il faut déjà bien comprendre qu'on n'utilise pas ces langages dans les domaines en question parce que c'est les meilleurs, mais parce que ça a été les seuls capables d'amener au niveau de performances requis pendant des dizaines d'années (et on choisit très souvent de privilégier les performances à la fiabilité quand on veut vendre à un très grand nombre). Donc à la question "pourquoi Swift ou Rust mettent 'du temps' à décoller ?". Ils mettent pas du temps, ils viennent d'apparaître, on va pas transformer des milliards de lignes de code du C à C++ en deux coups de cuillère à pot, et c'est pas le tout que le langage existe, il faut former les gens aussi, ça va pas se faire en deux jours.

    Ensuite, il vient la question d'assurer la fiabilité. Il est clairement possible d'assurer des niveaux de fiabilité très élevés sur des langages comme C et C++. C'est fait depuis des années dans le ferroviaire, l'aviation, l'armement, seulement il faut y mettre les moyens. Et rien ne dit qu'on atteindrait le même niveau facilement avec d'autres langages comme Rust. Je crois personnellement que c'est possible, effectivement, mais l'outillage d'un langage comme Rust est encore, dû à sa jeunesse, encore très loin des outils qui sont aujourd'hui disponibles pour C ou C++. Et vous faites confiance au compilateur Rust ? Moi pas. Mais pour C, il existe des choses du niveau de CompCert (et s'il y a des travaux préliminaires pour Rust, on en est encore très loin). Alors on prend quoi ? Un langage pour lequel j'ai pas d'outil avancé de vérification et un compilateur qui n'est pas sûr ? Ou un langage pour lequel j'ai des outils ultra avancé de vérification et un compilateur certifié par preuve formelle ?

    Finalement, il faut pas oublier qu'il reste encore une option qui n'exclut pas des langages comme C. La génération de code correct par construction. Comme on peut le faire à partir de Lustre ou de langages comme Low-Star (basé sur F-Star). Je veux faire une lib de sécu, je fais quoi ? Je code en Rust sans aucune garantie que mon code est conforme à la spécification ? Où je l'écris en F-Star, je le prouve, je génère le C de manière certifiée et je le compile avec CompCert ? (Coucou HACL* !).

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mars 2011
    Messages : 183
    Points : 715
    Points
    715
    Par défaut
    Si des langages interprété sont exempte de ces problèmes, c'est qu'il est possible d'en faire autant en C ou C++ moyennement quelques lignes de codes/Directive préprocesseur.

    Si le C/C++ à de bonne performance, c'est parce que justement il ne vérifie pas si on va faire un buffer overflow, « use after free », ou la vérification de type. C'est au développeur de s'assurer qu'il y'en as pas, en rajoutant des instructions de vérification.

    Utiliser Python ou Java comme indiquée dans l'article est une solution, qui préfèrent la sécurité au performance.

    Pour ce qui est de Rust et Swift, je ne les connait que de noms. Mais si ils ont trouvée des solutions, c'est soit, la syntaxe du langage qui empêche ces problèmes, soit des instructions processeur supplémentaire qui alourdissement l’exécution.

  6. #6
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par e101mk2 Voir le message
    Pour ce qui est de Rust et Swift, je ne les connait que de noms. Mais si ils ont trouvée des solutions, c'est soit, la syntaxe du langage qui empêche ces problèmes, soit des instructions processeur supplémentaire qui alourdissement l’exécution.
    Ce n'est pas syntaxique, c'est sémantique. Rust repose sur des "linear-types" (pour ceux qui veulent jeter un oeil à la partie théorique), pour garantir l'absence de runtime errors liées à la mémoire statiquement et permettre la libération automatique de mémoire sans GC, et de manière déterministe (et par comptage de référence si le développeur ne sait pas comment faire mieux). Il s'ajoute aussi à cela du contrôle automatique de bornes qui (en fait) dans la très vaste majorité des cas (pour ne pas dire tout le temps) peut être automatiquement virée par le compilateur. En gros, si un contrôle est laissé par le compilateur, ça veut très probablement dire que le développeur est de toute façon en train de faire une connerie.

    Et c'est pour ça que ce serait intéressant d'avoir des analyseurs sémantiques encore plus puissants (du niveau de ce qu'on sait faire en C) pour Rust (interprétation abstraite par exemple), ça pourrait permettre de transmettre des hypothèses supplémentaires au compilateur pour virer encore plus de choses.

  7. #7
    Membre émérite Avatar de onilink_
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    597
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : Juillet 2010
    Messages : 597
    Points : 2 439
    Points
    2 439
    Par défaut
    Citation Envoyé par KsassPeuk Voir le message
    Finalement, il faut pas oublier qu'il reste encore une option qui n'exclut pas des langages comme C. La génération de code correct par construction. Comme on peut le faire à partir de Lustre ou de langages comme Low-Star (basé sur F-Star). Je veux faire une lib de sécu, je fais quoi ? Je code en Rust sans aucune garantie que mon code est conforme à la spécification ? Où je l'écris en F-Star, je le prouve, je génère le C de manière certifiée et je le compile avec CompCert ? (Coucou HACL* !).
    Intéressant, je ne connaissais pas F-Star. Reste a voir si ce n'est pas trop compliqué à utiliser.

    Citation Envoyé par e101mk2 Voir le message
    Si le C/C++ à de bonne performance, c'est parce que justement il ne vérifie pas si on va faire un buffer overflow, « use after free », ou la vérification de type. C'est au développeur de s'assurer qu'il y'en as pas, en rajoutant des instructions de vérification.
    [...]
    Pour ce qui est de Rust et Swift, je ne les connait que de noms. Mais si ils ont trouvée des solutions, c'est soit, la syntaxe du langage qui empêche ces problèmes, soit des instructions processeur supplémentaire qui alourdissement l’exécution.
    En fait Rust est juste beaucoup mieux pensé que le C++ ou d'autres langages, pour la sécurité. Pour le comprendre il faut au moins lire un peu de documentation.
    Le langage est beaucoup plus strict sur plein de niveaux, et il n'a effectivement pas peur de faire quelques concessions sur les performances (comme le bound checking), mais tout cela de manière intelligente (ainsi, si on code correctement il n'y aura que très peu de perte de performances, car le compilateur pourra supprimer pas mal de "checks").

    Par contre, je le trouve difficile à apprendre. Certains disent que le C++ est difficile... il n'ont pas vu Rust
    C'est un peu comme quand on tente d'apprendre Vulkan et que les premières lignes indiquent "contrairement a une API haut niveau comme OpenGL [...]"
    Circuits intégrés mis à nu: https://twitter.com/TICS_Game

  8. #8
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par onilink_ Voir le message
    Intéressant, je ne connaissais pas F-Star. Reste a voir si ce n'est pas trop compliqué à utiliser.
    Le but en soi avec ce langage c'est de produire des programmes qui pourraient (sur le papier, pas encore officiellement je pense) être certifié CC-EAL7. Donc, il faut pas d'attendre à un truc facile. Mais c'est plutôt à utiliser pour des composants ultra-critiques (et c'est, au fond, pas plus dur qu'atteindre le même niveau de fiabilité sur du C : ce serait même plus facile, c'est fait pour). Ça reste un langage avec des types dépendants et de la preuve formelle, donc des coûts de développement élevés et des utilisateurs qui ont besoin d'un bon niveau en maths.

  9. #9
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par onilink_ Voir le message
    Par contre, je le trouve difficile à apprendre. Certains disent que le C++ est difficile... il n'ont pas vu Rust
    Je ne connais pas encore Rust aussi bien que C++ mais, après avoir lu en entier la 2e édition de The Rust Programming Language (qui est une introduction au langage), je n'ai pas eu l'impression qu'il était plus compliqué que C++. Au contraire, je pense encore que C++ est probablement plus compliqué que Rust.

    Cependant, j'avais déjà étudié Haskell avant de me pencher sur Rust. Du coup, dans Rust, je n'ai pas été déstabilisé par les traits (qui sont similaires aux type classes de Haskell) et j'étais déjà habitué à certaines fonctionnalités comme le pattern matching.

    Rust est plus éloigné de Java que ne l'est C++, surtout si on privilégie la programmation orientée objet quand on programme en C++.

  10. #10
    Membre émérite Avatar de onilink_
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    597
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : Juillet 2010
    Messages : 597
    Points : 2 439
    Points
    2 439
    Par défaut
    @KsassPeuk
    Je vois, merci pour les infos

    Citation Envoyé par Pyramidev Voir le message
    Je ne connais pas encore Rust aussi bien que C++ mais, après avoir lu en entier la 2e édition de The Rust Programming Language (qui est une introduction au langage), je n'ai pas eu l'impression qu'il était plus compliqué que C++. Au contraire, je pense encore que C++ est probablement plus compliqué que Rust.

    Cependant, j'avais déjà étudié Haskell avant de me pencher sur Rust. Du coup, dans Rust, je n'ai pas été déstabilisé par les traits (qui sont similaires aux type classes de Haskell) et j'étais déjà habitué à certaines fonctionnalités comme le pattern matching.

    Rust est plus éloigné de Java que ne l'est C++, surtout si on privilégie la programmation orientée objet quand on programme en C++.
    Peut être que je vois les choses plus difficiles car j'ai juste lu la documentation, et que je n'ai jamais fait beaucoup de fonctionnel, mais je trouve C++ assez simple s'il est appris correctement (donc déjà, pas en commençant par C, pas en apprenant C++98 ...), surtout si on se limite à une utilisation standard sans trop approfondir.
    C'est sûrement aussi le cas de Rust.

    Mais Rust il y a beaucoup de règles à connaître, et pas forcement des choses intuitives, comme les références et le borrowing.
    On ne sait pas trop par ou commencer quand on veut écrire son "premier vrai programme".

    Après c'est peut être tout simplement mon gros bagage C++ qui fait que je vais forcement toujours vouloir "penser C++"/impératif dans un autre langage (ce qui est plus un frein qu'autre chose pour apprendre un langage tel que Rust).

    En tout cas, même si je ne compte pas changer de langage de ci tôt, Rust donne vraiment envie.
    Il a l'air d'être pensé de manière très intelligente, et même s'il semble assez difficile d'utilisation (au premier abord), ça fait du bien de voir des langages "modernes" qui privilégient la sécurité et les performances plutôt que le côté facile d'utilisation (qui présuppose toujours que les dev sont des idiots).
    Circuits intégrés mis à nu: https://twitter.com/TICS_Game

  11. #11
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Rust est plus éloigné de Java que ne l'est C++, surtout si on privilégie la programmation orientée objet quand on programme en C++.
    Oui. Rust est plus un langage fonctionnel qu'objet donc forcément.

    Concernant l'article, s'il a raison sur le fond, il est quand même un peu biaisé. Déjà dans les années 90, on ne risquait pas de coder en Rust ou en Swift... Ensuite C++ a beaucoup évolué donc il ne faudrait pas non plus comparer le Rust de 2018 avec le C++ de 98. Enfin Rust est poussé par Mozilla, donc l'avis d'un ingé de Mozilla n'est pas forcément des plus objectifs.

  12. #12
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    La solution de changer de langage n'est pas valable, celui ci entrainera d'autres failles.

    Pourquoi ne pas adapter C/C++ tout simplement!
    Certe c'est fastudieux mais ces langages sont supportés...
    Si la réponse vous a aidé, pensez à cliquer sur +1

  13. #13
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par hotcryx Voir le message
    Pourquoi ne pas adapter C/C++ tout simplement!
    À mon avis, cela n'arrivera pas. Un borrow checker serait trop lourd à intégrer au C++.
    Face à la complexification croissante du C++, on a régulièrement le slogan Remember the Vasa! qui dit, en gros, qu'il ne faut complexifier le C++ qu'avec parcimonie.

  14. #14
    Membre à l'essai
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 7
    Points : 10
    Points
    10
    Par défaut
    concernant la sécurité, si le C et C++ sont utilisées, il n'y as pas le choix, il faut monter en puissance, (projet de type aéronautique, ferroviaire, nucléaire, ..)
    ensuite il faut un os certifie EAL avec le critère commun. il n'y as point de salue en dehors de méthode, de maitrise du compilateur et la validation applicative.
    sinon il faut des langages typé forte. il en existe, mais certain sont désuet (pas obsolète mais trop peu l'utilisent, ADA 2012
    il n'y as pas de recette miracle, et la montée en cybersécurité vont sans aucun doute amener à renforcer les outils, la vérifications , les tests, mais aussi les règles de codages.

  15. #15
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par hotcryx Voir le message
    Pourquoi ne pas adapter C/C++ tout simplement!
    Ce serait déjà bien d'utiliser les fonctionnalités "modernes" du C++ : pointeurs intelligents, itérateurs, move semantic...

  16. #16
    Membre expérimenté

    Homme Profil pro
    Retraite
    Inscrit en
    Octobre 2005
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraite
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2005
    Messages : 477
    Points : 1 333
    Points
    1 333
    Billets dans le blog
    1
    Par défaut le Rust oui mais quand au C/C++
    Bonjour, je code en c++2018 gcc8.2 avec les options mise en place la compilation détecte beaucoup d'erreur qui passaient il y a plusieurs années.
    pour ma part.
    j'ai essayé Rust effectivement il parait plus simple , mais quand je prend par exemple sans tomber avec les packages.... mais simplement de base j'essaye de faire un projet simple pas hello word , ben j'ai du mal alors peut-être suis je idiot mais ... projet console complexe avec arbre btree (traitement simple d'index pour fichier a plat ) appel de programme tel execv msgsnd ... ben j'arrive pas (alors que la même chose en C/C++ ça tourne) bref ce n'est pas un jugement, alors biens-sur il y a les packages, mais là je voulais sentir le langage l’appréhender j'ai beaucoup buter sur la doc et sur comment prendre le file et tirer pour penser Rust....
    dans les exemples qui sont bien fait (dès fois ne sont pas ajour avec la version proposer) on ne montre pas un projet de bout en bout avec par exemple fichier client commande facturation avec des programmes qui s'appelle communique ect.... je pense que tout ça c'est une lacune peut-être dut a sa jeunesse pas une faute de jeunesse mais cela montre qu'il faut du temps pour mettre en place et offrir quelque chose qui tiens la route.

    le c/c++ avec la doc et les forums sont très réactif et il est rare de ne pas trouvé sont bonheur de plus le C++ a vraiment fait un bond prodigieux , mais il est vrais que l’investigation pour la mémoire n'est pas facile moi même j'ai encore ... c'est pour cela que je me conforme a une logique très dur quitte à écrire un peu plus de lignes de code et les tests ...

  17. #17
    Membre confirmé
    Homme Profil pro
    Développeur multiplateformes
    Inscrit en
    Mars 2003
    Messages
    273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur multiplateformes
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2003
    Messages : 273
    Points : 628
    Points
    628
    Par défaut
    Citation Envoyé par JPLAROCHE Voir le message
    le c/c++ avec la doc et les forums sont très réactif et il est rare de ne pas trouvé sont bonheur de plus le C++ a vraiment fait un bond prodigieux , mais il est vrais que l’investigation pour la mémoire n'est pas facile moi même j'ai encore ... c'est pour cela que je me conforme a une logique très dur quitte à écrire un peu plus de lignes de code et les tests ...
    Oui - C++ est maintenant bien équipé depuis C++11 et 17.
    Il est beaucoup moins coûteux d'apprendre à utiliser ces nouvelles spécifiés plutôt que de tout réécrire dans un autre langage, sauf si il a d'autres considérations à prendre en compte.

  18. #18
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    498
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 498
    Points : 1 148
    Points
    1 148
    Par défaut
    Je ne comprends pas les gars, vous parler tous du language en lui-meme, vous pouvez le faire en assembleur, cela change rien a la maintenance.
    Le sujet est qui a le temps pour coordonner tous ces projets. Je ne me rappelle plus comment marche le C++. Sans compter que Linux c'est pas un petit projet, c'est OS entier dont le code maintenu par des milliers d'utilisateur.

    C'est la motivation qui manque, la connaissance aussi. De ce que je vois ici, il y a tres de peu developpeur Rust, GO, et patati.

  19. #19
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par hotcryx Voir le message
    La solution de changer de langage n'est pas valable, celui ci entrainera d'autres failles.
    Pas nécessairement justement. Quand tu as un système de types qui est designé à la base pour éviter les problèmes, il n'y aura pas d'autres failles. Ça ne veut pas dire qu'il est impossible qu'il y en ait. Mais si tu conçois ton langage avec cette idée en tête dès le début, tu limites beaucoup plus fortement les possibilités (par exemple pour Rust, il y a déjà de très bonnes raisons de penser que ce qu'ils avancent en terme de sécurité soit vrai : https://plv.mpi-sws.org/rustbelt/popl18/paper.pdf). D'autre part, en repartant d'un design beaucoup plus simple, tu augmentes tes chances de voir arriver un jour une version formellement prouvée du bousin. Ce qui est juste hors de portée pour C++ par exemple.

    Citation Envoyé par hotcryx Voir le message
    Pourquoi ne pas adapter C/C++ tout simplement!
    Certe c'est fastudieux mais ces langages sont supportés...
    C'est pas fastidieux. Pour C, c'est simplement impossible parce qu'il n'y a rien dans le système de base qui permette d'obtenir quelque chose de semblable, donc en fait ça reviendrait à en faire un autre langage. Pour C++, c'est impossible dans un délai raisonnable et en plus, contrairement à tout autre langage conçu avec une optique de sécurité à la base, ça ne permettrait d'obtenir aucune garantie puisque tout le reste du langage doit rester supportée.

    Et ça n'enlèverait absolument en rien le fait que tout le reste de ces deux langages est bourré d'incohérence et de contradiction. Pour C, on a un compilateur certifié (qui a dû renforcer certaines choses de la norme sinon c'était impossible), on sait vérifier que du code est exempt de runtime-errors, sauf que c'est très coûteux. Pour C++, le compilateur certifié, ça impliquerait d'avoir du monde pour spécifier mathématiquement une norme de 1400 pages (on est bien parti), dont certaines parties sont déjà très mal définies en anglais, et qui continue à croître à une vitesse folle.

    Bref, il y a des limites à l'adaptation, principalement fixées par la manière dont le langage a été pensé à la base.

    Pour ce qui est du support, il y a déjà des PoC de compilateurs Rust -> C par exemple. Ce qui fait qu'on peut virtuellement compiler du Rust vers n'importe quoi.

    Citation Envoyé par JPLAROCHE Voir le message
    Bonjour, je code en c++2018 gcc8.2 avec les options mise en place la compilation détecte beaucoup d'erreur qui passaient il y a plusieurs années.
    C'est vrai, mais malheureusement, c'est complètement insuffisant pour garantir des propriétés de sécurité, même simplistes comme des accès mémoire. Et une base de test ne sera jamais suffisante pour garantir la sécurité sur des parties vraiment critiques des systèmes qu'on utilise en permanence (systèmes d'exploitation, protocoles de communication, ...). Et ça c'est sans parler des propriétés fonctionnelles pour lesquels Rust, ou Swift, ou Go, ne sont absolument pas équipés. On a des outils pour C par contre (ou autres langages du genre), et il serait intéressant de les adapter à des langages comme Rust, parce qu'on pourrait prouver des propriétés compliquées tellement plus facilement qu'en C ! (Et il y a aussi des options comme ce que j'ai mis plus haut à propos de génération depuis des langages très haut niveau).

  20. #20
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par KsassPeuk Voir le message
    Pour C++, le compilateur certifié, ça impliquerait d'avoir du monde pour spécifier mathématiquement une norme de 1400 pages (on est bien parti), dont certaines parties sont déjà très mal définies en anglais, et qui continue à croître à une vitesse folle.
    Le nombre de pages a augmenté en C++17. Par contre, pour C++20 (pas encore fini), c'est à nuancer.

    N3337 (C++11 draft) fait 1 324 pages.
    N4140 (C++14 final draft) fait 1 365 pages.
    N4659 (C++17 final draft) fait 1 622 pages.

    Ensuite, en regardant ici :
    N4687 fait 1 647 pages. Donc ça a un tout petit peu monté.
    N4700 fait 1 416 pages. Je n'ai pas analysé comment ils se sont débrouillés pour réduire le nombre de pages.
    Ensuite, le nombre de pages a de nouveau augmenté. N4778 fait 1 580 pages.

Discussions similaires

  1. problème installation à cause d'excel (référence)
    Par greg26 dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 17/09/2007, 10h14
  2. problème sérieux avec le DOM.
    Par g0up1l dans le forum Hibernate
    Réponses: 4
    Dernier message: 19/06/2007, 02h55
  3. Problème sérieux open_basedir sur un serveur virtuel
    Par microcongo dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 1
    Dernier message: 14/01/2007, 19h49
  4. [FLASH MX2004] Problème loading à cause du son
    Par zzman dans le forum Flash
    Réponses: 2
    Dernier message: 30/03/2006, 22h14
  5. Problème sérieux au démarrage
    Par onyouma dans le forum Windows XP
    Réponses: 1
    Dernier message: 27/02/2006, 12h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo