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. #121
    Expert éminent sénior
    Avatar de Escapetiger
    Homme Profil pro
    Administrateur système Unix - Linux
    Inscrit en
    Juillet 2012
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Administrateur système Unix - Linux

    Informations forums :
    Inscription : Juillet 2012
    Messages : 1 473
    Points : 11 035
    Points
    11 035
    Par défaut
    [Intermède *]

    Citation Envoyé par commandantFred Voir le message
    (.../..). Néanmoins je vous invite à la tester sur vos compilateurs, vous verrez que ça fonctionne très bien. Je pense qu'on peut même supprimer les espaces et écrire : maj = i+++++i;
    Histoire d'obfusquer un peu plus.

    Le résultat sera le même
    D'après Wikipedia, digne de la syntaxe du langage Brainfuck

    ps
    Je ne sais pas si ledit langage (enfin son compilateur) gère les UB (Undefined Behaviour)

    [/Intermède *]

    * cf. CNRTL (Centre National de Ressources Textuelles et Lexicales)
    « Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
    Club des professionnels en informatique

  2. #122
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 214
    Points : 10 136
    Points
    10 136
    Par défaut
    Citation Envoyé par commandantFred Voir le message
    Le problème est que la pile du C est la même que la pile système. Son pointeur est stocké dans le registre SP (stack pointer)
    Or, toutes les variables locales d'une fonction C sont stockées dans la pile.

    Dès lors, il n'y a pas 36 solutions. Si c'est trop volumineux pour la pile (je n'entre pas dans le détail de pourquoi la taille de pile C est limitée), il faut faire des malloc(...).
    Qu'appelle tu pile systeme ?
    Celle de l'OS ?
    Parce que la pile de ton exécutable et celle de l'OS (et des autres applications) , sont pas dans les mêmes adresses mémoires.

    Sinon non en C la taille de la pile est "infini", c'est juste l'OS qui le limite, en embarqué la pile c'est la taille de la RAM - (text/bss/data/heap).
    Mais le C ne définis pas une taille précise de la pile, elle peut faire quelque Ko comme plusieurs Mo ,techniquement rien n’empêcherai d'avoir une pile de 1Go (mais l'interet serait bien limité).

  3. #123
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    Citation Envoyé par Kannagi Voir le message
    Qu'appelle tu pile systeme ?
    Celle de l'OS ?
    Parce que la pile de ton exécutable et celle de l'OS (et des autres applications) , sont pas dans les mêmes adresses mémoires.

    Sinon non en C la taille de la pile est "infini", c'est juste l'OS qui le limite, en embarqué la pile c'est la taille de la RAM - (text/bss/data/heap).
    Mais le C ne définis pas une taille précise de la pile, elle peut faire quelque Ko comme plusieurs Mo ,techniquement rien n’empêcherai d'avoir une pile de 1Go (mais l'interet serait bien limité).
    Damn, trois trucs faux ou à côté en trois phrases. Je pensais que vous étiez en vacances. Vous êtes sûr de vouloir à tout prix intervenir sur ce topic ?

    Le sujet de mon post n'est pas la pile ni les segments mémoire un exécutable C. Le sujet ici, c'est les vulnérabilités logicielles. Ca peut être un peu pointu et la plupart du temps, c'est non-documenté. Merci de trouver un topic approprié pour les autres sujets.

  4. #124
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 214
    Points : 10 136
    Points
    10 136
    Par défaut
    Citation Envoyé par commandantFred Voir le message
    Damn, trois trucs faux ou à côté en trois phrases. Je pensais que vous étiez en vacances. Vous êtes sûr de vouloir à tout prix intervenir sur ce topic ?
    Ouaw cela veut dire que pendant mes 15 ans de pratique bas niveau, j'ai rien compris !

    Si c'est le cas n'hésitez pas à me rectifier, mais pour le moment je constate que vous dites des choses souvent fausse
    Ou alors vos phrases ne sont pas clair et vous devriez plus les expliquer.

  5. #125
    Membre régulier

    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2023
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Octobre 2023
    Messages : 37
    Points : 77
    Points
    77
    Par défaut
    Je trouve exagéré de déplacer des problèmes liés aux réseaux et à internet sur le langage C et C++. La NSA s'imagine qu'en changeant pour du Rust tout s'améliore. En fait ces problèmes de mémoire dépendent des développeurs. Et ensuite ce qui est amusant c'est que les défauts sont ciblés sur le C et le C++ mais pas les autres langages. Le C++ offre un code sur pour qui dispose d'une acuité normale. Le C est plus difficile à maîtriser mais on y arrive cela prend plus de temps . J'ai écrit entre autres en C et C++ une application qui sert des services statistiques dans un tableur. Tout le code correspondant aux traitements et aux calculs comporte une multitude d'allocations mémoire et une fois mis au point et testé avec Linux ne présente aucune anomalie. Les zones allouées sont correctement initialisées, il n'y a aucune erreur d'écriture dans des zones tampons, il n'y aucune erreur de fuite mémoire. C'est évident que c'est plus lent à mettre en oeuvre en C qu'en C++. Bref ce code volumineux testé sans erreur de manière autonome a été injecté dans une application graphique de type Qt et GTK et wxWidgets et là lors du test de l'application c'est la cata , des erreurs qui fusent de partout MAIS qui ne viennent pas du module injecté MAIS de ces environnements graphiques . Alors j'image qu'une fois en réseau sur internet les risques sont décuplées mais ne viennent pas du langage mais du contexte dans lequel on manipule le langage. Rust ne fait qu'avancer une rustine sur un problème qui est plus vaste lié la sécurité des réseaux et le développement Web.

  6. #126
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 684
    Points
    684
    Par défaut
    Citation Envoyé par djm44 Voir le message
    Je trouve exagéré de déplacer des problèmes liés aux réseaux et à internet sur le langage C et C++. La NSA s'imagine qu'en changeant pour du Rust tout s'améliore. En fait ces problèmes de mémoire dépendent des développeurs. Et ensuite ce qui est amusant c'est que les défauts sont ciblés sur le C et le C++ mais pas les autres langages. Le C++ offre un code sur pour qui dispose d'une acuité normale. Le C est plus difficile à maîtriser mais on y arrive cela prend plus de temps.
    Rien qui va dans ton message. C'est pas que des problèmes de réseaux et d'internet. C'est pas la NSA. Il y a des milliers (littéralement) de vulnérabilités reportées chaque année (dont une grosse partie liées à la mémoire). Le problème n'est pas juste lié à un manque "d'acuité" des devs.

    Citation Envoyé par djm44 Voir le message
    J'ai écrit entre autres en C et C++ une application qui sert des services statistiques dans un tableur. Tout le code correspondant aux traitements et aux calculs comporte une multitude d'allocations mémoire et une fois mis au point et testé avec Linux ne présente aucune anomalie. Les zones allouées sont correctement initialisées, il n'y a aucune erreur d'écriture dans des zones tampons, il n'y aucune erreur de fuite mémoire. C'est évident que c'est plus lent à mettre en oeuvre en C qu'en C++. Bref ce code volumineux testé sans erreur de manière autonome a été injecté dans une application graphique de type Qt et GTK et wxWidgets et là lors du test de l'application c'est la cata , des erreurs qui fusent de partout MAIS qui ne viennent pas du module injecté MAIS de ces environnements graphiques . Alors j'image qu'une fois en réseau sur internet les risques sont décuplées mais ne viennent pas du langage mais du contexte dans lequel on manipule le langage. Rust ne fait qu'avancer une rustine sur un problème qui est plus vaste lié la sécurité des réseaux et le développement Web.
    Tu ne serais pas le premier qui n'a aucun problème lorsqu'il travaille sur du code non critique, et qui se prend un grosse claque lorsque son code essaie de passer une validation un peu sérieuse.

    A part peut être dans les domaines critiques, n'importe qui qui me dit qu'une app un peu sérieuse (pas les petits outils internes de quelques milliers de LOC) à 0 bugs, je lui dis que c'est parce que son app n'est pas assez testée.

  7. #127
    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 djm44 Voir le message
    Tout le code correspondant aux traitements et aux calculs comporte une multitude d'allocations mémoire et une fois mis au point et testé avec Linux ne présente aucune anomalie. Les zones allouées sont correctement initialisées, il n'y a aucune erreur d'écriture dans des zones tampons, il n'y aucune erreur de fuite mémoire. C'est évident que c'est plus lent à mettre en oeuvre en C qu'en C++.
    On va citer un grand de ce monde:

    Program testing can be used to show the presence of bugs, but never to show their absence!
    Edsger W. Dijkstra
    Qu'est ce qui vous garantit que vos affirmations sont vraies ?

  8. #128
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    Dijkstra est effectivement un algorithme très puissant et astucieux qui s'adapte à la topologie de la data qu'il traite.
    Néanmoins, je n'en dirais pas autant de sa citation.

    Evidemment qu'on teste l'absence de bug !

    Les simulations sont parfois aussi coûteuses que le développement en lui-même. Tout dépend du budget bien sûr mais j'ai souvent exploité mes périodes improductives pour essayer de planter mon programme. Plutôt que de rester devant son écran à ne rien faire, quand le cerveau est fatigué, c'est le moment de lancer un gros crash test. Egalement pendant les pauses et pendant la nuit.

    Chercher les régressions est toujours plus long que de faire des tests unitaires mais quelle fiabilité peut-on espérer si on ne le fait pas ? Donc, la phrase est jolie, son auteur est prestigieux mais ... comment dire... elle est complètement fausse dans mon cas. Je ne saurais trop suggérer de ne pas économiser le testing, changer souvent de jeu de tests et même de testeurs(euses).


    J'ai discuté avec un développeur Rust hier soir. Il y a un runtime, comme en C++. Donc, Rust est surtout pressenti pour remplacer C++. Pour le C, c'est une autre histoire. Dans l'embarqué. Il n'est pas d'usage d'utiliser des runtime. Ca pourrait changer à l'avenir. Mais C reste unique sur ce point.

    Pour les allocations mémoire, j'ai du mal à appréhender la "Big Picture" de Rust. Clairement, le runtime fait beaucoup de choses mais sans aller jusqu'à la GC.
    Bon, dans la réalité, les capacités mémoire d'aujourd'hui permettent d'allouer de gros buffers avec des marges confortables en usage courant (strings affichables notamment)
    D'autre part, pour les variables locales, les arguments de fonctions etc... Après vérification sur Gemini, Rust alloue un nouveau buffer de pile à chaque appel de fonction !! Grosse différence avec le C qui n'utilise que la pile allouée au démarrage du programme.

    En cas de dépassement de buffer de string, le runtime génère une erreur.

    Par contre, pour les arrays je copi colle la réponse de Gemini :

    En résumé:

    Les dépassements d'arrays ne sont pas testés par défaut en Rust, ce qui peut entraîner des problèmes de sécurité et de fiabilité.
    Il est important de prendre des mesures pour prévenir les dépassements d'arrays et de gérer les cas d'erreur potentiels.
    Des alternatives existent pour garantir un accès sécurisé aux arrays en Rust.

    Comportement identique au C donc mais j'ignore à quoi ressemblent les arrays Rust. Noter que C# teste systématiquement les indices et lève une exception en cas de dépassement.

  9. #129
    Expert éminent sénior

    Avatar de dragonjoker59
    Homme Profil pro
    Software Developer
    Inscrit en
    Juin 2005
    Messages
    2 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Software Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 2 045
    Points : 11 368
    Points
    11 368
    Billets dans le blog
    10
    Par défaut
    Tester c'est pour les faibles, il faut prouver son code...
    Si vous ne trouvez plus rien, cherchez autre chose...

    Vous trouverez ici des tutoriels OpenGL moderne.
    Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
    Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).

  10. #130
    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 commandantFred Voir le message
    Evidemment qu'on teste l'absence de bug !
    Ben non, pas "évidemment" du tout. Parce que le test exhaustif ça n'existe pas. Tout ce qu'un test garantit c'est qu'il n'y a pas de bug pour la trace d'exécution exécutée. Des traces d'exécutions il y en a un nombre pas du tout raisonnable dans un programme réaliste.

    Citation Envoyé par commandantFred Voir le message
    Je ne saurais trop suggérer de ne pas économiser le testing, changer souvent de jeu de tests et même de testeurs(euses).
    Ça tombe bien, la citation ne dit pas du tout qu'il ne faut pas tester. Elle dit juste que tester est insuffisant pour garantir l'absence de bugs. C'est même précisément pour ça qu'il a inventé une technique qui s'appelle le weakest precondition calculus (et que d'autres ont inventé pleins d'autres méthodes pour garantir l'absence de certains bugs, comme les procédures de typage par exemple).

  11. #131
    Communiqués de presse

    Femme Profil pro
    Traductrice Technique
    Inscrit en
    Juin 2023
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 879
    Points : 61 838
    Points
    61 838
    Par défaut Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
    Existe-t-il un consensus au sein de l'industrie sur l'abandon de C/C++ ? Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire

    Dans un livre blanc, Google partage son point de vue sur la sécurité de la mémoire. Voici les raisons pour lesquelles Google publie ce livre blanc.

    Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.

    Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.

    Pourquoi Google publie ce livre blanc maintenant ?

    L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.

    Google :
    En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
    Nom : 1.png
Affichages : 131289
Taille : 77,6 Ko

    Le point de vue de Google

    Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.

    Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.

    Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.

    Google :
    Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
    Mais Google considère qu'il est important de compléter la transition vers des langages à mémoire sûre pour le nouveau code et les composants particulièrement à risque par des améliorations de la sécurité du code C++ existant, dans la mesure du possible. Ils pensent également que des améliorations substantielles peuvent être obtenues par une transition progressive vers un sous-ensemble de langage C++ partiellement sûr en mémoire, complété par des fonctions de sécurité matérielle lorsqu'elles sont disponibles.

    Les investissements de Google dans les langages à mémoire sécurisée

    Google :
    Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.

    • Android a écrit plusieurs composants en Rust au cours des dernières années, ce qui a permis d'améliorer considérablement la sécurité. Dans le module UWB (Ultra-wideband) d'Android, cela a permis d'améliorer la sécurité du module tout en réduisant l'utilisation de la mémoire et les appels interprocéduraux.

    • Chrome a commencé à livrer certaines fonctionnalités en Rust ; dans un cas, Chrome a pu sortir son générateur de code QR d'une sandbox en adoptant une nouvelle bibliothèque à mémoire sécurisée écrite en Rust, ce qui a permis d'améliorer à la fois la sécurité et les performances.

    • Google a récemment annoncé l'octroi d'une subvention d'un million de dollars à la fondation Rust afin d'améliorer l'interopérabilité avec le code C++. Cela facilitera l'adoption progressive de Rust dans les bases de code existantes où la mémoire n'est pas sûre, ce qui sera essentiel pour permettre à un plus grand nombre de nouveaux développements de se produire dans un langage à mémoire sûre. Dans le même ordre d'idées, nous nous efforçons également de résoudre les attaques inter-langues qui peuvent se produire lorsque l'on mélange Rust et C++ dans le même binaire.

    • Google investit dans la construction d'un écosystème open-source à mémoire sécurisée par l'intermédiaire du GISR Prossimo et du projet Alpha-Omega de l'OpenSSF. En 2021, nous avons financé les efforts visant à intégrer Rust au noyau Linux, ce qui nous permet désormais d'écrire des pilotes à mémoire sécurisée. Ce financement est également destiné à fournir des alternatives ou des mises à jour de bibliothèques open-source clés dans un langage à mémoire sécurisée, comme la fourniture d'une implémentation TLS à mémoire sécurisée.
    Google reconnait que les langages à mémoire sécurisée ne résoudront pas tous les bogues de sécurité, mais tout comme ses efforts pour éliminer les attaques XSS par le biais d'outils l'ont montré, l'élimination de grandes catégories d'exploits profite directement aux consommateurs de logiciels et leur permet de se concentrer sur la résolution d'autres catégories de vulnérabilités de sécurité.

    Source : 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



    Et vous ?

    Pensez-vous que cet avis de Google est crédible ou pertinent ?
    Quel est votre avis sur le sujet ?

    Voir aussi :

    La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust, jugés supérieurs pour sécuriser les espaces mémoire des logiciels

    Les futurs logiciels devraient être sûrs pour la mémoire, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyber-attaques

    Google annonce la prise en charge du langage Rust pour le développement d'Android, l'intérêt est de résoudre les problèmes de sécurité de la mémoire
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  12. #132
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    C'est bizarre cette crainte d'être déshonoré qu'on voit sur ce site. Je me fiche pas mal que vous ayez raison ou tort.
    Allez je vous offre un intermède
    A la une du NYT demain :

    La Maison Blanche se rétracte après une remarque désobligeante de Developpez.net à propos du C++
    La DGSI française et le ministère des armées présentent leurs excuses au groupe d'experts éminents

  13. #133
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    Citation Envoyé par Jade Emy Voir le message
    [B][SIZE=4]

    Pensez-vous que cet avis de Google est crédible ou pertinent ?
    Quel est votre avis sur le sujet ?
    Crédible ? Hem ! C'est quand même Google ! Le million de dollars donné à l'équipe Rust pour faciliter la migration parle bien. Qu'ils aient raison ou tort, ils entérinent la mort de C++ sur toutes les plateformes où Rust est implémenté. Donc il est deux fois crédible, d'une part, il est Google, d'autre part, il paye pour aider à faire le job.


    Mon avis, je l'ai déjà donné plus haut. C gardera l'immense marché du petit embarqué. C++ est sur le barbecue.

    Pour une application desktop, vu l'évolution de Java, C# est la première option à considérer. L'écriture d'un gros projet en full C++ a toujours été un choix inexplicable selon moi. Les bugs sont très méchants, les temps de dev sont monstrueux.

    Pour du temps réel vraiment pointu comme un séquenceur audio (DAW) par exemple, le choix est plus difficile même si les machines d'aujourd'hui propulsent un programme javascript beaucoup plus vite que le même programme en assembleur d'il y a 20 ans. Il reste des problèmes de milliseconde qui peuvent se poser typiquement à la lecture d'une séquence musicale sur 20 pistes utilisant une demi douzaine d'instruments VST différents. Le minimum de synchronicité dans ce cas est d'au moins 5 ms. Un délai à la portée de langages de haut niveau avec un CPU récent quoique on puisse souhaiter descendre plus bas et employer Rust comme une bibliothèque pour améliorer la "résolution temporelle" (subtilement différente de la vitesse d'exécution)

    D'autre part, dans les hackatons (CodinGame) les modules C++ tombent comme des mouches à chaque upgrade du compilateur. Très peu de modules survivent à 3 ou 4 upgrades (certains y parviennent quand même). C++ est quand même ultra sensible aux mises à jour.

    A voir si le software des géants (office, .net framework, chrome, etc...) fera sa mue. Les grands éditeurs en ont les moyens. Je dirais même qu'ils y ont intérêt.
    A voir aussi combien d'éditeurs moyens ne pourront pas faire face et mettront la clé sous la porte.

    Il est évident que développeur Rust est une situation plus enviable que développeur C++ depuis quelques mois.

    Rust a gagné tous les suffrages de toutes façons. Il semble évident que le marché l'adopte massivement à l'avenir.

  14. #134
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 684
    Points
    684
    Par défaut
    Citation Envoyé par commandantFred Voir le message
    elle est complètement fausse dans mon cas.
    Ou alors tu n'as pas compris la phrase.

    Mais franchement, c'est pénible et sans intérêt de discuter avec toi. Tu veux pas comprendre et tu nous prend pour des cons quand on n'est pas d'accord avec toi. Je vais arrêter de perdre mon temps.

    Citation Envoyé par Jade Emy Voir le message
    Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire
    Au final, Google conclue les mêmes choses que l'on sait déjà, à savoir (j'ai lu en diagonal la news, pas le doc publié) :

    - les problèmes mémoire sont une cause importante des vulnérabilités connues
    - c'est impossible de réécrire tout le code C++ existant
    - Rust n'empêchera pas tous les bugs

    Donc globalement, cela reste un pari a faire sur l'évolution des différents langages et pratiques. Et différents contextes (on n'est pas tous Google, avec leurs problématiques spécifiques, ainsi que leurs moyens)

    Citation Envoyé par KsassPeuk Voir le message
    C'est même précisément pour ça qu'il a inventé une technique qui s'appelle le weakest precondition calculus
    Dans ton lien : "They define the semantics of an imperative programming paradigm". Question naive : pour les autres paradigmes, en particulier (au hasard...) en POO, il y a des sémantiques spécifiques ou c'est la même sémantique appliquée à de la POO transformée en impératif ? EDIT: et pour la concurrence ?

  15. #135
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Ou alors tu n'as pas compris la phrase.

    Mais franchement, c'est pénible et sans intérêt de discuter avec toi. Tu veux pas comprendre et tu nous prend pour des cons quand on n'est pas d'accord avec toi. Je vais arrêter de perdre mon temps.
    C'est pas comme si à chaque message que je poste, y'avait pas une meute pour me dire que j'ai pas compris, ou que je suis "idiot". Vous n'êtes pas du tout le genre à interrompre quelqu'un qui parle, fût-ce pour lui dire des âneries hors sujet.
    Je n'ai pas le souvenir d'avoir jamais "discuté" avec toi. Ma mémoire fuite peut-être. Si tu trouves ça pénible, surtout, passe au message suivant. Le thread n'appartient pas à l'un ou l'autre des commentateurs que je sache.

    Tout énervé que tu sois, cette citation est très explicite et dit quelque chose que je ne veux pas entendre dans une équipe de dev. Donc, pour conclure, je dirais que je l'ai très bien comprise et peut-être a-t-elle été mal traduite. Je ne parle pas un mot de polonais.

    Je n'ai pas été impoli en faisant cette remarque qui reste proportionnée et appropriée.

  16. #136
    Membre régulier

    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2023
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Octobre 2023
    Messages : 37
    Points : 77
    Points
    77
    Par défaut
    Google est dans son domaine le Web. C'est dans ce contexte que l'on observe le plus de vulnérabilités . N'importe qui peut essayer de trifouiller une application accessible par le réseau. Les attaques sur internet avec Google sont un véritable fléau qui dépasse de loin la conception du C++.


    Rust ne remplacera jamais le C++ qui est un langage sur pour qui ne fait pas d'aberrations. L'avantage du borrowing de Rust ne peut pas effacer toute l'architecture du C++. Il en faudrait plus pour menacer le C++.

    Le problème du C++ c'est la lourdeur si on ne va pas à l'essentiel et la surcharge syntaxique qui est inutile à mon sens.

    Google parle Android, Chrome c'est le monde de l'internet c'est à dire le terrain des arnaqueurs de tout poil. Si on pouvait réduire la cybercriminalité par une rustine comme Rust on l'aurait déjà fait. Mais il faut être réaliste. Mais il est tout à fait concevable que des acteurs d'internet comme Google créent leur propre langage pour mettre à disposition leurs services . A l'heure actuelle il y a une tribu constituée de Rust Go Julia Swift qui tente de percer. Google c'est le Go. Mozilla c'est le Rust. Apple c'est le Swift. Le poids de ces entreprises est tel qu'il peut modifier la donne dans le développement informatique.

  17. #137
    Membre à l'essai
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mars 2024
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2024
    Messages : 2
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par djm44 Voir le message
    Google est dans son domaine le Web. C'est dans ce contexte que l'on observe le plus de vulnérabilités . N'importe qui peut essayer de trifouiller une application accessible par le réseau. Les attaques sur internet avec Google sont un véritable fléau qui dépasse de loin la conception du C++.


    Rust ne remplacera jamais le C++ qui est un langage sur pour qui ne fait pas d'aberrations. L'avantage du borrowing de Rust ne peut pas effacer toute l'architecture du C++. Il en faudrait plus pour menacer le C++.

    Le problème du C++ c'est la lourdeur si on ne va pas à l'essentiel et la surcharge syntaxique qui est inutile à mon sens.

    Google parle Android, Chrome c'est le monde de l'internet c'est à dire le terrain des arnaqueurs de tout poil. Si on pouvait réduire la cybercriminalité par une rustine comme Rust on l'aurait déjà fait. Mais il faut être réaliste. Mais il est tout à fait concevable que des acteurs d'internet comme Google créent leur propre langage pour mettre à disposition leurs services . A l'heure actuelle il y a une tribu constituée de Rust Go Julia Swift qui tente de percer. Google c'est le Go. Mozilla c'est le Rust. Apple c'est le Swift. Le poids de ces entreprises est tel qu'il peut modifier la donne dans le développement informatique.
    Je préfère swift à Rust mais Rust est mieux supporté par la communauté.

  18. #138
    Membre régulier

    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2023
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Octobre 2023
    Messages : 37
    Points : 77
    Points
    77
    Par défaut
    Je préfère swift à Rust mais Rust est mieux supporté par la communauté.
    C'est pour remplacer Objective C. Faut pas rêver cela ne diminue pas la complexité de Cocoa sur Mac. Objective C s'est vu maudit du jour au lendemain alors que c'était un langage très ouvert permettant l'intégration du C et du C++. Apple travaille sur la compatibilité du C++ avec Swift.

    Pour revenir à ces acteurs de l'internet qui refond le monde des langages on s'étonne qu'Amazon n'ait pas crée le sien. Du moins à ma connaissance. Mais j'insiste sur le fait que ces problèmes de mémoire sont étroitement liés au contexte dans lequel on utilise un langage comme le C++ ou pourquoi pas Python . La gestion de la mémoire sur Python me surprendra toujours. Mais bon ce n'est pas un langage compilé.

    Avec le C++ ce qui est critique est la move sémantique dans la navigation des objets en mémoire. Cela induit un partage potentiel excessif des objets en mémoire. Maintenant on dit que Java est plus sur mais avec son garbage collector on ne peut pas bien voir ce que deviennent les objets en mémoire. Pas plus qu'avec Javascript . Mais bon dans la catégorie des langages compilés Ada est sans doute très scrupuleux et C# sur Windows héritier du Pascal Delphi semble assez assez surs.

  19. #139
    Membre averti
    Homme Profil pro
    Ergonome
    Inscrit en
    Octobre 2016
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Octobre 2016
    Messages : 162
    Points : 305
    Points
    305
    Par défaut
    Citation Envoyé par djm44 Voir le message
    C'est pour remplacer Objective C. Faut pas rêver cela ne diminue pas la complexité de Cocoa sur Mac. Objective C s'est vu maudit du jour au lendemain alors que c'était un langage très ouvert permettant l'intégration du C et du C++. Apple travaille sur la compatibilité du C++ avec Swift.

    Pour revenir à ces acteurs de l'internet qui refond le monde des langages on s'étonne qu'Amazon n'ait pas crée le sien. Du moins à ma connaissance. Mais j'insiste sur le fait que ces problèmes de mémoire sont étroitement liés au contexte dans lequel on utilise un langage comme le C++ ou pourquoi pas Python . La gestion de la mémoire sur Python me surprendra toujours. Mais bon ce n'est pas un langage compilé.

    Avec le C++ ce qui est critique est la move sémantique dans la navigation des objets en mémoire. Cela induit un partage potentiel excessif des objets en mémoire. Maintenant on dit que Java est plus sur mais avec son garbage collector on ne peut pas bien voir ce que deviennent les objets en mémoire. Pas plus qu'avec Javascript . Mais bon dans la catégorie des langages compilés Ada est sans doute très scrupuleux et C# sur Windows héritier du Pascal Delphi semble assez assez surs.
    Objective C était prometteur. Son modèle objet était élégant à l'oeil.
    Pour la sécurité mémoire, le problème est centré sur les langages compilés ciblant un CPU précis. Les langages p-codés à GC comme java ou .net ne sont pas vraiment concernés. Les langages interprétés comme javascript ou python sont à priori immunisés à 100% pour autant que l'interpréteur soit bien débuggé.

    La garbage collection, c'est à cause d'elle que Google parle de "sécurité temporelle", du moins, je l'interprète comme ça. La prose des géants reste un peu évasive...
    Ce qui m'étonne le plus, c'est de savoir que Rust est déjà implémenté dans Chrome et Android. Ils ont visiblement déjà beaucoup investi dans la migration.

    Je veux bien parier ma plus belle chemise qu'Amazon ne créera jamais de langage compilé. Pas son style, trop de problèmes, pas assez de revenu, responsabilité très lourde. Les langages, c'est surtout l'affaire des éditeurs d'OS qui ont toujours un avantage pour placer leur système si les API de leur OS sont bien implémentées. En outre, ils ont besoin d'outils pour leurs développements internes.

    Amazon pourrait bien éditer un langage de script pour naviguer dans les offres AWS ou retail. Mais rien de plus qu'un genre de shell script.

    C pourrait bien revenir dans les annonces d'emploi par le truchement de contrôleurs bien pourvus en mémoire qui viendraient grignoter le marché des machines d'enregistrement logistiques (type TPV ou caisse enregistreuse dans les boutiques).

    Pour la demande de développeurs, la double compétence C++ et Rust pourrait être très recherchée dans un avenir très proche.

  20. #140
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 628
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 628
    Points : 10 553
    Points
    10 553
    Par défaut
    Citation Envoyé par djm44 Voir le message
    Avec le C++ ce qui est critique est la move sémantique dans la navigation des objets en mémoire.
    en C++/ C, ce qui est surtout critique, c'est d'avoir des programmeurs super qualifiés et se prendre la tronche pour ne pas faire "d'erreurs" (du moins réduire au maximum)
    C'est 1 ancien débat entre le C++ et le Java : avec le C++ tu te focalises sur le comment faire, avec Java sur ce que tu dois faire.

    Si 1 langage comme Rust permet dans 1 temps assez rapide de supprimer 1 grande partie des "erreurs communes", c'est déjà 1 énorme +.
    C'est comme le casque pour le vélo. En apparence, cela ne sert pas à grand chose. Mais, il permet de ne pas surcharger les urgences pour le moindre choc "bénin".

    De de toute façon, plus le temps passe, et plus dans le domaine embarqué on commence à avoir de gros processeurs et 1 bonne capacité mémoire.
    Et donc à terme ne plus se focaliser sur le pouillième de performance qu'1 langage pourra apporter. Tout sera sandboxé (peut-être virtualisé).
    Regarde la Switch avec Zelda ToTK : ce qu'1 ""téléphone de 2015"" est capable de faire/ d'afficher.

Discussions similaires

  1. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 13h51
  2. Index TIOBE du classement des langages de programmation
    Par Gordon Fowler dans le forum Actualités
    Réponses: 564
    Dernier message: 13/01/2013, 18h51
  3. Passer des paramètres à un programme
    Par Cravis dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 08/11/2007, 14h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 02/04/2006, 23h03

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