Discussion :

[commandantFred]

Juste que Rust n'a rien inventé, je n'y peut rien, ce sont les faits.

(...)
Donc le gars de la maison blanche qui demande à plusieurs millions de développeurs d'arrêter d'utiliser le C / C++ pour "des langages qui protègent mieux la mémoire", j'ai difficile de le prendre au sérieux. Il ne vas pas se permettre de dire aux ingénieur de boeing de faire correctement leur boulot, mais les dev, on peut les mettre à toutes les sauces, on trouve ça normal.

Bon, BàV, Peace and Love.

Ok avec tout ça. C'est la jungle, terrible jungle.

Après, je ne sais pas si tu as remarqué mais avant de bien comprendre une technologie complexe, on a une période d'acceptation où il est sans doute nécessaire de nier le problème. Puis on dort un bon coup dessus et tout rentre dans l'ordre. (courbe d'apprentissage)

L'univers pro que tu me décris ressemble à celui des ssii où les commerciaux te placent là où ils ont de la demande... Je n'ai plus connu ça depuis longtemps mais je me rappelle que c'était stressant. Les premiers jours d'une mission sont toujours déstabilisants.

Un truc sur les fonctions de 25 lignes : dans les assurances, j'en ai fait une de +9000 lignes. Un process de calculs en cascade qui permet de trouver le montant d'une prime (d'assurance)
Ben si je l'avais divisé en plein de fonctions qui se suivent, ça aurait plutôt tout embrouillé puisqu'il fallait passer par toutes les requêtes SQL pour faire péter les triggers, on ne pouvait pas fractionner ce calcul.

J'en ai fait d'autres moins grosses mais quand même bien longues. Toujours dans l'assurance, la constitution d'un flux EDI dépassait 2000 lignes. Idem, process non interruptible.

Cette règle des 25 lignes, je l'ai lue autrefois mais parfois , elle semble d'un autre monde.
Tant que l'éditeur n'explose pas... Ce me semble plus lisible de mettre des gros titres avant chaque traitement de la séquence et sauter au moins 2 ou 3 lignes entre chaque...

Pour la longueur des lignes , d'accord à 100%

Les styles divergent, y'a des gars qui mettent des pages de commentaires pour 5 lignes de code. Puis rebelote big commentaire encadré avec des gros '#' et 3 petites lignes...

[Uther]

Quant on a une base de code, écrite en C, qui est utilisée depuis de 20 ans sans le moindre soucis, rien que le fait de la réécrire sera plus dangereux que de garder ce qui fonctionne depuis des années.

Il faut arrêter de laisser entendre que l'on va forcer les gens a réécrire en urgence en Rust toutes les applications existantes. Personne de sérieux ne l'a jamais demandé. Ça serait juste idiot et impossible en pratique. Bien sûr que le C restera encore longtemps le langage avec la plus grosse base de code en production.
On demande juste de préparer les gens pour permettre de faire une transition vers des langage sûr là ou ça a du sens. Rust sera utilisé surtout dans des nouveaux projets où des refontes déjà envisagées.

Je ne suis pas contre Rust, mais j'ai du mal a penser qu'il peux régler tous les soucis, d'une variété d'utilisations énorme (de l'embarqué aux gros sites Web qui doivent être hyper sécurisé).

Ça tombe bien, Rust ne prétend pas résoudre tout les soucis du monde : il prétend surtout de résoudre les soucis de sureté mémoire dans les applications qui nécessitent de la performance et du contrôle bas niveau. Dans ce type d'application, la sureté mémoire est quand même la cause de la grande majorité des vulnérabilité graves.

Si on veut sécuriser le web, le problème à résoudre se situe plus au niveau des frameworks web que du langage.

Les vrais soucis viennent plus souvent des technologies "du Web", que du code de bas niveau. Je n'ai jamais voulu faire du dev Web, car de ce que je vois, rien n'est jamais vraiment stable dans cet écosystème. Ce qui était adulé il y a 1 an, et jeter aux ordures, pour le nouveau "framework" à la mode. Des couches, sur des couches à n'en plus finir, qui sont souvent écrites par des dev peu expérimentés, ça peut vite créer des soucis, je le comprend très bien.

C'est des problèmes assez orthogonaux. Le dev web pose des problématiques de sécurité spécifiques (Injection, XSS,...), plutôt rares voire inexistants pour un développement bas niveau. Et inversement, les problématiques de sureté mémoire ne se posent pas trop dans le développement Web, pour la simple raison que les langages qu'on utilise traditionnellement pour ça sont déjà memory safe.
Par contre, si on faisait du web en C, on cumulerait les deux sources de problème.

https://en.wikipedia.org/wiki/Cyclon...ming_language).
Il s'agit d'une version plus Safe du C: Il y est mentionné que Rust y a puisé pas mal d'idées.
Pourquoi ça n'a pas pris à l'époque, je ne sais pas.

En effet, Cyclone est un langage que les créateurs Rust citent souvent dans leurs influences, ainsi que le ML. Le concept de lifetime explicite vient clairement de Cyclone. S'il n'a pas pris, c'est sans doute qu'il s'agissait avant tout d'un projet de recherche qui n'avait pas vraiment pour vocation d'être utilisé en l'état, développé à une époque où la sécurité des logiciels bas niveau n'était pas une préoccupation première.

Rust ne prétend pas avoir inventé quoique ce soit de foncièrement nouveau. Le titre de la première présentation officielle du projet Rust par son créateur original était même : "Technology from the past come to save the future from itself".
Même les concepts de ownership et lifetime, qui font la particularité de Rust, ne sont pas nouveaux en soi : c'était de règles de bonne pratique en C. Le problème étant qu'il peut y avoir des erreurs dans leur mise en pratique. Ce qu'apporte Rust à ce niveau, c'est que le compilateur garanti leur bon usage de manière à ce que l'on ne puisse pas causer d'accès mémoire invalide.

Encore une, je n'ai rien contre Rust, mais les notion de Owner/lifeTime etc, ça me semble plus compliqué que de de savoir faire correctement un malloc et un free.

C'est en effet plus compliqué, surtout au début, mais au final on s'y habitue. Par contre, on à la garantie que ça sera toujours bien fait, alors que l'on peut très bien savoir comment bien gérer un malloc et quand même se planter.
Si on veut un analyseur statique qui traite tous les cas, on finit par réinventer Rust en moins bien.

[OuftiBoy]

J'entend tes arguments, je n'ai jamais connu le monde des assurances, ni les contraintes que ça impose, donc, comme je ne sais pas, je ne dis rien sans savoir.

Oui, les 25 lignes, ça vient d'une autre époque, eu du fait que les écrans sous DOS et les terminaux avant avait une résolution de 80x25 lignes, et l'avantage que ça a, c'est que tu réfléchis intérieurement à un problème, avoir l'ensemble du code de la fonction sous les yeux, ça me permet de rester concentrer. Je peux parfois rester des heures devant ces 25 lignes, et en arrière plan, mon cerveau (enfin, ce qu'il reste maintenant) turbine à 1000%. Comment réduire et/ou simplifier la chose, comment la rendre plus lisible, compréhensible.

Les commentaires ne me gênent pas, tant que la fonction (le code) reste visible sur un écran. Je dis 25 lignes, mais ça peut monter jusqu'à 35, ça dépend du nombre de ligne que l'éditeur peut me montrer. Et puis y'a commentaire et commentaire. Normalement, si la fonction est bien nommée, ainsi que ces paramètres (le moins possible) sont eux aussi explicite, et le code bien écrit, y'a pas vraiment besoin de commentaire. Mais je m'en sert surtout pour visuellement séparer les fonctions d'un module et/ou d'une classe.

Les lignes de 600, ça je l'ai vécu. Le mec trouvait ça normal. Puis un jour, le projet partant à la dérive (encore pleins de fonctionnalités a implémenter et le CPU était chargé à 90% et presque plus de RAM), on me demande d'aller jeter un œil sur la "chose". Je n'ai trouvé que des monstruosités, des trucs inimaginables. Un bordel incroyable dans le code, des "task" (on avait un RTOS) qui jouait avec des sémaphores, eux-mêmes intercepté dans une autre "task" pour, au final relancer la première "task". Bref, c'était a pleurer. des commentaires, il y en avaient, mais n'étaient pas vraiment à jour par rapport au code. Mais bon, puisque j'étais là, autant faire le ménage. 3 jours plus tard, le gars revient (il avait pris qlq jour de congé). Il a quand même été content de retrouver un CPU chargé à 25%, et plus de la moitié de la RAM était redevenue disponible.

voilà le genre de chose qui arrive qd on ne réfléchit pas longtemps avant de coder...

Oui, je suis d'une autre époque, j'ai fait mes gammes sur un commodore64 :-) Il en reste de vieux réflexes, peut-être suranné, mais ça m'a toujours permit, en respectant quelques règles "de la même époque", d'avoir en toute circonstance, un code "court", ou chaque fonction fait clairement ce qu'elle doit faire, et je mets les commentaires qu'on m'impose de mettre, pour la génération d'une documentation, qui n'a jamais été ouverte. Par contre, je suis l'emmerdeur de première qd une spécification n'est pas clair. Ou début, les nouveau chefs de projets qui arrivaient, se plaignait que je coupais les cheveux en quatre, mais après quelques années a travailler avec eux, la plupart était convaincu que j'avais la bonne méthode. Il m'arrive même souvent d'attendre quand je "sens" que ce qu'on me demande de faire n'est pas la bonne solution. Et très souvent, le gars revient en me disant, "j'ai réfléchis à ce que tu m'as dit, t'as peut-être pas tord." Et bien souvent, on se mets alors à 2 et on réfléchit au problème, on est critique l'un envers l'autre, le ton monte parfois. Mais au final, c'est de ces échanges que vient la solution. Après, le code c'est pas la partie la plus difficile (dans mon domaine).

La difficulté, c'est de voir ce qu'on peut tirer comme informations que quelques capteurs nous donnent, et comment réaliser une fonctionnalité avec finalement très peu de marge de manœuvre. Des fois, ça marche "en laboratoire", mais c'est sur le terrain qu'on découvre des limites, des perturbations lié à l'environnement. Avec le temps, on finit par anticipé, et c'est normal qu'un nouveau dev doit prendre du temps pour comprendre toutes ces contraintes. Je pense que c'est assez éloigné du monde des assurances :-)

Mais 9000 lignes, c'est pas un record. J'ai vu 10000 lignes une fois. Je dois avouer que c'est un peu plus complexe a appréhender :-/
Je pense que je ne serais pas un bon dev pour ton assurance...

BàT, et P&L.

[OuftiBoy]

Oui, je suis globalement d'accord avec tes réponses. C'est parfois compliqué pour moi de correspondre via des échanges par post interposé. On discute bien mieux avec quelqu'un quand on est face à face.

Je pense que tu as commencer a comprendre "mon point de vue", et que je commence a comprendre le tiens :-) Le tiens, mais bon, on est humain, même si on est dev. Chacun vois midi à sa porte :-)

Des fois je monte un peu dans les tours, mais je suis comme ça, c'est mon côté "sanguin". J'ai apprécié que tu reconnaisses que tu t'était trompé de personne, et demander Pardon. J'accepte volontiers. L'échange constructif et argumenté, c'est qd même plus chouette. J'essaye de mettre en perspective mon point de vue. Des fois, en voyant la même chose, mais d'un angle différent, on ne comprend pas la même chose.

C'est pour que je prend souvent des analogies comme exemple. C'est une manière de parler d'un même problème sous un autre angle, de sortir de notre bulle, de lever les yeux au-dessus du guidon. Et puis, suivant le parcours, on est plus ou moins sensible à certaines choses.

BàT. et... P&L.

[KsassPeuk]

Ce qu'apporte Rust à ce niveau, c'est que le compilateur garanti leur bon usage de manière à ce que l'on ne puisse pas causer d'accès mémoire invalide.

Et même ça, en soi, c'est pas si nouveau, le typage linéaire et les permissions fractionnaires, ça a été développé avant Rust pour des besoins similaires : faire de la vérification de sûreté de fonctionnement.

C'est en effet plus compliqué, surtout au début, mais au final on s'y fait. Par contre on à la garantie que ça sera toujours bien fait. Parce qu'on peut savoir comment bien gérer un malloc et quand même se planter.
Si on veut un analyseur statique qui traite tous les cas, on finit par réinventer Rust en moins bien.

En moins rapide, en moins intégré, oui. En moins bien, il faut voir les outils de logique de séparation savent bien gérer ça et acceptent a priori plus de cas que Rust.
Par contre c'est sûr qu'il faut se palucher la preuve à la pogne.

[mith06]

Heureusement que google est la pour sécuriser le code (écrit en C) du micro contrôleur de mon vibromasseur de ma télécommande.

[OrthodoxWindows]

Quel est votre avis sur le sujet ?

Que je commence à en avoir marre de cette polémique stérile est inutile.
Chaque langage à ses qualités et ses inconvénients, surtout chez les langages de bas-niveau. Si Rust s'impose pour les domaines où la sécurité est la plus importante, tant mieux.
Mais je ne voit pas pourquoi des langages ayant des qualités largement confirmés comme le C et le C++ disparaîtrait.

Par contre je ne serait pas contre un débat sur la pertinence de certains langages de haut-niveau utilisés à tord et à travers... Avec des performances de plus en plus catastrophiques.

[Pyramidev]

2) l'UTF-16 c'est 2 octets par caractère. En C, tu as le nouveau type wchar_t et tout 1 pan de la bibliothèque standard a été refaite pour supporter l'UTF-16.
Le problème, c'est 1 caractère peut-être soit 1 caractère (2 octets) soit 2 caractères (4 octet). Ce sont les "surrogate pairs"
Par exemple, c'est soit 'é' (e accent grave) soit 'e' + '\'' (e + l'accent grave).

Concernant l'exemple avec "é", ce n'est pas vraiment ça. Un caractère dans le sens "groupe de graphèmes" peut se décomposer en un ou plusieurs points de codage Unicode. Il peut aussi y avoir plusieurs manières de représenter un caractère. Par exemple, "é" correspond soit à un seul point de codage, soit à deux dont le premier qui correspond à "e" et le deuxième, "◌́", qui ajoute un accent aigu.
En UTF-8, un point de codage fait 1, 2, 3 ou 4 octets.
En UTF-16, un point de codage fait 2 ou 4 octets. Quand il fait 4 octets, on l'appelle une "surrogate pair".
En UTF-32, un point de codage fait 4 octets.
L'article suivant résume bien certaines subtilités d'Unicode : The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)

[Uther]

Des fois je monte un peu dans les tours, mais je suis comme ça, c'est mon côté "sanguin". J'ai apprécié que tu reconnaisses que tu t'était trompé de personne, et demander Pardon. J'accepte volontiers. L'échange constructif et argumenté, c'est qd même plus chouette. J'essaye de mettre en perspective mon point de vue. Des fois, en voyant la même chose, mais d'un angle différent, on ne comprend pas la même chose.

Pas de soucis, même si on est pas forcément d'accord sur tout, on peut avoir un échange constructif, contrairement à la personne avec qui je vous avais confondu, je m'en excuse encore.

[floyer]

Par contre je ne serait pas contre un débat sur la pertinence de certains langages de haut-niveau utilisés à tord et à travers... Avec des performances de plus en plus catastrophiques.

Tu penses à Python ou Ruby ?

J’aime beaucoup cet article : http://blog.gmarceau.qc.ca/2009/05/s...ty-of.html?m=1

Il classe les langages selon deux axes : vitesses d’exécution et concision des contributions au benchmarks (l’avantage d’un langage de haut niveau est logiquement d’être concis).

Aprés, un benchmarking doit être analysé avec prudence. Quand je vois des contributions C à un benchmark bien connu hyper optimisées à coup d’instructions MMX ou SSE2 donc non portable et non représentatif de ce que l’on coderait usuellement…

On y trouve que l’on peut avoir une concision proche de Python mais avec des langages de haut plus rapides. J’avoue avoir un faible pour les langages à typage fort et statiques (cela détecte pas mal d’erreurs à la compilation) mais à inférence de type qui fait que dans beaucoup de cas, on programme un peu comme avec un typage dynamique.

[commandantFred]

Concernant le monde de l'embarqué, ce n'est aussi simple que.

Quant on a une base de code, écrite en C, qui est utilisée depuis de 20 ans sans le moindre soucis, rien que le fait de la réécrire sera plus dangereux que de garder ce qui fonctionne depuis des années. Pas seulement en terme de "Bugs", mais aussi en terme fonctionnalités, il y'a parfois des routines très pointues, qui on été étudiées, testées (je par de fonctionnalité), et validées. Les réécrire a l'identique, avec un autre langage, n'est souvent tout simplement pas possible. Des fois, une fonctionnalité fonctionne correctement ou pas, et ça se joue à quelques µs.

Je voudrais ajouter aussi à la discussion, que même si en effet, les microcontrôleurs deviennent de plus en plus gros, que ce n'est forcément ceux-là qu'on va utiliser. On nous déjà fait changer de microcontrôleur, pour gagner 0,10 €. Lorsque l'on produit en grande série, le moindre centime d'économisé peut faire qu'un produit se vende bien ou pas. Car entre ceux qui font la produit, et ceux qui l'utilisent au finale, il y'a plusieurs couches d'acteurs qui chacun, et c'est bien compréhensible, doit faire une marge. Et au final, le 0,10€ devient 1€. Si on multiplie par des dizaines de milliers de produit, et que chaque produit final comporte plusieurs sous-système, la note au final peut être énorme.

De plus, en entreprise, il est important de garder une cohérence, s'il y a disons 20 dev maîtrisant le C, on ne vas pas passer à Rust (ou autre), si facilement. Le changement fait peur, et autoriser un nouveau dev a utiliser un autre langage, fait que lui seul pourra auditer son code. On ne passe pas une équipe de 20 dev du C a Rust en disant juste que ça va permettre de régler des problèmes qui n'existe pas (vu la base de code qui a prouvé sa qualité depuis des décennies).

L'embarqué est un autre monde. On n'a vraiment pas intérêt à embarquer une stack IP (corruptible) si on n'en a pas l'usage. Or, si ton firmware est chargé par un bruleur de PROM ou en flashant une NAND, les pirates vont rester "au port". Le risque d'intrusion est nul s'il n'y a pas de vecteur.
Donc, tu peux rester en C.

C'est un peu différent sur le wifi esp32 (bluetooth ne suffit pas toujours bien qu'il consomme beaucoup moins). La fonctionnalité la plus intéressante est le serveur http embarqué. Evidemment écrit en C (vaguement ++). Inutile d'expliquer l'avantage en termes telecom. Difficile de caractériser le risque, l'accès à un routeur internet est facile à implémenter. Je n'ai jamais vérifié si on peut activer le petit serveur généralement inclus dans python. Bon...
Esp32 est complètement chinois. Ses deux coeurs s'apparentent à un ARM, il embarque 520 kb de ram et un contrôleur radio qui fait beaucoup plus que ce qui est toléré en occident. Les versions d'exportations sont bridées mais on peut bricoler un protocole zigbee par exemple. Faire la même chose sur Atmel requiert pas mal d'extensions. Son prix oscille entre 5 et 10 €.

Un Pic entrée de gamme coûte 1.5€ je crois. En même temps, c'est un investissement personnel pour chaque architecture.

Comme j'implémente des algorithmes ultra voraces en calcul, j'ai besoin de FLOPS, côté mémoire , j'ai des processes récursifs bien profonds. En fait , je vais toujours au maximum de puissance de calcul. Côté mémoire, je suis un peu moins au taquet.

Je ne suis pas contre Rust, mais j'ai du mal a penser qu'il peux régler tous les soucis, d'une variété d'utilisations énorme (de l'embarqué aux gros sites Web qui doivent être hyper sécurisé). Les vrais soucis viennent plus souvent des technologies "du Web", que du code de bas niveau. Je n'ai jamais voulu faire du dev Web, car de ce que je vois, rien n'est jamais vraiment stable dans cet écosystème. Ce qui était adulé il y a 1 an, et jeter aux ordures, pour le nouveau "framework" à la mode. Des couches, sur des couches à n'en plus finir, qui sont souvent écrites par des dev peu expérimentés, ça peut vite créer des soucis, je le comprend très bien.

Il y a aussi eu le (selon moi), néfaste passe des smatphones, qui ont changés la manière, ne fusse que visuel des sites web, qui a influencé le dev des applications que je nommerais "Bureautique". On veut tout faire dans un navigateur, qui en quelque sorte, "remplace", l'OS de base petit à petit. Il faut que tout soit connecté à tout, même quant ce n'est pas nécessaire, ce qui multiplie les risques. Pour ma part, je regrette le temps du début d'internet, où l'on consultait des info, sans plus. Beaucoup de soucis liée a des attaques, on déferlés suite à l'introduction, petit à petit, de "programmation dans le web". Je déteste au plus haut point les "application dans le navigateur", rien qu'en terme d'expérience utilisateur, c'est tout simplement une horreur. Ce qu'on autorise sans soucis dans une application web (du genre tu clique sur un bouton, et entre-temps, la mise en page se fait progressivement, et que le bouton n'est plus à la même place, ou que des boutons ne ressemblent plus à des boutons, pour une soit disant question de design, ou que tu doivent "scroller" pour trouver le bouton pour ne fussent que valider un choix, serait tout simplement considéré comme une erreur sur une application de bureau "classique").

Bref, tout n'est pas binaire, noir ou blanc, toute la palette de gris s'étalent entre différents problèmes, et il n'y a et n'aura pas UNE solution pour régler les différents soucis de notre discipline, que nous aimons tant.

C'était mes pensées du jour. BàV, et comme je dis souvent, Peace & Love :-)

L'écosystème web application est de plus en plus impressionnant. J'espère que les développeurs sauront corriger les défauts que tu soulignes.
Les avantages des technos web pour un développeur sont innombrables. Les librairies sont époustouflantes. En fait, c'est tout le gratin des librairies qui est implémenté mais le W3C est très long à tout normaliser. Dans ce cas , la norme est incontournable car il y a plusieurs navigateurs - même s'il y a de moins en moins d'architectures - µsoft a jeté l'éponge et utilise le moteur de Chrome. Mozilla est un des derniers pionniers à garder son indépendance.


C'est un sujet très vaste, l'existant est très stable. Tu peux apporter une IHM très développée à tes programmes C en adressant un petit serveur http.

[mintho carmo]

J'ai l'impression que certains ici pensent qu'il n'y a des vulnérabilités uniquement dans le code qui utilise du web, de l'internet ou du réseau. Et donc que s'ils n'ont pas de fonctionnalités de connexion dans leur code, ils n'ont pas de vulnérabilité.

Mais n'importe quel bug/UB dans un code qui est utilisé sur un objet connecté (ordi, telephone, iot, etc) est une vulnérabilité.

[commandantFred]

J'ai l'impression que certains ici pensent qu'il n'y a des vulnérabilités uniquement dans le code qui utilise du web, de l'internet ou du réseau. Et donc que s'ils n'ont pas de fonctionnalités de connexion dans leur code, ils n'ont pas de vulnérabilité.

Mais n'importe quel bug/UB dans un code qui est utilisé sur un objet connecté (ordi, telephone, iot, etc) est une vulnérabilité.

Au contraire, le risque est augmenté sur les objets connectés. Encore faut il qu'ils le soient. Si le hardware n'a aucune connectivité réseau, non seulement, il n'y a pas de risque pour lui même mais il ne peut pas être "zombifié" pour attaquer une autre machine. A l'inverse, une machine dont la connectivité lui permet d'échanger de l'information réseau présente un risque même pour une application qui ne fait pas usage du réseau (mais accessible par celui-ci).

Une machine complètement standalone peut être buggée mais n'est pas sujette à une intrusion intentionnelle.

Le propre des "exploits de hacker" est de mettre en oeuvre de nombreuses vulnérabilités simultanément. Ce sont des intrusions coordonnées, souvent très astucieuses.

Les exécutables distribués en masse, modules d'OS, grands logiciels, navigateurs et même anti-virus sont des têtes de pont appréciées des hackers parce qu'il est facile d'avoir une copie de ces fichiers et d'y chercher des failles. La recherche de faille dans un exécutable peut être très longue. Il faut des milliards d'itérations avant de trouver le paramètre qui met le système en danger.

Lorsque une logique d'intrusion est identifiée sur un exécutable distribué sur des millions de systèmes. Sa mise en oeuvre est publiée sur des sites bien précis. Elle prend alors le nom de "zéro-day" (jour zéro) qui signifie que la faille a été identifiée depuis moins de 24 heures et qu'elle ne risque pas d'avoir fait l'objet d'un patch de sécurité.
Ces mêmes sites publient des centaines de scenarii d'attaques coordonnées ainsi que les scripts pour les mettre en oeuvre.

Mais perpétrer un exploit est devenu plus difficile aujourd'hui. La plupart des réseaux sensibles ont au moins un pare-feu et des antivirus. Les attaques sont donc plus sophistiquées.

On découvre régulièrement des failles exploitées par des hackers depuis des années, même au plus haut niveau de criticité (l'Otan a été écouté pendant des années avant de découvrir un mouchard dans ses machines, les chefs d'états ont été espionnés via un fameux logiciel israélien...)

Bon, je ne connais pas toute la panoplie des hackers, elle peut être très variée mais à notre époque où on ne distribue plus grand chose sur support physique, la connectivité est une constante opérationnelle. A moins d'être en charge de données très critiques et de faire l'objet de rapprochements physiques de services secrets (les jeunes espionnes de l'Est ont la cote ces jours-ci), les développeurs sont "responsables"** du périmètre de leurs créations. Ce périmètre s'étend au logiciel qu'ils mettent en oeuvre. Les autres parties du système relèvent de la responsabilité de leurs propriétaires.

Mais au risque de me répéter, il est très probable qu'un logiciel "normal" soit utilisé dans un exploit pour infecter ou pour saturer une autre partie du système.

Je vais remettre la main sur la directive de la DGSI que j'ai reçue. Elle demande que les développeurs de logiciel restent "joignables" dans mon souvenir... On est à la préhistoire de la cyber sécurité mais de gros investissements ont été annoncés partout en Europe.


** Entre guillemets parce que je ne connais pas la portée exacte de la responsabilité d'un éditeur de software vulnérable. Cette notion est d'ailleurs floue. En France, la DGSI, un département du ministère des armées, est compétente sur ces questions. Par contre, un vol ou une escroquerie relèvent de la justice civile. Seul un expert en cyber sécurité connait vraiment le degré de responsabilité des développeurs. Actuellement, factuellement, ces questions sont ignorées par la plupart des développeurs et je doute que la DGSI puisse répondre sur ce point. Le mot "responsabilité" doit donc être pris au figuré.

[foetus]

Encore 1 fois tu ne sais pas de quoi tu parles

Les jeux de caractères sont innombrables, rien que dans mon éditeur html, j'en ai une soixantaine ! Imaginez que je vous les liste tous avec une explication pour chaque... OEM XX-nn est bien adapté au cunéiforme et au serbo-croate mais se prête moins bien au sanscrit... Damn, la journée va être longue...

Non, là tu cites tous les "code pages" la page Wikipédia

D'ailleurs depuis le HTML5 (2014), on n'a plus besoin de préciser l'encodage (et les doctypes) : par défaut c'est de l'UTF-8.

Bon, je ne connais pas toute la panoplie des hackers, elle peut être très variée mais à notre époque où on ne distribue plus grand chose sur support physique, la connectivité est une constante opérationnelle. A moins d'être en charge de données très critiques et de faire l'objet de rapprochements physiques de services secrets (les jeunes espionnes de l'Est ont la cote ces jours-ci), les développeurs sont "responsables"**

Là c'était dans les années 70 avec James Bond

29 août 2023 : "Les données d'environ 10 millions d'allocataires inscrits en février 2022 ont été compromises dans une fuite de données subie par un prestataire de Pôle emploi."
9 février 2024 : "33 millions de Français sont concernés par une fuite de leur numéro de sécurité sociale, après une cyberattaque qui a touché deux gestionnaires de tiers payant."
Et la majorité des attaques de spoofing utilisent le même numéro de téléphone (la même plateforme en gros) que ta banque

Les styles divergent, y'a des gars qui mettent des pages de commentaires pour 5 lignes de code. Puis rebelote big commentaire encadré avec des gros '#' et 3 petites lignes...

La réponse est simple : on ne code pas que pour soi.
Avec les méthodes agiles (surtout eXtrem Programming), on préfère les fonctions "self documented" parce qu'au fil des maintenances, le commentaire peut devenir erroné (s'il n'est pas modifié en même temps que le code)
De plus écrire 1 commentaire est difficile parce qu'il ne doit pas "paraphraser" le code.
Mais il y a des outils qui permettent d'extraire les commentaires et de générer 1 documentation automatiquement et ceci au moyen de gros blocs commentaire.

[Charvalos]

D'ailleurs depuis le HTML5 (2014), on n'a plus besoin de préciser l'encodage (et les doctypes) : par défaut c'est de l'UTF-8.

Je ne tiens pas à me mêler à votre discussion mais par contre, je ne peux m'empêcher de réagir à ça parce que ce n'est pas juste.

1) Le doctype HTML est obligatoire. C'est juste qu'il a été nettement simplifié pour le HTML 5.
2) Indiquer l'encodage est grandement conseillé, histoire d'éviter les mauvaises surprises. Les navigateurs actuels partent du principe que c'est de l'UTF-8.

Voilà, je vous laisse à votre discussion.

[deedolith]

L'intention est louable.

Dommage que la propagande Google (Rust) s'immisce dans l'équation.

[Uther]

Dommage que la propagande Google (Rust) s'immisce dans l'équation.

Je vois pas trop le rapport : Rust est un projet libre, initialement créé par Mozilla, et maintenant géré par une fondation indépendante. Google utilise certes Rust dans certains composants d'Android, mais il n'a pas fait de propagande particulière pour Rust, contrairement à ce qu'il a pu faire pour ses langages maison : Go et surtout Dart.

Il faut voir que la généralisation de l'usage de Rust ne profite pas plus à Google qu'à ses concurrents. Il participe au financement de son infrastructure et de son évolution via des contributions à la Fondation, mais tout comme d'autres grand noms qui utilisent Rust (Amazon, Meta, Microsoft, ...). Il n'en retirent pas d'avantage concurrentiel particulier. Au contraire, si Google voulait que son investissement lui soit profitable, il aurait intérêt que les autres n'utilisent pas Rust, pour être le seul à profiter des améliorations qu'il contribue à financer.

[sheldon lee cooper]

C'est une question de SI. La robustesse en matière de sécurité du code informatique promet la SI.

Donc c'est normale que la maison Blanche s'intéresse à la programmation