Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

La Maison-Blanche exhorte les développeurs à abandonner C et C++ pour Rust

La Maison-Blanche exhorte les développeurs à abandonner C et C++ pour Rust

rustacean.net

Le 04 mars à 06h59

« La Maison-Blanche exhorte les développeurs à abandonner C et C++ », titre Le Monde Informatique.

Les entreprises IT « peuvent empêcher l’introduction de multiples vulnérabilités dans l'écosystème numérique en adoptant des langages sécurisés », explique en effet l'Office of the National Cyber Director (ONCD) de la Maison-Blanche. Il invite les développeurs à réduire le risque de cyberattaques en utilisant des langages protégés contre les débordements de mémoire tampon, les lectures hors limites (out-of-bounds reads) et les fuites de mémoire.

LMI relève que des études récentes de Microsoft et de Google indiquent en effet « qu'environ 70 % de toutes les failles de sécurité sont dues à des problèmes de sécurité de la mémoire », et qu'une fiche d'information de la NSA sur la cybersécurité datant de novembre 2022 mentionne, en plus de Rust, les langages C#, Go, Java, Ruby et Swift, comme sécurisés.

Dans son rapport de 19 pages, l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités en matière de sécurité de la mémoire, et qualifie Rust comme sûr.

L'un des objectifs du rapport de l’ONCD serait de « transférer la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grands groupes, les entreprises IT et le gouvernement américain ». Ils sont, souligne le communiqué de presse de la Maison-Blanche, « plus à même de gérer une menace en constante évolution ».

L'abandon du C et du C++ sera « long et difficile », estime Josh Aas, directeur exécutif et cofondateur de l’Internet Security Research Group (ISRG), à l'origine de Let's Encrypt. « Il faut un effort soutenu pour amener les gens à penser autrement, et des communications comme celle-ci contribuent à rappeler l’importance de la sécurité », a ajouté le dirigeant.

« Il est clair que nous devons écrire et déployer de nouveaux codes, mais pour y parvenir, nous avons besoin de ressources et que des dirigeants à tous les niveaux, du gouvernement au secteur privé, en fassent une priorité », a-t-il insisté. « Les dirigeants concernés doivent être sensibilisés à ce problème et savoir qu'ils seront soutenus s'ils cherchent à le résoudre ».

Le 04 mars à 06h59

Commentaires (158)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Il me semblait pourtant que l'immense majorité des problèmes dans le domaine relevait de l'interface chaise-clavier et/ou de problèmes de configuration. Alors ces 70%, c'est avant ou après que les précédents classiques aient (au moins) entr'ouvert la porte?
La Maison Blanche devrait aussi mieux trier chiffons et serviettes à mélanger des langages tournant sur des interpréteurs/VM à bytecode/nativement (on écrit comment ce qui permets aux 2 premiers de simplement exister sans avoir les derniers).
Bon, ça serait pas le 1er langage à vouloir bouter le C (le C++ serait sans doute déjà plus réaliste)... l'avenir nous dira ce qu'il en est mais vu la masse de boulot il est en tout cas fort lointain!
votre avatar
Un des problème de l'interface chaise-clavier, c'est qu'elle ne fait pas toujours attention à la gestion de sa mémoire. Sauf que C (et C++) n'y font pas pleinement attention non plus. C'est une des problématiques à laquelle Rust tente de répondre : faire des vérifications à ce niveau, dès la compilation.
Ça ne résoud pas tous les problèmes induits par l'interface chaise-clavier mais au moins ces problèmes très "technico-techniques" de gestion de mémoire.
votre avatar
Quite à faire des vérifications à la compil parce que le dev est un légume, dans ce cas, passe directement à l'ADA.

Ce n'est pas bien compliqué de se représenter les cycles de vie de la donnée et de sa représentation en mémoire. Si tu sais faire ça, il est alors possible d'avoir un binaire opérationnel dès la 1ere compil.

Mais bon, aujourd'hui, on apprend à paramétrer des framework et non à programmer.
votre avatar
Rust a une syntaxe qui me semble plus proche des habitudes que celle d'Ada, mais je ne suis pas spécialiste. Quant à traiter les devs de légumes, c'est un peu facile je trouve et je ne viendrais même pas argumenter contre cette pseudo-attaque.

Je ne vois pas pourquoi il faudrait privilégier Ada plutôt que Rust du coup, j'imagine que les deux ont la même fiabilité, un écosystème similaire et que les devs vont naturellement vers ce qui les effrait le moins (oui, les devs sont des créatures qui ne veulent pas toujours faire de gros efforts d'adaptation, comme les humains en général d'ailleurs).
votre avatar
ADA a probablement plus d'ancienneté dans le domaine.
votre avatar
Notez aussi qu'il s'écrit Ada. C'est un prénom, pas un sigle.
votre avatar
Quite à faire des vérifications à la compil parce que le dev est un légume, dans ce cas, passe directement à l'ADA.

L'utilisation d'ADA n'empêche pas la destruction de fusée(s) Ariane ...
J'ai de bons souvenirs de la fac concernant ADA : rigueur, définition de types au micro poil. Mais aussi des souvenir de "lourdeur", qui s'expliquent par les origines, surtout la syntaxe/structure très Pascal.

Sinon, dites moi les codeurs C/C++, si Rust vous fait le même effet que moi : j'ai commencé deux fois le tuto sans jamais réussir à le terminer. Mon cerveau bloque sur des éléments de syntaxe et fait des nœuds.
Bon, après, faut dire que je suis vieux, je manque de souplesse ...
votre avatar
Rust (et d'autres langages "memory-safe" comme Zig) rend la compilation plus difficile, car la priorité est la sécurité du code produit. Les nombreuses vérifications à la compilation (qui sont aussi dues au typage, pas seulement à la gestion de la mémoire, d'ailleurs) sont pénibles mais, quand ça compile enfin, on a un programme plus sûr (et il est plus facile de lire les messages d'erreur du compilo que de déboguer un segmentation fault).
votre avatar
J'ai jamais dit que l'utilisateur devait faire attention à la gestion de sa mémoire, juste à ce qu'il fait car dans ce cadre, 2 options:
-Il est admin, banco dans tous les cas.
-Il ne l'est pas et il faut trouver une faille qui peut permettre de le devenir et pourra exploiter un bug de gestion mémoire ou autre.

Dans le second cas, note que notre étourdi qui clique sur n'importe quoi va en premier lieu se faire poutrer via le programme qu'il installe (imparable) ou des données spécialement construites visant son applicatif (avec une préférence pour ce qui est en frontal réseau: Navigateur, client mail/messageries diverses... oh, tiens-tiens, Rust vient de Mozilla... et ensuite, ce qui permet d'extraire/visualiser ces données, comme une visionneuse d'images).

C'est pourquoi je disais que le C++ (une grande part de l'applicatif compilé) est sans doute plus réaliste que le C (démarrage/OS/drivers-modules). Et en prime cela suffirait sans doute à faire le job.

D'ailleurs la remarque sur l'origine de Rust n'est pas innocente.

Mais même pour de l'applicatif, attention au combo language encore jeune qui évolue/dépendances fondation de pans entiers de nos systèmes/cycles de maintenance de ces derniers:
https://ariadne.space/2021/09/16/the-long-term-consequences-of-maintainers-actions/

C'est de 2021, mais le constat demeure.
votre avatar
L'interface chaise-clavier correspondait au développeur, pas à l'utilisateur du logiciel.
votre avatar
Notez que personne ne prétend réécrire tous les programmes C en six mois. Le rapport de la Maison-Blanche (dont je recommande vraiment la lecture) ne parle que des nouveaux projets.
votre avatar
J'y connais rien en Rust, mais je me demande pourquoi on ne pourrait pas utiliser une IA générative pour "traduire" un code du C/C++ au Rust ? Ça me semble particulièrement adapté, non ?
Sans que ça fasse tout le travail, ça pourrait peut-être en faire 80%, non ?
votre avatar
Le "problème" n'est absolument pas syntaxique, il est sémantique. Le principe de Rust c'est qu'à tout moment il doit exister un et un seul pointeur "maître" qui référencie un bloc alloué. En C ce n'est absolument pas le cas et il existe quelques rares structures de données tordues (p. ex. stocker des listes doublement liées en faisant un XOR des deux pointeurs) qui font qu'à un moment donné il n'existe aucun pointeur vers un bloc mémoire pourtant référencé.
votre avatar
D'un point de vue technique, remplacer le C par Rust peut s'envisager. Pour le C++, cela me parait plus compliqué.

D'un point de vue pratique, ce n'est pas au législateur de s'occuper de ça (coup de bol pour eux, pour une fois, ils n'ont pas dit une grosse connerie). Sinon, en France, tout le monde serait équipé du pare-feu OpenOffice...
votre avatar
Et les perfs ?
Je n'ai jamais entendu parler du fait que Rust serait plus rapide que le C !?

Et pour faire plus rapide que le C, c'est l'assembleur ... et là, les « framework for monkeys » y'en a pas.
votre avatar
Y aussi le COBOL. C'est quasiment de l'assembleur, cela dit.
votre avatar
Mouaif ... en Cobol, tu ne manipules pas les entiers et les flottants en natifs, et encore moins les instructions évoluées du processeur.
votre avatar
Côté perf, Rust est du même niveau que C. Je crois que le rapport entre les 2 est de 1,03 de mémoire
Et pour faire plus rapide que le C, c'est l'assembleur
Pas toujours. En tout cas, pour sur les architectures modernes. Les processeurs sont tellement compliqués, avec les pipelines, et tout le tralala qu'un code C optimisé par compilateur est souvent plus performant qu'un code assembleur écrit à la main.
votre avatar
Oui et non. Oui quand tu fais du code série, la différence étant la capacité du dev à utiliser correctement le compilateur, chose que Rust ne laisse pas trop faire et dans certains scénarios de de type calculs haute-performances, C peut très légèrement battre Rust.

En revanche en code parallèles (type calculs scientifiques/ingé), Rust est jusqu'à x10 (d'après mon expérience) que du C/C++. Non pas en raison du compilateur mais du modèle mémoire qui n'est pas fait pour des tâches de type fork-join de manière efficace.
votre avatar
Merci du retour.

Effectivement, le benchmark que j'avais vu, c'était principalement du code séquentiel (comme la grande majorité des benchmarks)
votre avatar
Ben, pour ce genre de calculs, il y a fortran et les librairies OpenMP ou MPI :)
votre avatar
J'ai pas osé sortir le Fortran, ne sachant pas si c'était encore utilisé.
votre avatar
Non seulement il est encore utilisé, mais il continue d'évoluer ! La dernière version date de 2023 ;)
votre avatar
Sans dépend des mondes. Dans l'industrie, tu trouves encore des vieux codes datant de cette époque. Maintenant, avec les logiciels comme Matlab et la tendance à faire du C++/Rust non Fortran n'est plus vraiment utilisé car, pour les managers (même ceux avec soit disant des diplômes d'ingé), Fortran c'est has-been.

J'ai un client qui a préféré voir sa facture être multiplié par 3 parce qu'il a préféré une lib écrite en C++ qu'en Fortran pour du calcul d'algèbre linéaire. Alors qu'à la fin il ne fait qu'un appel à cette lib (donc il s'en fiche de la techno tant que l'ABI est stable). Mais dans sa tête Fortran sentait les cartes perforées...

Dans le milieu académique, on trouve encore du Fortran (qui plus est sous sa forme moderne). Même si les doctorants ne l’apprennent plus en cours, en général ils deviennent accros une fois qu'ils ont compris que, pour des problèmes s'exprimant avec l'algèbre linéaire, Fortran est génial. J'ai souvenir d'un étudiant de M2 qui ne jurait que par le C++. Et puis, lorsqu'il a découvert Fortran pour ses calculs de mécaniques quantiques en thèse, il a vite changer son fusil d'épaule.
votre avatar
ça dépend. As-tu déjà essayé de faire des R-tree avec Fortran ? Si oui, tu sais alors que C/C++ (ou autres) sont plus appropriés tant pour le confort d'écriture que la possibilité d'optimiser plus finement le code.

OpenMP n'est pas compatible avec Rust nativement en raison de son modèle mémoire. MPI aurait un sens, mais il est souvent implémenté en C. Je ne vois dès lors peu l’intérêt de l'adjoindre à Rust. Un MPI en Rust (je ne sais pas si ça existe) aurait dès lors plus un sens. Mais bon, faire une réduction en Rust avec son modèle mémoire sur un supercalculateur, faut avoir de l'argent à perdre.
votre avatar
Tu n'en a jamais entendu parler car c'est faux. Et c'est bien le problème d'ailleurs car même si cela se joue à quelques % à niveau d'optimisation équivalent, on préférera toujours faire passer les bons outils sur un source C (surtout s'il est bien stable) pour en débusquer les problèmes potentiels que tout recoder dans un langage qui évite les problèmes à la base mais entraîne une petite pénalité.

Faut voir que dans l'industrie, bien souvent un produit tout neuf exploite déjà le matériel à 80% à sa sortie (sinon, on sera mal placé vs concurrence à avoir surdimensionné et on vendra rien). Dès un petit milieu de vie on sera au delà des 95% après l'ajout des features définitives et on cherchera encore à grappiller pour ce qui n'était pas prévu au départ mais que les clients demandent.

Donc les qq % de pénalité de Rust posent déjà problème et comme c'est les industriels qui raquent et/ou contribuent...
votre avatar
80% dans l'industrie ?! Sérieux tu as le chance d'avoir ce genre de perfs. Je constate, pour ma part, des codes perfs de l'ordre de 40 % max. des capacités de calculs d'un processeur par rapport à un code optimisé. Et ceux même avec des logiciels de calculs d'ingé spécialisé.

Après de quelle industrie parle-t-on aussi. Perso, les contrats qu'on me file à exécuter en ce moment, c'est des grands groupes qui ont besoin de ré-optimiser des codes mal écrits ou mal fichus et soit disant vendu pour être performant.
votre avatar
Question de noob : pourquoi plus plausible le remplacement de C que de C++ ?
votre avatar
C++ et Rust ne partage pas la même approche pour le polymorphisme. C++ est basé sur l'héritage, ce qui n'est pas le cas de Rust.

Là où un remplacement par partie de l'existant peut se faire lors d'une transistion C => Rust, cela sera beaucoup plus difficile à mettre en oeuvre dans le cadre d'une transition C++ => Rust, sauf à remplacer d'un bloc tout un applicatif.

Remplacer un applicatif entier, cela présente de nombreux risques. Le faire uniquement parce que l'applicatif est écrit en C++, c'est une "mauvaise raison". Cela fait prendre d'énormes risques à court, moyen et long terme, pour des avantages qui ne se verraient potentiellement qu'à très très long terme.
votre avatar
AMHA, C++. Déjà Rust est un langage OO et risque de poser pour le bas niveau ou le C règne le même pb que C++. Au 1er "new", c'est déjà plus le programmeur qui maîtrise finement sa gestion mémoire. Forcément pour certaines phases globales du démarrage (avant init DDR) ou d'init matériel (drivers), ça fait juste de pas à mal le job et c'est pour cela que le côté "assembleur de haut niveau" du C s'est imposé.
votre avatar
Ce n'est pas le législateur qui s'exprime ici mais un organisme fédéral en charge de guider l'exécutif sur les questions de cyber sécurité. Il s'agit de recommandations et aucunement d'une directive contraignante à ce stade.

En partant de là, ce genre de recommandation pourrait avancer et venir influencer le cadre décisionnel pour par exemple

- s'intégrer aux critères d'appel d'offre de l'état fédéral
- s'appliquer aux développements faits par des agences fédérales (p.ex. Nasa, les services postaux, ...)
votre avatar
Le contraignant est déjà prévu : "L'un des objectifs du rapport de l’ONCD serait de « transférer la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grands groupes, les entreprises IT et le gouvernement américain »."

Particuliers et PME pouvant se retourner contre leurs fournisseurs... Le pb historique Liability => Foolproof des USA. Et ils sont capables d'y aller très vite, ce ne serait pas une première fois. Seule de grosses faillites induites par une légalité douteuse pouvant alors les arrêter.
votre avatar
Il faudrait vraiment que tu jettes un œil au "cyber resilience act" de l'U.E. ...parceque la responsabilisation des "fabricants", distributeurs et importateurs de logiciels atteint des sommets, en permettant à toute entreprise de poursuivre un de ces acteurs en justice en cas de dégâts liés à une vulnérabilité, et ce même si l'entreprise plaignante utilise le logiciel en question à titre gracieux.

En U.E. la mozilla foundation, ou dans certains cas des contributeurs, pourraient se faire poursuivre par les utilisateurs lésés par une vulnérabilité.

Il ne sera plus possible de s'abriter derrière une clause de type "ce logiciel est mis à votre disposition tel quel, utilisez-le à vos risques et périls"

De ce que j'ai lu de l'approche US sur la question, on reste dans un cadre moins dangereux pour les petits acteurs, les contributeurs du libre, ...
votre avatar
Et les recommandations techniques du rapport US sont sérieuses, alors que pour le CRA européen, elles seront écrites par CEN/CENELEC, qui n'y connait rien en programmation.
votre avatar
C'est clair, sur le plan réglementaire, l'U.E. est une faillite intellectuelle sur le côté cyber sécurité.

Aussi le coup de l'EIDAS où on oblige les navigateurs à faire confiance aux les autorités de certification étatique en mode "tu nous fais confiance, sinon...", au lieu de laisser les navigateurs gérer le sujet avec des critères qualitatifs objectifs, ça ne rassure pas. Ils sont occupés à changer l'U.E. en république ex-soviétique.

Et les projections concernant les votes pour les élections européennes tendent à montrer qu'on ne va pas vers une amélioration de l'intelligence des gens qui nous dirigent... bien au contraire...
votre avatar
Oh non, je suis exhorté. Oskour.
votre avatar
« La Maison-Blanche exhorte les développeurs à abandonner C et C++ », titre Le Monde Informatique.
Moi qui croyait qu'on ne faisait plus que des logiciels inefficients en NodeJS réinventant la roue et empilant les surcouches inutiles pour des fonctions basiques.
Dans son rapport de 19 pages, l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités en matière de sécurité de la mémoire, et qualifie Rust comme sûr.
Moi ça me rassure pas, car lorsqu'on qualifie un truc comme "sûr", on a tendance à relâcher son attention. Et donc à la fin, à faire de la merde quand même en reposant sur la supposée sûreté by design.

Je ne suis pas développeur et suis incapable de dire si tout ceci est vrai ou pas pour Rust. Peut-être que oui et tant mieux. Mais j'aime pas les arguments du style "utilisez Machin car c'est plus sûr", ça me rappelle trop les "utilisez Linux c'est plus sécurisé" scandé tel un dogme alors que c'est au mieux de la superstition. La sécurité magique by design, à ma connaissance, ça n'existe pas. Ca demande du travail dans tous les cas. Si le produit facilite ce travail et évite de faire des erreurs basiques, tant mieux. Mais perso je considère qu'il ne faut pas non plus trop s'endormir sur ces arguments.
votre avatar
Disons que Rust a besoin de connaître la taille de toutes les variables déclarées au moment de la compilation pour pouvoir gérer la mémoire lui même, ça ne résous pas tous les problèmes mais c'est déjà un début.

Un point que je trouve quand même relativement intéressant c'est que le but pour le gouvernement américain (visiblement) est de déplacer la responsabilité
L'un des objectifs du rapport de l’ONCD serait de « transférer la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grands groupes, les entreprises IT et le gouvernement américain ». Ils sont, souligne le communiqué de presse de la Maison-Blanche, « plus à même de gérer une menace en constante évolution ».
Je ne sais pas si c'est la meilleure des solutions mais c'est un choix qui s'entend s'ils arrivent à trouver des solutions alternatives qui palient à 99% au problème initiale mentionné dans l'article.
votre avatar
Tout à fait d'accord pour l'empilement des couches. Depuis 30 ans que je fais de l'informatique, je n'ai quasiment jamais entendu quelqu'un parler d'optimisation...

Pour ce qui est de Rust, le langage est effectivement memory safe sauf que... pour une raison qui m'échappe, il est prévu des opérations unsafe telles que déréférencer un pointeur.

:reflechis: :fumer:
votre avatar
Habituellement les opérations unsafe (y a aussi en C#) c'est soit pour les performances dans des sections très critiques, soit pour l'interopérabilité avec d'autres langages. Dans les deux cas on essaie de rendre ces sections les plus courtes possibles.
votre avatar
C'est pour s'interfacer avec des lib en C.
votre avatar
La raison qui vous échappe est, par exemple, de pouvoir parler directement au matériel. Mëme Ada avait son "chapitre 13" des opérations dangereuses. Au moins, elles sont clairement marquées. En Rust, contrairement à C, il est trivial de voir si un programme utilise des trucs qui ne sont pas "memory-safe".
votre avatar
Je cite Bjarne Stroustrup (le fou derrière l'horreur qui est connue sous le nom de C++) :
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."
C++ est plus "safe" que C, mais C++ n'empêche pas de faire de la merde non plus avec des cascades de conséquences plus importante.
votre avatar
Surtout que, c'est pas nouveau, mais je dirais que niveau interpréteurs divers le problème posé par ceci:
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Qui ammenait à travers l'exemple du C (et Rust n'y pourrait rien non plus, le pb étant de taper le code généré, y compris le compilo des générations suivantes!) à ce bilan:

"In demonstrating the possibility of this kind of attack, I picked on the C compiler.
I could have picked on any program-handling program..."

Demeure!

Le problème étant que la parade imaginée bien plus tard (au delà du pb de poule et d'oeuf de compilo de confiance posé par la DDC, cf "Here’s Wheeler’s trick" ici: https://www.schneier.com/blog/archives/2006/01/countering_trus.html) ne vise pas les interpréteurs (ou autre bytecode généré à la volée) côté utilisateur.

Décliner le concept du natif/compilé, ce qui est imaginable, poserait en effet un problème existentiel à ce type de langage: Multiplier, à chaque exécution ou 1ère exécution et chez chacun, la pénalité unique de build côté développeur du natif... Ouille!
votre avatar
Je ne suis pas développeur et suis incapable de dire si tout ceci est vrai ou pas pour Rust
Ton analyse/questionnement est le bon.

Pour simplifier un peu: Rust empêche intrinsèquement les erreurs "non intentionnelles" les plus fréquentes parce que le programmeur est obligé de déclarer son intention de manipuler/partager un espace mémoire.

Rust n'empêche pas les erreurs grossières mais tellement communes "je fais comme ça pour l'instant et je corrigerai plus tard" qui n'est jamais corrigé, ni le fait qu'une bibliothèque vérolée pourrisse un produit, ni une conception trop légère sur la sécu...
votre avatar
Moi qui croyait qu'on ne faisait plus que des logiciels inefficients en NodeJS réinventant la roue et empilant les surcouches inutiles pour des fonctions basiques.
On pense souvent ça, mais en fait l'architecture de NodeJS est excellente, et permet dans de nombreux cas une meilleure efficacité qu'un programme équivalent en C++.

Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.

Il faut vraiment avoir des besoin de calcul à haute performance spécifiques pour que NodeJS ou Python ne conviennent pas.

S'il n'y a pas de besoin de perf en calcul, NodeJS ou Python sont de bien meilleur choix que du code C/C++ pour une application industrielle.

Pour les autres cas il y a Rust ou Go.

Si on se repose sur une peur permanente du dev pour "ne pas relâcher son attention", la partie est déjà perdue. L'attention mise sur des problèmes de gestion mémoire ne sera pas mise sur d'autres aspects.

Par ailleurs, on peut détruire l'efficacité d'un programme C/C++ plus facilement qu'en NodeJS.

Particulièrement en C++, c'est vraiment facile de copier des structures entières et tous leurs enfants en une ligne de code. Comme une std::map(std::string,std::string) passé en argument par valeur.

Ou de rajouter des blocages et des ralentissements significatifs avec des mutex et des locks, alors que NodeJS a une architecture lock-free.
votre avatar
Par ex. le modèle d'event-loop de NodeJS basé sur libuv permet de meilleurs perfs avec un serveur web NodeJS que Apache.
Toujours regarder en détail les benchmarks, sinon, on y voit ce que l'on veut ;)

En l'occurence, je vois 2 gros points noirs qui viennent complètement fausser la comparaison :
- Apache + PHP, et non Apache + FastCGI/PHP (un context PHP est recréé à chaque requête, forcément, ça fait mal)
- A une époque pas si lointaine, les serveur nodeJS n'étaient jamais en front, toujours derrière un reverse proxy comme... Apache (les choses ont peut être changées depuis, d'où l'usage du passé). Quand on commençait à vouloir faire de la mise en cache, de la compression gzip à la volée ou même tout simplement du SSL/TLS, nodeJS était nul, sans compter sur l'explosion de la mémoire nécessaire.
votre avatar
- A une époque pas si lointaine, les serveur nodeJS n'étaient jamais en front, toujours derrière un reverse proxy (...)
Surtout que maintenant on met du WAF devant les applications.

Après, ma remarque trollesque sur NodeJS (mais les explications données ensuite étaient très intéressantes, merci aux intervenants) venait surtout du point de vue de quelqu'un qui ne comprend pas pourquoi il faut démarrer un serveur web qui exécute le moteur Javascript de Chromium pour faire un éditeur de texte sur son PC.

C'est une caricature, mais à un moment, je me dis qu'on a foiré une étape en chemin. Sans parler de la surface d'attaque qui s'élargit forcément car on empile les runtimes et les dépendances.

Certes, ça permet aussi de faire des applications extrêmement portables, VSCode en version Web c'est très pratique (GitHub Codespace reposant là dessus) et Diagram.net est un formidable outil. Mais y'a toujours un truc qui me gêne avec cette techno et la multitude de produits désormais basés dessus. Un peu comme les appImage qui pullulent sous Linux pour compenser la multiplicité des distribs en préférant ramener des bulldozers de 45 tonnes pour le moindre logiciel avec une régression monumentale en terme de gestion de packages (en gros, aucune).
votre avatar
[troll]Biden décide de s'occuper des problèmes de mémoire. Il était temps.[/troll]
votre avatar
pas mal :)
votre avatar
La Maison-Blanche exhorte les développeurs à abandonner C et C++ pour Rust
Non.
La Maison-Blanche exhorte les développeurs à utiliser des langages de programmation "memory safe".
Donc effectivement d'abandonner C/C++ comme à titré le Monde Informatique.
Mais pas de passer à RUST comme titre NXI.

C'est dingue de constater que Le Monde Informatique a mieux compris l'information que NXI.
votre avatar
... ben pourtant.

Il y a un paragraphe entier intitulé « Rust cité en exemple », qui précise « Dans son rapport de 19 pages, l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités en matière de sécurité de la mémoire, et qualifie Rust comme sûr. »

La source précise effectivement « there are dozens of memory safe programming languages that can – and should – be used », mais seul Rust est nommément cité.
votre avatar
Rust est cité une seule fois dans le rapport de l'ONCD. ici:
According to experts, both memory safe and memory unsafe programming languages meet these requirements. At this time, the most widely used languages that meet all three properties are C and C++, which are not memory safe programming languages. Rust, one example of a memory safe programming language, has the three requisite properties above, but has not yet been proven in space systems.
Voila. ni plus ni moins.

Idem dans la note de la NSA:
Recommended memory safe programming languages mentioned in the CSI include C#, Go, Java, Python, Rust, and Swift. Software manufacturers should evaluate multiple memory safe programming languages before integrating them into their workflows

Les langages sont simplement cités dans l'ordre alphabétique, sans indiquer de préférence. De plus, la note indique que les fabricants doivent en évaluer plusieurs. Donc pas foncer tête baisser vers RUST.
votre avatar
D'ailleurs, les bons programmeurs utilisent tous Zig, pas Rust, à la place de C :-) https://www.infoworld.com/article/3713082/fast-growing-zig-tops-stack-overflow-survey-for-highest-paid-programming-language.html
votre avatar
Ceci dit pourquoi ça serait au langage de porter la notion d'intégrité de la mémoire ?

Normalement, un dev sait comment un ordi fonctionne, sait comment un processus vit en mémoire, sait comment le code et les données sont agencées dans l'espace mémoire du process et sait comment le langage ordonne les données en mémoire.

A quoi bon bouffer des perfs en compil et en execution pour faire des contrôles inutiles dans la mesure où le dev a déjà fait le travail ?
:D
votre avatar
C'est un vaste débat qui dure depuis la nuit des temps. Au final, au-delà des positions tranchées, je dirais que ça dépend de l'utilisation finale du programme, de ses performances souhaitées, des contraintes techniques (puissance CPU, espace mémoire vive et mémoire programme), du temps de développement disponible et des compétences des développeurs. Sinon on fait tous de l'assembleur en binaire et y a même plus besoin de compiler.

Ca ne sert pas à grand chose d'utiliser un langage très rapide pour une application qui n'en a pas besoin plus que ça (sans tomber dans l'excès inverse non plus), surtout si l'équipe de développement doit longtemps galérer à corriger des bugs abscons (les bugs de gestion mémoire c'est assez horrible à tracer, il faut déjà s'apercevoir que c'en est un) parce qu'on sait qu'elle n'a pas les compétences pour maîtriser ce langage. Ceci dit sans vouloir juger, l'équipe a certainement d'autres compétences et je ne dirai pas qu'elles sont moins bonnes, il faut juste s'adapter aux points forts et aux points faibles, y compris de ceux pour qui on développe quand on doit livrer les sources.

Donc par exemple (choisis vite faits), OK pour mettre du C avec des vrais morceaux d'assembleur dans un encodeur vidéo, mais certainement pas dans un logiciel de gestion de quelque chose en entreprise où on ne mettra sans doute même pas du C++ mais plutôt un des langages "sécurisés" cités dans l'article, quand c'est pas carrément du Web (bon ça c'est surtout pour la facilité d'accès depuis n'importe où).
votre avatar
Parce qu'il n'y a pas que les dévs qui font du développement. Il y a aussi énormément de pisseurs de code (très probablement bien pus nombreux que les dévs).
votre avatar
Tu as oublié les devs trop sûr d'eux qui pensent que les bugs de mémoire ne sont introduits que par des pisseurs de code :mad2:

C'est l'humain le soucis et c'est l'idée de se baser sur la capacité d'un dev à ne pas commettre d'erreur qui est une erreur.
votre avatar
Les personnes trop sûres d'elles au point d'être persuadées de faire un travail toujours proche de la perfection (s'ils ne la dépassent pas), c'est dans tous les domaines, pas spécifique au développment :)
votre avatar
Et les bugs sur le terrain, c'est toujours de la faute de leurs clients, rayonnements cosmiques, ou parce que le système n'est pas configuré comme chez eux, n'est-ce pas ?

Rust pour le coup serait un très bon langage pour ces personnes-là en leur forçant à réexaminer le code que le compilateur refusera et de voir où les possibilité de condition de course ou d'aliasing interviennent, ce leur serait d'un grand apprentissage. Mais malheureusement leur ego, qui n'a d'égale que leur sentiment d'excellence, ne leur permet pas ce genre de remise en question.

Si tu es dans cette catégorie, je te souhaite de courage pour gérer les bugs sur le field. Mais je sais, ça ne doit jamais t'arriver ;)
votre avatar
Ceci dit pourquoi ça serait au langage de porter la notion d'intégrité de la mémoire ?
Dans la gestion des risques, les mesures de contrôle "by design" doivent être privilégiées si elles existent.

Avec ce rapport, les autorités US rappellent aux fabricants que ca existe et qu'ils doivent donc les utiliser.
votre avatar
Parce que beaucoup de dev ne font pas bien leur travail.

Et c'est tellement facile d'utiliser un pointeur après avoir libéré la mémoire dans un programme à états.
votre avatar
« Normalement, un dev sait comment un ordi fonctionne, sait comment un processus vit en mémoire, sait comment le code et les données sont agencées dans l'espace mémoire du process et sait comment le langage ordonne les données en mémoire. » Ça, ce n'est pas un dev, c'est un Surhomme, voire un Dieu Vivant venu de l'espace. Les devs que je connais sont humain·es et ont des capacités cérébrales finies (d'où l'importance du rapport de la Maison-Blanche, avec lequel je suis d'accord).
votre avatar
"Les devs que je connais sont humain·es..."

Va falloir inventer le langage de programmation inclusif, piquant les yeux à l'écrit et imprononçable à l'oral, imposant d'oublier "l'accord" qui ferait écrire "developpeur-euse" sonnant trop "develop-peureuse" et bouclerait la boucle de l'inclusif au stigmatisant!

Bon, sur le fond du problème on en revient à des préoccupations très typiques des USA: Liability menant au Foolproof (littéralement: "A l'épreuve des cons"), par conception et/ou parades/avertissements.

Les conséquences chez eux allant du "Objects in the mirror are smaller than they appear" (sans déconner!) gravé sur les rétros de bagnole à des matériels conçus pour presque tout pardonner niveau erreurs de l'utilisateur. Quand c'est trop difficile voir impossible (aviation...), cela peut mener à la faillite des constructeurs sur un seul évènement. Y'a bien que le sacro-saint flingue qui chez eux échappe au concept.
votre avatar
Va falloir boire ta camomille :kimouss:
votre avatar
Je ne supporte pas cette écriture aussi débile qu'imprononçable... Ce qui est dingue, c'est que même l'EFS s'y était mis une fois aux appels au don du sang. Apparemment, ça avait été la douche pour en avoir parlé au médecin par lequel on passe avant: Au mieux les gens venaient et demandaient quelle mouche les avait piqué au pire ils ne venaient pas. Le plus cocasse étant que ceux a qui cela s'adressait et qui a qui il était enfin permis de donner sans devoir mentir ne venaient pas plus: Ça demande des "droits" mais quand il s'agit de donner de sa personne pour les exercer y'a plus personne.

Depuis l'EFS écrit de nouveau en français. Un bilan qui vaut sans doute bien des sondages.
votre avatar
Donc tu penses réellement que l'EFS permet à des homosexuels de donner du sang dans l'unique but d'être inclusif et de suivre une mode ?

Je ne supporte pas ta façon de raisonner mais pourtant je considère que tu as le droit de t'exprimer. Tu ne me portes pas irrespect comme le commentaire plus haut ne te porte atteinte en aucune manière.
votre avatar
C'est vrai que "humain point médiant euh" c'est super facile à prononcer, et surtout à comprendre...
Ce qu'oublient les adorateurs de l'écriture inclusive excluante, c'est qu'en plus d'excluer totalement les non-binaires, elle n'est aucunement prononcable à l'oral. Alors que l'écriture n'est là QUE pour coucher l'oral, et rien d'autre.
votre avatar
Et c'est sans compter que le point médiant est une véritable plaie pour de nombreux utilisateurs de dispositifs de lecture vocale, comme les mal voyants par exemple.
votre avatar
Ce qui ressortait de cette affaire au delà du problème d'écrire en français, c'est que les minorités concernées qui ont fait des pieds et des mains des décennies pour pouvoir donner, amenant sans doute à ces point-débiles-pseudo-inclusifs dans les com de l'EFS, sont plus fortiches pour réclamer des droits que pour les devoirs qui en résultent.
In-fine, comme ils ne viennent pas, l'EFS ne pouvait pas se permettre d'irriter ceux qui viennent pour quelques fio:censored: qui aiment visiblement plus râler que les piqures!
Et de ré-écrire en français lisible et même prononçable...
:bravo:
votre avatar
"In-fine, comme ils ne viennent pas, l'EFS ne pouvait pas se permettre d'irriter ceux qui viennent pour quelques fio:censored:"

Ha mais tu réussis vraiment bien à montrer que le problème que tu as avec cette comm' se situe au niveau de la langue française et pas un problème viscéral contre ces personnes :stress:
votre avatar
Je n'ai pas de problème "viscéral", à vrai dire je m'en cogne de qui baise qui et de quel sexe chez lui. Ce qui me pose problème c'est vraiment le prosélytisme croissant et mal inspiré de certains dans cette communauté dont le don du sang, devant lequel ils se dégonflent après en avoir réclamé le droit et que l'EFS consente même à violer la langue pour les rameuter, n'est pas le principal problème hélas...

Je dirais que ça a démarré avec la gay-pride: Franchement, qui a envie en croisant cela dans Paris avec ses gosses de leur expliquer pourquoi 2 mecs/nanas se paluchent, ou ce que la grande folle en talons cambrée comme la vache qu'on amène au taureau a logé dans le fion?

Et ça c'était avant qu'ils ne demandent la PMA (le M c'est pour médical, rappelons le) pour toutes (sans logique vs des préférences sexuelles rendant l'affaire normalement impossible) en attendant la mère porteuse pour tous, par souçi d'égalité...

Il y a un moment ou cela pose en effet un problème qui peut devenir viscéral, mais merci de ne pas confondre cause et conséquence.
votre avatar
C'est triste de s'attendre à ce que tes gosses ne te demandent rien de plus compliqué que d'expliquer pourquoi 2 personnes peuvent s'aimer quelque soit leur genre.

J'ose espérer qu'ils peuvent s'exprimer suffisamment librement que pour pouvoir te poser des questions hautement plus intimes que ça sans avoir à sentir qu'il y a un problème parce que ça dérange papa ou maman.
votre avatar
Tu as visiblement mal et/ou pas tout lu... Ou alors pas de meilleur aveugle que celui qui ne veut pas lire car il soutient les dérives citées. Des gonzesses qui se baladent avec des "gadgets", j'en ai connu, en particulier une bonne coch.... qui mettait des boules de geisha quand on faisait de la moto histoire de multiplier l'effet "good vibrations". Aucune par contre montée sur un char dans la rue avec le truc visible, chose que l'on est certain de voir si on croise la "fameuse" parade annuelle. Et je ne connais absolument personne d'assez tordu pour souhaiter expliquer cela à ses jeunes enfants, mais j'avoue ne pas avoir de malades mentaux dans mon entourage. Le pire niveau enfants étant de les voir arriver à tordre la PMA pour arriver à en avoir non pour une raison médicale mais de préférences sexuelles qui interdisent naturellement l'affaire. Mais de qui se moque-t'on? Il y a un moment ou il faut être simplement cohérents...
votre avatar
Personnellement, je ne vois pas trop le problème, il me semble plus important que tou·te·s puissent se sentir représenté·e·s quand on s'exprime, le tout en gardant le texte compact, oralement c'est bien entendu une autre paire de manches, mais on s'en contentera pour l'écrit.
votre avatar
On peut aussi juste respecter la langue francaise, qui est déjà adaptée pour inclure TOUT LE MONDE, sans faire d'exception (contrairement à l'écriture inclusive excluante) et qui est parfaitement lisible, au lieu de tout faire pour la détruire connement.
votre avatar
«[La] langue française n’est point fixée et ne se fixera point. Une langue ne se fixe pas. L’esprit humain est toujours en marche, ou, si l’on veut, en mouvement, et les langues avec lui. Les choses sont ainsi. […] Toute époque a ses idées propres, il faut qu’elle ait aussi les mots propres à ces idées. Les langues sont comme la mer : elles oscillent sans cesse. À certains temps, elles quittent un rivage du monde de la pensée et en envahissent un autre. Tout ce que leur flot déserte ainsi sèche et s’efface du sol. C’est de cette façon que des idées s’éteignent, que des mots s’en vont. Il en est des idiomes humains comme de tout. Chaque siècle y apporte et en emporte quelque chose. Qu’y faire ? cela est fatal. C’est donc en vain que l’on voudrait pétrifier la mobile physionomie de notre idiome sous une forme donnée. C’est en vain que nos Josué littéraires crient à la langue de s’arrêter; les langues ni le soleil ne s’arrêtent plus. Le jour où elles se fixent, c’est qu’elles meurent.»

Victor Hugo


Mais tu considères aussi qu'un bon dev est un dev qui ne fait jamais d'erreur malgré le fait d'être un humain. Ca ne doit pas te sembler impossible d'arrêter le soleil non plus :mrgreen:
votre avatar
Pas certain que Victor Hugo ait pu imaginer que son constat de bon sens puisse être utilisé un jour pour défendre une aberration pareille. Évolution n'est pas sabotage et le propre de l'écrit reste de coucher fidèlement l'oral. Même en ayant été transgressif il n'a à ma connaissance jamais oublié les fondamentaux.

Maintenant, c'est mon avis. Le sien on ne l'aura jamais et je ne me permettrait certainement pas de me raccrocher à ses écrits pour soutenir mes propres opinions.
votre avatar
Il ne suffit pas d'écrire en majuscule un truc pour qu'il devienne vrai... la grammaire française invisibilise de fait le féminin, ce qui montre plus un irrespect de la langue pour celles qui la pratiquent.

et puis bon, directement les grands mots, comme "détruire la langue" ... que de balivernes. On est dans un monde qui bouge et change, et s'efforcer de garder la langue au 17è siècle n'est pas lui faire honneur, et ce n'est pas non-plus faire confiance à celleux qui la pratiquent.
votre avatar
Du coup, que penses tu de ce petit programme de monitoring des fréquences CPU en C, écrit le nez au vent sans notes, juste avec le schéma de données en tête ? :D

https://github.com/TNZfr/watchfreq

Edit : Eh bé ... 22 clones du dépôt en 5 heures. :)
votre avatar
Ce projet est vraiment sensé pouvoir démontrer quelque chose ?
Il ne démontre aucune compréhension spécifique de l'architecture d'un ordinateur. Faire des malloc, utiliser le keyword "register" ou savoir comment récupérer les fréquence du CPU via sysfs ça n'est pas de la compréhension du fonctionnement d'un ordinateur. Tu sais coder en C et utiliser certaines API du système Linux.

La remarque de Stéphane sur le fait d'être un Dieu s'attache plutôt à critiquer la remarque qui était que si tu sais comment l'ordinateur fonctionne, alors il est à ta charge de gérer l'intégrité de la mémoire et que, au final, c'est facile de ne jamais faire de bourde puisque tu sais comment ça fonctionne.

Tu es inhumain si tu es capable de guarantir que tu ne commetras aucune erreur de distraction qui aboutiront à des problèmes de mémoire si tu n'as pas l'assitance d'outils (et il en existe en C aussi).
Là aussi ton projet ne démontre rien, sa complexité est trop basse pour prouver que tu as cette qualité qu'on trouve inhumaine ;)
votre avatar
Fais mieux et après on cause !

Et pour peu que tu aies compris les mécanismes codés ... lire 3 lignes et reconnaître une arborescence linux et un ou 2 mots-clés du langage ne fait pas de toi un critique crédible. Tu as regardé la surface et tu es passé à côté de l'algo.
votre avatar
J'ai regardé ton programme, histoire de m'amuser. Je me considère rouillé en C, dans la mesure où je n'en fais plus depuis fort longtemps. Voici ce que j'ai vu, qu'un langage comme Rust ne laisserait pas passer :
- fonction GetNbCore() : aucune vérification sur l'accès au pipe, ni aucune gestion des erreurs.
- fonction read_freq() :
- idem, aucune vérification quant aux accès au système de fichiers
- pas de vérification de la valeur de retour des appels à malloc
- je ne vais pas dire que la mémoire n'est pas libérée, puisque ton application à juste besoin d'allouer de la mémoire au début une fois pour toute au début de l'application. Une fois qu'on est dans la boucle principale, aucune allocation n'est faite.

Je m'arrête là pour l'analyse. Un attaquant aurait de quoi largement faire avec ce petit programme ^^ Surtout qu'il y a d'autres problèmes (mais pas lié au langage lui-même).
votre avatar
Contrôle des pipes : la chaine de caractère finit dans un atoi ... qui sortira une valeur nulle au pire. Et la plupart des programmes qui utilisent des pipes font des appels comme ça : pclose(popen("commande","r")); ... surtout utilisé dans les programmes multi-threadées pour remplacer la fonction system() non compatible avec le multi-threading.

Contrôle du système de fichiers : surtout sur une arborescence mémoire montée par le noyau (et donc mécaniquement présente sinon tu n'aurais pas même pu te connecter à la machine).

Un contrôle de malloc unitaire sur des tailles maîtrisées (dépendant du nombre de cores/threads et non d'un paramètre utilisateur) ... t'es gentil. Tu passerais ton temps à faire des malloc / realloc dans des boucles et/ou des malloc dépendants de paramètres utilisateur (donc potentiellement déconnants), là, oui le contrôle des valeurs retournées est obligatoire.

Et au jeu des vérifications, j'ai aussi oublié de contrôler l'espace disque disponible (ben oui puisqu'il y a des fopen), les T° CPU / carte mère (ben oui, ça boucle) et l'âge du capitaine.

Effectivement, tu fais bien d'arrêter ... parce qu'enfoncer les portes ouvertes des « bonnes » pratiques trouvées sur wikipedia, n'importe quel script-kiddie en est capable. Tu n'as même pas essayé de comprendre l'algo (d'ailleurs personne n'en a parlé) et pourquoi les contrôles que tu dénonces manquants ne sont pas nécessaires.

Maintenant, puisque tu as trouvé des « failles », je te propose de mettre à jour le bout de code et de nous montrer comment il devrait être. Toutefois, il faut que :
* ça compile sans warning,
* ça reste maintenable CàD compréhensible par quelqu'un qui découvre le code pour la 1ere fois (ça c'est pas simple)
* les perfs ne soient pas dégradées : CàD une conso CPU qui ne polluera pas les mesures.

Enjoy !
(d'où le fameux « keep it simple, stupid ! »)
votre avatar
Contrôle des pipes : la chaine de caractère finit dans un atoi ... qui sortira une valeur nulle au pire. Et la plupart des programmes qui utilisent des pipes font des appels comme ça : pclose(popen("commande","r")); ... surtout utilisé dans les programmes multi-threadées pour remplacer la fonction system() non compatible avec le multi-threading.
Depuis quand "la plupart des programmes" c'est une justification pour faire quelque chose qui s'apparente à une mauvaise pratique ?

Et puis, pas de bol, je ne parlais pas de ça (du aoti). Je parlais d'aller lire un flux sans même savoir s'il est ouvert correctement ou pas.
Contrôle du système de fichiers : surtout sur une arborescence mémoire montée par le noyau (et donc mécaniquement présente sinon tu n'aurais pas même pu te connecter à la machine).
Il est effectivement impossible d'avoir un programme tournant dans un environnement "sécurisé" comme les conteneurs, un chroot, ou dont l'accès à cette partie du système de fichier est interdite via des règles de gestion fine. De même qu'il est impossible que la limite du nombre de descripteur de fichiers ouverts soit atteinte. Tant de certitude...
Un contrôle de malloc unitaire sur des tailles maîtrisées (dépendant du nombre de cores/threads et non d'un paramètre utilisateur) ... t'es gentil. Tu passerais ton temps à faire des malloc / realloc dans des boucles et/ou des malloc dépendants de paramètres utilisateur (donc potentiellement déconnants), là, oui le contrôle des valeurs retournées est obligatoire.
Es-tu certains à 100% que les appels à malloc soient maitrisés ? Moi non. Le premier dépend de la valeur de retour du programme "nproc" : le premier programme "nproc" trouvé qui sera dans le PATH (c'est ça la faille qui ne dépend pas du langage : utilisation d'un programme sans préciser son chemin absolu, permettant de le substitué très facilement). Ton nproc renvoi 100000000 et boum.

En gros, ton programme, je peux lui faire consommer 4Go très facilement si j'en ai envie. Toujours maitrisé donc ?

De plus, tu sembles considérer des ordinateurs avec une mémoire de plusieurs Go. Sache que Linux tourne sur de nombreux terminaux. Par exemple, des routeurs. Celui que j'ai et sur lequel tourne OpenWRT ne dispose plus que de quelques ko (oui oui, quelques ko !).
Effectivement, tu fais bien d'arrêter ... parce qu'enfoncer les portes ouvertes des « bonnes » pratiques trouvées sur wikipedia, n'importe quel script-kiddie en est capable.
Que d'arrogance.... Que répondre à ça, si ce n'est que tu ne sembles même pas comprendre les bases de la sécurité informatique dans les programmes...
Tu n'as même pas essayé de comprendre l'algo (d'ailleurs personne n'en a parlé) et
En toute honnêteté, on s'en fiche de ton algo. C'est pas le but de la discussion. Le but c'est l'apport d'un langage comme le Rust par rapport au C.
pourquoi les contrôles que tu dénonces manquants ne sont pas nécessaires.
Et moi je maintiens qu'ils sont nécessaires. Pas pour le cas "normal" (on est d'accord la-dessus). Mais un attaquant qui cherche à exploiter une faille n'en à rien à faire du cas normal. Ce qui l'intéresse, ce sont les effets de bords exploitables.

Et désolé de te le dire, mais ton programme, pourtant court, présente de nombreuses failles que ton orgueil refuse de considérer.
Maintenant, puisque tu as trouvé des « failles », je te propose de mettre à jour le bout de code et de nous montrer comment il devrait être.
Pas de souci. Je peux. Où puis-je t'adresser mon devis ?
votre avatar
Bon, tu ne fait qu'effleurer la surface et tu campes sur tes positions.
Tu nous fais le chapitre du programmeur absolu qui ne sait pas contextualiser. Et justement, la contextualisation permet d'ajuster le code avec ce qui est nécessaire. C'est un ensemble. Pour faire tourner une application dans un datacenter la composante plateforme de production est très importante (puissance de calcul, système d'exploitation ...) dans la conception du code.

Je vais faire le vieux con et j'aime pas ça : un programme ne tourne pas tout seul, il lui faut un OS et une machine pour fonctionner. Si tu ne tiens pas compte de ces paramètres, aucun programme ne pourra être dans les clous des règles de programmation, à part HelloWorld, et encore, y'a des fois où certains arrivent à faire de la m*rde avec ce dernier. Mais bon, pour ça, il faut avoir un peu plus de bagages que des formations médailles en chocolat de paramétrage de frameworks en java. Tout le monde sait qu'avec Java, on a pas besoin de machine et de système d'exploitation !
votre avatar
Bon, tu ne fait qu'effleurer la surface et tu campes sur tes positions.
Si, pour toi, une réponse détaillée comme je l'ai fait, ce n'est qu'effleurer la surface... Tu dis ça parce qu'on ne s'intéresse pas à l'algo qu'il y a derrière ? Tu veux des félicitations pour quoi ? Pour le fait d'avoir 2 buffers qui contiennent la valeur courante et la valeur précédente, et que tu switch de l'un à l'autre avec un pointeur sur la base d'un modulo 2 ? Ok, félicitation.

Et il est vrai que tu ne campes pas sur tes positions non plus :eeek2:
Tu nous fais le chapitre du programmeur absolu qui ne sait pas contextualiser. Et justement, la contextualisation permet d'ajuster le code avec ce qui est nécessaire. C'est un ensemble. Pour faire tourner une application dans un datacenter la composante plateforme de production est très importante (puissance de calcul, système d'exploitation ...) dans la conception du code.
C'est là où tu fais une énorme erreur. Ce n'est pas que je ne sais pas contextualiser. C'est que ton outil, il est dispo en ligne et en open-source. Tu ne peux pas savoir COMMENT il sera utilisé, ni par QUI. (En fait, je ne devrais pas dire open source, car il n'y a pas de licence. Il est en source available).

Ne sachant ni comment, ni par qui, tu ne peux pas savoir s'il va être utilisé ou pas pour y exploiter des failles. Et je t'ai donné l'exemple d'une faille qui est présente.
Je vais faire le vieux con et j'aime pas ça : un programme ne tourne pas tout seul, il lui faut un OS et une machine pour fonctionner.
Justement ! (sur la partie en gras). Un programme ne tourne pas tout seul. Ton cas d'usage perso, pour lequel tu l'as développé, c'est peut être OK pour toi. Maintenant, je le répète :ton programme est en ligne. Du coup, tu ne peux pas savoir s'il est utilisé ou non, ni comment, ni par qui, ni dans quel environnement.

Ne sachant pas tout ça, tu dois protéger au maximum pour éviter les problèmes et les failles. Ton programme ne serait utilisé que par toi, sur ton serveur avec 16Go RAM utilisant une Debian12 à jour dont le seul accès est un SSH par clé 4096bits en utilisateur simple. Oui, ton programme suffit tel qu'il est. Sauf que ce cas d'utilisation, tu ne peux pas le garantir. C'est aussi simple que ça, et c'est ça qu'a priori, tu ne comprends pas.
Mais bon, pour ça, il faut avoir un peu plus de bagages que des formations médailles en chocolat de paramétrage de frameworks en java. Tout le monde sait qu'avec Java, on a pas besoin de machine et de système d'exploitation !
Hmmm, mon trollomètre détecte une attaque ad hominem. Et si tu apportais une réponse précise sur des bases techniques, au lieu de vouloir t'attaquer aux compétences de ton interlocuteur ?
votre avatar
Contrôle des pipes : la chaine de caractère finit dans un atoi ... qui sortira une valeur nulle au pire
Heu, non, au "pire" il y a un dépassement de buffer. Ni l'initialisation de l'array de caractères sur le stack ni le fread ne peuvent garantir qu'il y aura bien un byte nul pour terminer la string. S'il y a un byte nul, c'est par chance parce que le stack n'a pas encore réutilisé de l'espace déjà initilalisé par un appel précédent.

char Buffer[16] = "";

ça garantit juste que Buffer[0] est le caractère nul, mais ne dit rien des 15 autres, qui vont simplement récupérer ce qui traîne sur le stack.
votre avatar
En absolu, d'un point de vue purement universitaire et théorique ... tu as raison.

Mais, quand tu regardes ce pourquoi la variable va être utilisée, la plage de valeurs recues est très limitée. A vrai dire, j'aurai pu réduire la taille de la variable car la valeur la plus grande est sur 10 caractères, donc un Buffer[11] aurait fait le job.

Et pour finir avec les strings, la commande donnée au popen retourne une string, donc une série de caractères terminée par un 0 binaire. Du coup, je suis sûr d'avoir une string en bon et dûe forme dans le atoi ...

C'est dingue ce que le manque d'XP et une croyance universitaire crasse peuvent faire dire.
votre avatar
Houlà... que de certitudes qui ne se basent sur rien d'autre qu'une ignorance crasse... Et quelle belle démonstration du postulat de Dunning Kruger.

Non, passer Buffer à 11 ou une quelconque autre valeur ne changera rien à l'affaire (et je passe sur le fait que tu hard-codes la taille du buffer au lieu d'utiliser une constante...) . Le simple fait que tu le proposes prouve que tu n'as rien compris. Le problème ce n'est pas le fread qui va écrire trop loin, ce n'est pas un buffer potentiellement trop petit, c'est le atoi qui va lire trop loin car rien ne garantit que le buffer sera terminé par un zéro binaire.

Car non, la commande passée à popen ne renvoie pas une string, elle renvoie un stream de bytes que fread va mettre dans la variable Buffer. Mais cela ne constitue pas une "string" au sens C car le stream ne contient pas de zéro binaire en fin, et fread n'en mettra pas. Pour mettre un tel byte nul en fin, il eut fallu faire un truc du genre (de tête et quick-n-dirty, et pas portable car suppose que sizeof(char) == 1, mais obligé vu que tu n'as pas jugé utile de définir un constante pour la taille du buffer) :

Buffer[fread(Buffer,1,sizeof(Buffer)-1,fd)] = '\0';

Note à quel point c'est différent de ce que tu as écrit, notamment il faut lire au maximum 15 éléments de taille 1, et non 1 élément de taille 15 de façon que fread renvoie le nombre de bytes lus histoire qu'on puisse accoler un NUL en fin.

Ou alors... utiliser fgets() ???

Tout ceci prouve que tu n'as jamais écrit du code qui fonctionne autrement que par hasard et sur ta propre machine. Donc, au niveau expérience, évite de voir la paille dans l'oeil de ton voisin, ça t'évitera de passer pour un noob.
votre avatar
Tout ton commentaire ne sert à rien. Dans un exposé universitaire, tu aurais raison mais pas là.

Effectivement, si la commande lancée par le popen aurait retourné un stream sans fin de ligne ni 0 binaire, cela aurait été pris en compte (avec un p'tit memset). Cette approche plus dépouillée sert la maintenabilité. Et ta proposition est juste, mais n'aide pas la maintenance.

Mon code fonctionne car les procédures appelées forment un ensemble.

PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr.
votre avatar
$ nproc
12
$ nproc|od -c
0000000 1 2 \n
0000003

$ nproc|wc -c
3


Donc les 3 caractères sortis par nproc sont : 1 2 et \n (=0x0a)

Pas de 0 "binaire" (comme tu l'appelles) de lu en fin de chaîne quand tu lis ces 3 caractères avec ton fread.

Ce qui suit les caractères lus par le fread est indéterminé. Ce n’est pas pour rien que le fread retourne le nombre de caractères lus.

Par contre, c'est le atoi qui te sauve non pas parce que la chaîne est terminée par un 0 mais parce qu'elle est terminée par un 0x0a et que le atoi s'arrête au premier caractère différent d'un chiffre après avoir détecté le début d'un nombre.
Et ici, si la lecture du pipe s'est bien passée (ce que tu ne vérifies pas), tu auras bien ton nombre.
votre avatar
Et atoi s'arrête aussi sur le newline ... pas uniquement sur le 0 binaire.
votre avatar
Oui, c'est ce que j'ai ajouté en éditant. Mais la discussion portait sur le 0, pas le newline.
votre avatar
Le 0 binaire, j'm'en tape. C'est la conversion numérique qui est utilisée après.

S'il y avait eu utilisation des strings dans un printf par exemple, oui, il y aurait eu un memset.
votre avatar
Le 0 binaire, j'm'en tape. C'est la conversion numérique qui est utilisée après.
La spécification de atoi c'est qu'elle reçoit une string. En C une string est terminée par un NUL. Si ce NUL n'est pas là, rien ne prouve que atoi ne va pas continuer à lire les caractères qui suivent. La spec dit que atoi arrête la conversion, pas nécessairement le scan de la string. Le fait qu'atoi est implémenté par une boucle "while le catactère courant est entre '0' et '9'' est un détail d'implémentation qui est généralement valide sur une architecture X86 ou ARM, mais peut-être pas sur une architecture IBM z9, ou une encore différente qui sortira l'année prochaine. Rien n'interdit à atoi() de continuer à scanner plus loin s'il le désire. Il ne peut pas aller plus loin que le NUL mais rien ne dit qu'il ne va pas aussi lire le caractère qui suit le \n.

Maintenabilité :fou:
votre avatar
Ah oui, je commence à comprendre : tu fais du z-linux ... CàD une implémentation très IBM d'un environnement Linux (j'ai fait aussi de l'AIX et y'a des contextes où c'est pas bon à manger surtout quand il s'agit d'une appli multi-OS).

La maintenabilité justement, c'est en environnement zOS où j'ai pu voir passer les pires trucs pondus par des « barbus-plein-d'XP ».

Dans ce genre de contexte de travail, les documentations projet tiennent sur une page : Cf Machin-pas-loin-de-la-retraite-ou-déjà-parti. Et les DSI derrière qui attendent en embuscade le départ en retraite pour tout décommissionner en urgence afin que cela ne leur pète pas au nez.
Une fois, des vieux programmes Z ont été rachetés à un client et la prise en main des bouzins a été longue et dure. Plusieurs mois de reverse-engenering pour s’apercevoir qu'on aurait plus vite fait de repartir de la page blanche.

La maintenabilité efficace, par ordre de priorité pour moi :
1. Programmation structurée
2. Capacité à comprendre pour un dev extérieur et accessoirement par l'auteur lui-même
3. Cohérence d'écriture globale : va maintenir un source avec 5 ou 6 styles d'écriture différents et avec du C, ça peut faire très vite mal à la tête.
4. Mail et/ou N° de téléphone de la personne qui a l'histoire du programme en tête : mieux vaut demander à un qui sait plutôt qu'à 2 qui cherchent
votre avatar
J'admire cet art subtil de tirer des conclusions foireuses. Je ne travaille pas sur z/OS et je n'ai jamais codé pour un mainframe. Je te parle juste d'un exemple d'architecture différente pour t'expliquer qu'il n'y a pas qu'Intel qui fait des processeurs.
Capacité à comprendre pour un dev extérieur et accessoirement par l'auteur lui-même
Tu m'expliques pourquoi tu castes explicitement le résulat de atoi vers un long ? Outre que c'est inutile, ça rend le programme difficile à comprendre car celui qui le lit va devoir se demander pourquoi tu fais ça.

C'est pour la faciliter la compréhension que tu lis une string avec fread au lieu de fgets ?
Cohérence d'écriture globale
C'est pour la cohérence que la variable "Buffer" commence par une capitale, contrairement à toutes les autres variables ?
ça peut faire très vite mal à la tête.
Je confirme, ton code est indigeste
Mail et/ou N° de téléphone de la personne qui a l'histoire du programme en tête
Woaw... Bien sûr.
votre avatar
Tiens... même le makefile (trois lignes de code !!!) est foiré. T'as oublié de lister le fichier .h comme dépendance pour l'exécutable. Si tu changes un truc juste dans le .h, le make ne recompilera pas l'application. C'est bien la peine de maintenir un makefile...

Chapeau pour tes 20 ans d'XP, tu les caches vraiment bien.
votre avatar
Cette approche plus dépouillée sert la maintenabilité.
Désolé de te le dire, mais toi qui défend la maintenabilité à tout va (ça fait plusieurs fois que tu parles de maintenabilité), il y a encore beaucoup de boulot pour que ton programme soit maintenable :
- avoir des conventions cohérentes : un coup de PascalCase, un coup du camelCase, un coup du snake_case
- nommage qui laisse sérieusement à désirer ;
- utilisation de constantes en dure, au lieu de les définir via un #define ou une variable const ;
- utilisation de la virgule au lieu du point virgule pour séparer des instructions (oui, c'est valable en C, je sais, mais cela n'en est pas moins une très mauvaise pratique, surtout pour éviter de définir un bloc d'instructions dans un if ou else par exemple)
Mon code fonctionne car les procédures appelées forment un ensemble.
Comme je te l'ai déjà dit dans un précédent commentaire : ton code fonctionne pour toi, dans ton cas d'utilisation. Mais il est public (tu l'as publié sur github) et tu ne sais pas dans quelles conditions il sera utilisé.

Ton code est du pain béni pour n'importe quel hacker, mais ça, tu n'en as que faire. Pire, tu refuses ne serait-ce que de le concevoir.
PS : surconfiance avec + de 20 ans d'XP sur le sujet ... mais bien sûr. Je dirais plutôt que tu nous fais une crise d'ego universitaire.
Argument d'autorité + attaque ad hominem (encore). Peux-tu rajouter la victimisation la prochaine fois stp, histoire de varier les procédés rhétoriques ?

Ou plus simplement, avoir de vrais arguments pour défendre ton point de vue. Merci d'avance ;)
votre avatar
Mon dieu !
Je n'ai pas utilisé les conventions normées.

Oui, c'est publié sur github et tous les script-kiddies de passage vont l'utiliser pour coller le boxon sur internet parce que c'est pas dans les normes des gardiens de la méthode.
votre avatar
Je me suis amusé à le compiler et à le lancer, histoire de voir. Toi qui est si fier de ton programme, sache qu'il génère 8 warnings avec gcc 9.4 (je croyais qu'il fallait les éviter ? C'est en tout cas ce que tu demandais commentaire 6.31 (je ne l'invente pas).

Et le comble, c'est que ton programme se termine par un beau segmentation fault à l'exécution.


Current Minimum Maximum
Core 0 : Khz Khz Khz
Core 1 : Khz Khz Khz
Core 2 : Khz Khz Khz
Core 3 : Khz Khz Khz
Core 4 : Khz Khz Khz
Core 5 : Khz Khz Khz
Core 6 : Khz Khz Khz
Core 7 : Khz Khz Khz

Total : Khz Khz Khz
Average : Khz Khz Khz

Nb Mini :
Nb Maxi :

Extr. Min: Khz Khz Khz
Extr. Max: Khz Khz Khz
Segmentation fault


(tu m'excuseras, je me suis contenté d'un copier/coller de la console, je n'ai pas envie de m'amuser à héberger une image pour ensuite la coller ici).

Alors, tu peux dire tout ce que tu veux de ton programme, tu ne peux pas lutter contre les faits.

Le plus drôle dans tout ça, c'est que j'ai trouvé un buffer overflow exploitable, et que je voulais justement le compiler/tester pour vérifier, mais que je n'ai même pas eu à le faire, car ton programme plante de lui-même.

J'applaudie, à 2 mains, les 20 ans d'expérience mis avec tant de valeur dans ton commentaire précédent :top:
votre avatar
Ok ... (t'es content ?)
votre avatar
Il faut que tu comprennes une chose : que ton programme fonctionne ou pas, je m'en fiche totalement (et ceci le plus sincèrement du monde et sans vouloir te manquer de respect).

Ce que j'essaie de te dire (et d'autres aussi), c'est que ton comportement arrogant vis-à-vis de ton programme est une des plaies quant à la sécurité des programmes d'aujourd'hui. Rust (que je n'apprécie pas vraiment, je trouve sa syntaxe illisible) empêche, de par sa conception, les principaux pièges qui constituent la majorité des failles (une étude révélait, par exemple, que la majorité des failles de sécurité dans des programmes C étaient dues à des buffer overflow).

Le pire, c'est que non seulement tu n'arrêtes pas de dire que ton programme est bien pensé, mais qu'en plus, tu te montres plutôt méprisant (pour ne pas dire insultant) envers celles et ceux qui ne seraient pas d'accord avec toi.

Du coup, je ne peux qu'abonder dans le sens du commentaire 14 de Stephane Bortzmeyer (sauf le côté virilisme que je n'ai pas trop compris dans son propos), où, désolé de te le dire, ton comportement est l'archétype même de ceux qu'il dénonce.
votre avatar
Dans le "t'es content ?" ... il fallait comprendre que je salue tes efforts pour prouver ton point de vue. Je salue également tes capacités de recherche d'un environnement suffisamment vétuste te permettant de prouver tes dires : la version 9.4 de GCC a été mise à jour pour la dernière fois en juin 2021. Pour te dire, même la vieille LTS Ubuntu 22.04 installe de base GCC 11 et propose GCC 12.
Au quotidien, je tourne en GCC 13.

« Le pire, c'est que non seulement tu n'arrêtes pas de dire que ton programme est bien pensé, mais qu'en plus, tu te montres plutôt méprisant (pour ne pas dire insultant) envers celles et ceux qui ne seraient pas d'accord avec toi. »
Je reste dans le ton des commentaires qui ont été faits. L'arrogance dont tu me crédites n'est ni plus ni moins que celle avec laquelle tu as entamé les débats.

Pour le virilisme, bien vu, je n'avais pas rebondi sur son commentaire.
Disons que le monsieur ferait bien d'aller faire un stage dans une équipe projet au sein d'une ESN pour voir comment ça se passe dans la vraie vie.
Non, tous les devs ne sont pas nuls (y'en a quand même), les conditions de réalisation des projets, par contre, sont pour beaucoup dans la dette technique des applis (et donc les CVEs créées ou non corrigées ...). Dans ces conditions de réalisation, de manière non exhaustive, on y trouve les comptables gérant à date d'échéance, un turn-over de compétition, des affectations de développeurs sur des périmètres dépassant leur niveau d'expérience, un client girouette, etc ...
votre avatar
Dans le "t'es content ?" ... il fallait comprendre que je salue tes efforts pour prouver ton point de vue. Je salue également tes capacités de recherche d'un environnement suffisamment vétuste te permettant de prouver tes dires : la version 9.4 de GCC a été mise à jour pour la dernière fois en juin 2021. Pour te dire, même la vieille LTS Ubuntu 22.04 installe de base GCC 11 et propose GCC 12.
Au quotidien, je tourne en GCC 13.

Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows :eeek2:)
Je reste dans le ton des commentaires qui ont été faits. L'arrogance dont tu me crédites n'est ni plus ni moins que celle avec laquelle tu as entamé les débats.
On pourra se la jouer court de récré, car bizarrement, en relisant nos premiers échanges, je n'ai pas du tout la même interprétation que toi. Je t'avoue qu'après un "script kiddy" et "une médaille en chocolat dans le paramétrage Java", j'ai commencé sans doute à être un peu moins sympa, sans pour autant tomber dans des attaques ad hominem. Je préfère toutefois laisser aux lecteurs se faire leur propre opinion à ce sujet.

Pour ma part, je pense que l'on peut clore la discussion, le tour ayant été fait sur le sujet.
votre avatar
« Si tu crois que j'ai "recherché" un environnement vétuste... ben non. J'ai juste pris la première VM que j'avais sous la main (car oui, ma machine principale est sous Windows) »

Une VM en WSL je suppose ?
votre avatar
Cela aurait été mesquin de ma part de ne pas prendre un vrai linux...
votre avatar
Pareil. Quand j'ai vu les warnings (un %d dans un printf pour formater des long) j'ai pas été plus loin. De toute évidence, sur son architecture les long et les int ont la même taille... C'est probablement pour cela que sur sa machine à lui il n'y a aucun warning. Et comme "pas de warning = programme OK", tout roule.

Et puis comme dit si bien alex.d ailleurs dans le thread, y'a pas de vulnérabilité dans printf :D
votre avatar
Ah mais non scacrebleu ! Si j'ai des warnings, il est totalement inenvisageable que cela vienne du code. C'est à cause de la version obsolète de GCC, que je suis allé volontairement chercher pour accréditer mes dires :stress:

Plus sérieusement, tant qu'il y aura des dev avec ce genre de mentalité, les CVE ont de beaux jours devant eux :craint:
votre avatar
Si tu tiens vraiment à jouer à kikalaplugrosse, ça fait 38 ans que je fais du C professionnellement.

"Cette approche dépouillée" mon dieu... Ce n'est pas une approche dépouillée/

Quant à la ligne suivante où tu castes explicitement le résultat de atoi vers un long, tout ça pour retourner le nombre de processeurs (qui ne devrait en toute logique pas dépasser 65535 dans le meilleur des cas...) oui de fait ça respire 20 ans d'expérience... Vingt ans de cut-n-paste de code que tu ne comprends pas.
votre avatar
Dans le document de la Maison Blanche, Rust est le seul exemple cité. LMI indique bien que Rust est cité, et que c'est un autre document de la NSA qui évoquer les autres langages (Swift, C#, etc.).
votre avatar
La seule mention à Rust dans le rapport de l'ONCD est pour dire que RUST qui est un exemple de langage sûr pour la gestion mémoire n'a pas été "prouvé" pour systèmes spatiaux.
votre avatar
Le rapport PDF ne parle pas que des langages de programmation: https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

Il parle aussi de "Memory Safe Hardware" (CHERI est cité en exemple: est-ce que Next a déjà fait un article sur le sujet?)
et de "Formal Methods".
votre avatar
Quand on commence à dire que "le C présente des vulnérabilités", c'est qu'on n'a pas compris quelque chose. Autant demander d'interdire les couteaux qui n'ont pas de mécanisme pour empêcher de se couper les doigts.
votre avatar
Le rapport ne dit pas que le C présente des vulnérabilités, il dit par contre qu'il y a beaucoup plus de vulnérabilités dans les logiciels écrits avec un langage qui n'est pas sûr pour la gestion de la mémoire comme le C ou C++.
votre avatar
L'article dit texto : "l'ONCD cite le C et le C++ comme deux exemples de langages présentant des vulnérabilités".
votre avatar
QCM;

1. C/C++ est vulnérable aux risques d'une mauvaise gestion mémoire.
2. C/C++ est invulnérable aux risques d'une mauvaise gestion mémoire.

Votre réponse: ___
votre avatar
Oui, l'article dit ça, mais c'est faux. Vérifie dans la source si tu veux.
votre avatar
Disons que statistiquement, avec le C, il est probable de se couper les doigts en l'utilisant sur un gros projet.
votre avatar
Ce genre de réaction explique pourquoi des autorités comme la Maison-Blanche estiment nécessaire d'intervenir. Manifestement, il y a des développeurs qui nient la réalité. (Regardez autour de vous tous les dispositifs de sécurité dont aucun n'est parfait. On les supprime ?)
votre avatar
Le C est un langage qui permet d'écrire du code vulnérable. Mais il n'y a pas de vulnérabilité dans le langage.

Après, il faut utiliser le bon outil pour la bonne tâche. Le C n'est pas la bonne solution dans tous les cas, mais il est erroné de vouloir déconseiller l'usage du C dans tous les cas.
votre avatar
Heu si, il y a des vulnérabilités en C. Le fait qu'on puisse prendre l'adresse d'une variable qui contient un pointeur et caster vers autre chose permet de modifier arbitrairement la valeur d'un pointeur, ce qui interdit de structurer les pointeurs pour les rendre ne fût-ce qu'un peu plus safe. Le fait qu'une variable déclarée sur le stack et non explicitement initialisée contient n'importe quoi y compris un pointeur vers de la mémoire non allouée. etc. Et je ne parle même pas des antiquités K&R qui ne vérifient même pas le type des arguments d'une fonction, ce qui a permis l'émergence de la fonction standard printf() qui est une mélodie à elle toute seule.
votre avatar
La vulnérabilité n'est pas dans le langage, mais dans la façon de s'en servir. Ton exemple printf() est très mal choisi. Si tu veux citer une vrai vulnérabilité, alors parle plutôt de gets() (qui pour le coup est une vraie faille, mais la fonction est déprécié depuis longtemps).
votre avatar
On parlait d'une vulnérabilité dans le langage, pas dans la librairie standard.

gets() est une vulnérabilité exclusivement due à la librairie standard (il manque 'juste" la longueur du buffer dans les arguments - problème que n'a pas fgets)

Par contre le fait d'avoir des arguments quelconques sans aucun contrôle de type (ni même d'implémentation portable avant l'avènement de la notation va_args) pour permettre le fonctionnement de printf (ou scanf si tu y tiens vraiment...) est bien une caractéristique du langage.
votre avatar
Tout ça, ça date d'avant C89, c'est de la préhistoire. Plus personne n'utilise ça. La version par défaut dans le gcc actuel est C11.
votre avatar
Plus personne, sauf les gens qui maintiennent du code legacy. :phiphi:
votre avatar
Il faut bien regarder le rapport de l'ONCD, et du contexte dans lequel Rust est évoqué qui est assez précis puisqu'ils évoquent le matériel sécurisé de l'aérospatial. Ils énumèrent les critères suivants concernant les besoins des langages de programmation pour ce contexte:

- langage proche du matériel
- délais exécution à timing déterministe (adapté au temps-réel, pas de garbage collector)
- gestion sécurisée de la mémoire

On peut considérer que:

Le premier critère disqualifie les langages interprétés comme Js, Python, Java, ...
Le second exclue C#, go, V, et tous les langages utilisant impérativement un garbage collector
Le troisième exclue l'assembleur, c et c++

Rust est juste cité comme un exemple de langage correspondant à ces trois critères mais n'ayant pas encore fait ses preuves dans l'aérospatial.

D'autres alternatives intéressantes, correspondant à ces critères mais non citées sont par exemple ADA (vénérable langage très implanté dans l'aérospatiale), D (si on désactive le GC) , Zig, Swift, Ordin
votre avatar
Les deux premiers critères ne portent pas sur le langage lui-même, mais son implémentation. Il est possible de compiler nativement du Js ou du Java. Et rien n’empêche d'implémenter le Java sans un garbage collector, mais avec mécanisme similaire au Rust. D'ailleurs, il existait (ou existe encore) des bidouilles pour gérer la mémoire soit-même en Java.
votre avatar
Même la 3è pourrait être réglée au niveau de l'implémentation.

Pour le GC de Java il y a Epsilon, mais je n'ai pas encore pu me faire une opinion...

Faire des mécanismes similaires à Rust en Java? non, impossible, la notion de borrow qui est cruciale dans le modèle Rust et qui oblige les devs à explicitement gérer le cycle de vie des variables quand elles sont passées à des fonctions casserait tout.

Pour le reste l'objectif n'est pas de gérer la mémoire sois-même, c'est même tout le contraire.
votre avatar
Les zindiens et les pakpak ont ils eu connaissance de ce rapport ? :D
votre avatar
Ils écrivent en C ou C++ les Indiens ? Il me semblait qu'ils utilisaient beaucoup JAVA qui n'a pas de vulnérabilités liées de gestion mémoire.
votre avatar
votre avatar
« Je rêve d'avoir un CVE à mon nom. »
votre avatar
Le Cobol vaincra ! :phiphi:

==> Vers l'infini
votre avatar
C'est toujours la même histoire. On dit que PHP n'est pas "sécure" quand un mec arrive à rentrer sur un système. Sauf que la faille était dans Apache. Des amalgames comme celui-ci on en verra jusqu'à la fins des temps.

Si les dispositifs de verrouillage ne sont pas suffisamment implémentés dans un langage, c'est peut-être au développeur de faire un peu plus propre, d'effort. Et d'en finir avec les bêtises du genre "(en Java) ho non faut pas utiliser GC!". Et ce n'est pas la seule qu'on peut entendre.

Ce qui me fait tiquer ce n'est pas la promotion déguisée de ces langages c'est pourquoi la maisons blanche s'immisce dans ces affaires. Y'a pas de fumé sans feu.
votre avatar
Pour moi, c'est légitime que des organismes gouvernementaux chargés de la cybersécurité donnent des avis sur les technologies à utiliser. Ce serait une gestion désastreuse de leur part que de ne pas s'intéresser aux éléments qualitatifs de ces investissements qui se font aux frais du contribuable et qui peuvent impacter la sécurité de la nation.
votre avatar
C'est toujours la même histoire. On dit que PHP n'est pas "sécure" quand un mec arrive à rentrer sur un système. Sauf que la faille était dans Apache. Des amalgames comme celui-ci on en verra jusqu'à la fins des temps.
Peut être parce qu’il est infiniment plus facile d'exploiter une faille dans un code PHP (écrit à la va vite souvent open source) qu'une faille d'un Apache à jour.
votre avatar
Oui alors encore faut-il qu'il soit à jour l'Apache. La culture informatique des entreprises en France me fait douter. Même pour les plus gros. Ca fait peur même.
votre avatar
C'est sûrement vrai mais j'ai quand même l'impression que ça change (le : c'est de la prod, ça marche, pourquoi j'irai m'emmerder...).
J'arrête pas de le dire autour de moi : tu veux de la sécu ? Soit à jour !
votre avatar
Eh bien, si vous vous demandez pourquoi, en 2024, la sécurité informatique est toujours mauvaise et qu'on empile les CVE, lire cette discussion vous aidera à comprendre. Négationnisme (C n'a pas de faiblesses de sécurité), rejet de la faute sur l'utilisateur ou le programmeur, virilisme (c'est le développeur qui était nul), etc.
votre avatar
Et bien sûr le classique, la grande majorité des gens qui commentent le rapport ne semblent pas l'avoir lu.
votre avatar
virilisme (c'est le développeur qui était nul)
https://fr.wiktionary.org/wiki/virilisme
(Politique) Idéologie prônant la virilité comme valeur supérieure pour le genre masculin

??
votre avatar
Quand j'ai lu l'article et que j'ai vu 100+ commentaires, c'était couru d'avance. Je déplore énormément la moyenne d'âge que Next n'arrive pas à réduire, ce qui me fait ressentir de plus en plus un "effet Facebook", autant dans le côté reac' que dans l'humour des commentaires.

Rien d'insultant ou de provocateur, c'est juste factuel. Mais bon, d'habitude, le fait de dire ça fait justement réagir cette même communauté de manière très virulente :D !
votre avatar
Tu me donneras ton truc pour connaître l'âge d'un intervenant en lisant ses commentaires quand il ne donne pas d'indice daté.
Comme disait Brassens, "le temps ne fait rien à l'affaire".

Je te laisse trouver le reste des paroles.
votre avatar
Et voilà, qu'est-ce que je disais. J'aurais même pu parier sur toi pour la réponse... :D

Au bout d'un moment, stoppons tout de suite la mauvaise foi. On retrouve toujours les mêmes personnes en commentaire, et l'estimation qu'on peut se faire se confirme à chaque fois qu'une actualité nostalgique apparaît et où ça balance des âges ou des anecdotes datées (toi y compris).

Encore une fois, rien de méchant ou d'incisif, je souhaite pas vous voir partir hein, merci d'être là et de soutenir Next même. C'est juste dommage de ne pas avoir une communauté plus hétéroclite, avec des expériences et des générations autant représentées à parts égales, surtout sur un thème comme le numérique ou ce serait largement faisable.

Suffit de voir les réaction déjà à mon message pour voir que je ne suis (heureusement) pas le seul à penser ça. Next avait parlé de travailler la vidéo en 2024 pour essayer de rajeunir un peu la communauté. J'attends ça avec impatience.

PS : pour finir sur un aspect taquin, tu cites du Brassens. Si ce n'est pas suffisant comme élément pour définir le côté boomer... :non:
votre avatar
Et moi, je te dis que les réactions des gens n'ont rien à voir avec l'âge.

Perso, je suis dans le camp de ceux qui pensent que le C (et donc le C++) posent des problèmes liés à l'utilisation de la mémoire et que le rapport de la Maison Blanche est pertinent.
Je suis sûr qu'il y a ici plusieurs personnes plus jeunes que moi qui disent le contraire.

Mais j'ai vu trop de logiciels qui ne libéraient pas leur mémoire après usage, entraînant des fuites, trop d'utilisation d'un pointeur après libération de la mémoire, trop d'écritures au delà de la mémoire allouée et j'en passe pour penser que le C est un bon langage sur ces points.
Alors, oui, c'étaient peut-être de mauvais développeurs comme diraient certains ici, ils étaient plutôt moyens mais un langage doit être robuste à la moyenne des développeurs.
votre avatar
100% aligné sur cette vision. Mon commentaire était plus général et pas concentré uniquement sur cette actualité. Parfois, ça manque juste de représentation. :kimouss:
votre avatar
La Maison-Blanche exhorte…
Quand j'ai commencé dans l'informatique ON parlait (sans exhorter) du COBOL en fin de vie, Aujourd'hui retraité (moi) mais le canard (Cobol) est toujours vivant !
:francais: Dans une trentaine d'années ON parlera toujours de l'abandon du C ! :rem: (Comme pour le Cobol, il y a trop de milliards de lignes de C en service pour prendre le risque de démarrer des campagnes de changements)
votre avatar
Il y a beaucoup de vulnérabilités liées à la nature du COBOL ?
votre avatar
Ca fait longtemps que je ne fais plus de COBOL, il autorise désormais aussi les pointeurs hélas, mais en tout cas les attaques seront différentes et probablement moins efficaces (dans le cadre de la gestion de mémoire) mais surtout en raison de l'OS sous-jacent (z/OS) qui ne fonctionne pas comme Windows ou Linux.

Mais bon, écrire un driver d'imprimante Windows en COBOL, faut aimer le sport.
votre avatar
Je me lance

DATA DIVISION.
77 CURRENT-LINE PIC X(132).

Le reste c'est juste un détail...
votre avatar
Comme quoi le COBOL a du bon.
La France a même pris une mesure EXCEPTIONNELLE de passer la retraite à 64 ans pour conserver ses programmeurs :D
votre avatar
Je ne réponds pas a l'article, mais a plusieurs commentaires.

Il n'est pas nécessaire de modifier tous les logiciels, seulement ceux critiques, comme les noyaux de systèmes d'exploitation, les connecteurs réseaux, le décodage logiciel des codecs vidéo/audio, enfin tous ce qui concerne une entré/sortie réseau ou une interprétation d'un code importé (navigateur web, TCP/IP, TLS)

Il n'est pas du tout nécessaire de tous refaire. Par exemple, le noyau Linux à ajouté le support de Rust, pour le moment cela est utile pour quelques pilotes nouvellement développés.
votre avatar
Je ne serais pas si optimiste que toi sur le nombre de logiciels à réécrire.
Le dépassement de tampon (ou celui de tas) peut se produire dans tout logiciel qui traite des données qui viennent de l'extérieur et ça fait un sacré paquet de logiciels !

Mais comme dit par d'autres, le conseil de changer de langage de programmation est pour les nouveaux logiciels. Il n'est pas de tout réécrire.
votre avatar
Cool, donc pour que ce soit super safe suffit du port d'arme et de dev en RUST.

Mais bon ok, sauf qu'un programme c'est souvent des librairies externes et je ne pense pas qu'elles puissent toutes être remplacées si simplement.

Puis réécrire un programme... Faut avoir la chance d'avoir ou du code hyper bien commenté ou/et de la doc fonctionnelle vraiment à jour et bien écrite.

M'enfin y'aura bien une IA pour nous convertir du code directement non ?
votre avatar
Juste pour l'illustration.

En C/C++, on risque des effets de bords à cause de pointeurs "unsafe". Il y a des analyseurs statiques qui permettent de suivre un peu ces erreurs, et de bonnes pratiques à acquérir.

En Javascript, on risque ... les erreurs liées à la portée, et beaucoup d'erreur de synchro/parallélisme/exécution dans un ordre pas forcément voulu + des problèmes de mémoire qui enfle, au pire l'injection directe de code.

En C#/Java, voici ce que j'ai pu subir: l'utilisation de la sérialisation/désérialisation à outrance ... y compris en stockant dans les cookies... Magnifique travail, CVE car on peut injecter ce qu'on veut comme code dans le cookie, et il est exécuté par le serveur sous son login de serveur web.

Niveau faille, je dois avouer que tout langage a les siennes. Les programmeurs sont (souvent par fainéantise/pression du temps) très prolifiques.

Mais je trouve tout de même que Rust a de très bon atouts pour forcer de bonnes pratiques. Il est un bon compromis de principe déjà éprouvés dans d'autres langage (d'où le nom il me semble d'ailleurs). Mis à part la syntaxe de %$§!, c'est un bon produit.
votre avatar
Une recommandation pleine de bon sens, même si ça ne se fera pas du jour au lendemain, et que j'avoue avoir un faible pour la simplicité et l'universalité du C après m'y être remis "pour tester" il y a quelques années.

La Maison-Blanche exhorte les développeurs à abandonner C et C++ pour Rust

Fermer