Discussion :

[Anthony]

La vulnérabilité "BatBadBut" a été découverte entre autres dans la bibliothèque standard Rust, mais elle affecte également Erlang, Go, Haskell, Java, Node.js, PHP, Python et Ruby

Une faille de sécurité critique, baptisée "BatBadBut", a été découverte entre autres dans la bibliothèque standard Rust, affectant toutes les versions antérieures à 1.77.2 sous Windows. La vulnérabilité, identifiée comme CVE-2024-24576, a un score CVSS de 10.0 et permet à un attaquant d'exécuter des commandes shell arbitraires en contournant le mécanisme d'échappement lors de l'invocation de fichiers batch avec l'API Command.

La vulnérabilité "BatBadBut" a été découverte par le chercheur en sécurité RyotaK et divulguée de manière responsable à l'équipe de sécurité de Rust, qui a donc expliqué comment l'équipe Rust a géré l'alerte, et patché la faille, ce qui n'est pas encore le cas sur tous les autres langages affectés.

Selon le billet de blog de RyotaK, le problème provient des règles complexes d'analyse de cmd.exe, l'invite de commande de Windows, qui est implicitement lancée lors de l'exécution de fichiers batch. La bibliothèque standard Rust ne parvient pas à échapper correctement les arguments de commande pour cmd.exe, ce qui permet l'injection potentielle de commandes.

Alors que les API Command::arg et Command::args de Rust garantissent que les arguments seront transmis tels quels au processus créé et ne seront pas évalués par un shell, la mise en œuvre sous Windows est plus complexe.

L'API Windows ne fournit qu'une seule chaîne de caractères contenant tous les arguments, laissant au processus créé la responsabilité de les diviser. La plupart des programmes utilisent la chaîne d'exécution standard argv en C, ce qui permet d'obtenir un comportement cohérent en matière de division des arguments. Cependant, cmd.exe possède sa propre logique de découpage des arguments, qui nécessite un échappement personnalisé par la bibliothèque standard Rust.

"Pour éviter l'exécution inattendue de fichiers batch, vous devriez envisager de déplacer les fichiers batch dans un répertoire qui n'est pas inclus dans la variable d'environnement PATH.", a noté RyotaK dans son billet de blog. "Dans ce cas, les fichiers batch ne seront pas exécutés à moins que le chemin d'accès complet ne soit spécifié, ce qui permet d'éviter l'exécution inattendue de fichiers batch."

L'équipe de sécurité de Rust a reconnu que la logique d'échappement existante dans la bibliothèque standard était insuffisante, ce qui permettait à des arguments malveillants de contourner l'échappement et d'entraîner une exécution arbitraire de l'interpréteur de commandes. La gravité de la vulnérabilité "BatBadBut" est considérée comme critique si des arguments non fiables sont transmis lors de l'invocation de fichiers batch sous Windows.

BatBadBut ne se limite pas à un seul identifiant CVE

Alors que l'attention s'est d'abord portée sur le langage de programmation Rust, il est apparu que la vulnérabilité "BatBadBut" ne se limite pas à un seul identifiant CVE. La vulnérabilité affecte plusieurs langages de programmation et outils, chacun se voyant attribuer un identifiant CVE différent en fonction de la mise en œuvre et de l'impact spécifiques.

Outre CVE-2024-24576, qui concerne la bibliothèque standard Rust, "BatBadBut" englobe également CVE-2024-1874, CVE-2024-22423 (qui affecte yt-dlp avec un score de risque élevé de 8,3) et CVE-2024-3566 (qui affecte Haskell, Node.js, Rust, PHP et yt-dlp). Cela met en évidence la nature étendue de la vulnérabilité et la nécessité pour les développeurs d'évaluer leurs applications et dépendances à travers différents langages de programmation et outils.

Atténuation

Pour remédier à la vulnérabilité "BatBadBut", l'équipe Rust a publié la version 1.77.2, qui inclut un correctif pour le problème. Ce correctif améliore la robustesse du code d'échappement et modifie l'API Command pour qu'elle renvoie une erreur InvalidInput lorsqu'elle ne peut pas échapper un argument en toute sécurité. Cette erreur sera émise lors du lancement du processus.

Pour les développeurs qui implémentent leur propre échappement ou qui ne gèrent que des entrées fiables sous Windows, la méthode CommandExt::raw_arg peut être utilisée pour contourner la logique d'échappement de la bibliothèque standard.

Il est important de noter que la vulnérabilité n'affecte que le code Rust fonctionnant sous Windows qui exécute des fichiers batch avec des arguments non fiables. Les autres plateformes ou utilisations de Windows ne sont pas concernées.

La communauté Rust a exprimé sa gratitude à RyotaK pour avoir divulgué la vulnérabilité de manière responsable, à Simon Sawicki (Grub4K) pour avoir identifié certaines des règles d'échappement adoptées, et aux membres du projet Rust qui ont aidé à développer le correctif, à le réviser et à coordonner le processus de divulgation.

Il est fortement conseillé aux développeurs utilisant Rust sur Windows de mettre à jour vers la version 1.77.2 dès que possible afin de réduire le risque d'attaques potentielles par injection de commandes. Il est essentiel de s'assurer que les entrées non fiables sont correctement validées et assainies avant d'être transmises en tant qu'arguments à des fichiers batch.

État des lieux sur les autres langages de programmation affectés

Sources : Équipe Rust, "BatBadBut: You can't securely execute commands on Windows" (RyotaK, chercheur en sécurité)

Et vous ?

Quelle lecture faites-vous de cette situation ?

Voir aussi :

Comment Rust améliore la sécurité de son écosystème : la Rust Foundation publie un rapport sur ce que leur initiative de sécurité a accompli au cours des six derniers mois de 2023

« Choisir Rust est opter pour une meilleure sécurisation des logiciels qu'avec le C, mais une efficacité énergétique et une performance d'exécution que seul le C offre », d'après l'équipe AWS

[Fagus]

En fait c'est plus un défaut de conception dans cmd.exe qui oblige les langages à contourner le défaut de manière alambiquée.

However, when you execute the following command on the command prompt, calc.exe will be executed:

echo ""&calc.exe"

So, the following command spawns calc.exe when executed on PowerShell:

cmd.exe /c 'echo "%CMDCMDLINE:~-1%&calc.exe"

[Uther]

En effet, ou pour être plus précis, le défaut vient de la fonction CreateProcess de l'API de Windows qui fait insidieusement appel à cmd.exe quand le fichier exécuté est un fichier de commande (de type bat ou cmd). Cela à pour conséquence que les arguments ne sont plus traités comme tels, mais comme une ligne d'un fichier batch à exécuter.

Le principal problème vient du fait que ce comportement est mal documenté par Microsoft. La documentation MSDN actuelle n'indique pas du tout le comportement spécifique dans le cas des fichiers de commande. Au contraire elle indique que pour exécuter un fichier de commande, il faut invoquer cmd.exe manuellement.

[chrtophe]

Appeler un fichier externe avec cmd est une mauvaise idée.

[Uther]

Le problème c'est justement que ça ne concerne pas que les fichiers externes. Si tu fais appel à un fichier de commande, même interne, avec des paramètres variables, tu peux tout à fait être concerné.

[chrtophe]

J’avais compris que c'était lié à cmd.exe, Donc utilisé pour appeler une commande externe au logiciel.

Pas clair pour moi.

[Uther]

Quand je parle d'un fichier de commande interne, je parle d'un fichier qui ferait partie des fichiers ton logiciel et dont tu es certain du contenu.
Normalement, on s'attendrait qu'exécuter ce genre de fichier soit sûr. Le soucis c'est que l'API Windows interprète les paramètres que l'on transmet à ce fichier comme une ligne de commande Windows ce qui peut permettre des abus.

[OuftiBoy]

Salut à tous :-)

Je n'ai pas tout compris (j'ai pas eu le temps de gratter), mais dire que c'est la faute de cmd.exe, parce qu'il fait les choses différemment, me semble un rien douteux... Le fond du problème, c'est que les développeurs ont utilisé quelque chose qu'ils ne maîtrisaient pas. Un rien de bon sens, si on ne sait pas comment se comporte quelque, on teste ou on utilise pas. Mais bon, il y a tellement de "couches", qu'on ne sait pas tout prévoir. Mais utiliser, réutiliser, mettre une couche sur une couche à n'en plus finir, fait aussi partie du problème. Ce n'est pas propre à un langage, et ce n'est pas qu'en informatique. Plus le temps passe, plus on complexifie les choses. Un citoyien lamda est obligé de prendre un avocat pour se défendre en justice parce que les lois sont de plus en plus nombreuses, de moins en moins compréhensibles. Le problème est globale.

Pour en revenir à la faille, si c'était à cause de l'API de microsoft, c'est lui qui devrait réagir, non ? Ici, pleins de langages (mais pas tous) sont concernés et vont "faire autrement" pour éviter le problème. Comment ont fait les développeurs des langages non concernés ? Soit ils ont eu du bol, soit ils ont (bien) fait les choses.

Ce n'est que mon petit avis perso.

Peace & Love.

[Uther]

Je n'ai pas tout compris (j'ai pas eu le temps de gratter), mais dire que c'est la faute de cmd.exe, parce qu'il fait les choses différemment, me semble un rien douteux... Le fond du problème, c'est que les développeurs ont utilisé quelque chose qu'ils ne maîtrisaient pas. Un rien de bon sens, si on ne sait pas comment se comporte quelque, on teste ou on utilise pas.

C'est assez ironique d'avouer ne pas très bien comprendre le problème dont on parle, et en même temps de conclure que le problème vient des développeurs qui ne comprennent pas bien l’outil qu'ils utilisent.

Plus sérieusement, bien sur que les développeurs se doivent de maitriser les API qu'ils utilisent. Mais pour cela, encore faudrait-il qu'il puissent se renseigner sur leur comportement. Le fait que la fonction CreateProcess de l'API Win32 fasse appel à cmd.exe et surtout que les paramètres sont interprétés comme une ligne de commande, n'est pas documenté officielement.
Difficile de reprocher aux développeur de ne pas connaitre un comportement non documenté.

Pour en revenir à la faille, si c'était à cause de l'API de microsoft, c'est lui qui devrait réagir, non ? Ici, pleins de langages (mais pas tous) sont concernés et vont "faire autrement" pour éviter le problème. Comment ont fait les développeurs des langages non concernés ? Soit ils ont eu du bol, soit ils ont (bien) fait les choses.

Microsoft peut difficilement corriger ça sans risquer de casser la compatibilité.
Mais à défaut de corriger la fonction CreateProcess, ils devraient au moins correctement la documenter pour indiquer qu'elle fait appel à cmd.exe pour les fichiers de commande et que ça implique des règles d’échappement différentes et bien plus complexes.

[OuftiBoy]

C'est assez ironique d'avouer ne pas très bien comprendre le problème dont on parle, et en même temps de conclure que le problème vient des développeurs qui ne comprennent pas bien l’outil qu'ils utilisent.

Nuance, j'ai dis que je n'avais pas tout compris, car pas le temps, mais ne pas tout comprendre ne veux pas dire "rien" comprendre ;-) J'en ai compris assez (dans mon humble jugement) pour me faire mon opinion sur le sujet. Mais je n'ai pas la science infuse, et je vais tenter une autre approche pour défendre mon point de vue.

Plus sérieusement, bien sur que les développeurs se doivent de maitriser les API qu'ils utilisent. Mais pour cela, encore faudrait-il qu'il puissent se renseigner sur leur comportement. Le fait que la fonction CreateProcess de l'API Win32 fasse appel à cmd.exe et surtout que les paramètres sont interprétés comme une ligne de commande, n'est pas documenté officielement.
Difficile de reprocher aux développeur de ne pas connaitre un comportement non documenté.

Je vais prendre une métaphore. Tu te ballades dans la foret (dans ce cas, on pourrait dire la jungle), tu as faim, et tu vois un champignon. Tu n'as pas avec toi le "petit manuel des champignons dangereux" (et que même si tu l'as, tu ne trouve rien sur ce champignon), que fais-tu ? Perso, je ne mange pas le champignon... Remplace foret par développement, champignon par API, et le manuel par la documentation.

Donc oui, utiliser quelque chose dont on ne connait pas le résultat, c'est une erreur du développeur. Mon opinion est peut-être biaisée par mon vécu, je ne demande pas a avoir raison hein. Si des devs veulent utiliser un UB (comme notre discussion à propos de la sécurité du code entre Rust et C), c'est normal que des choses indéfinies peuvent se produire quelque fois ;-)

Microsoft peut difficilement corriger ça sans risquer de casser la compatibilité.
Mais à défaut de corriger la fonction CreateProcess, ils devraient au moins correctement la documenter pour indiquer qu'elle fait appel à cmd.exe pour les fichiers de commande et que ça implique des règles d’échappement différentes et bien plus complexes.

Je suis d'accord avec toi, une compagnie comme Microsoft se devrait d'avoir une documentation clair et net sur tout ce qu'ils produisent. Je suis aussi d'accord qu'ils ne peuvent pas "casser la compatibilité". C'est (je pense) un comportement (pas forcément mauvais, mais disons différent de ce que à quoi les devs sont habitués) qui a été "fait", il doit y avoir bien longtemps. Mais je ne suis pas certains que les devs lisent la documentation de chaque API. Pas le temps, pas pensé, oublié, ...

Il y a 3 coupables ici selon moi (par ordre d'importance):

1 - Les créateurs d'un langage "mainstream" utilisent mal une API,
2 - Les devs utilisent une API qu'ils ne maîtrisent pas,
3 - Microsoft a mal documenté la fonctionnalité.

Certains langages semblent ne pas avoir le soucis. Soit parce qu'ils n'utilisent pas cette API, soit parce qu'ils savaient (et ont trouvé quelque part une information à ce sujet), soit parce qu'ils ont eu du bol, comme avec les UB ;-)

Ce qui serait intéressant, c'est:
1 - De savoir depuis combien de temps ce "problème" existe,
2 - Et pourquoi on ne le découvre que maintenant ?
3 - Je ne me penche pas sur le pourquoi un compilateur "récent" pour un langage "récent" (non, je ne vise personne ;-)) a besoin d'utiliser une fonctionnalité reposant sur cmd.exe qui date de DOS 1.0...

Et je te rassures, je n'ai pas mangé de champignon :-)

Bonne fin de journée, et "Peace & Love", comme d'habitude.

[chrtophe]

Je vais prendre une métaphore. Tu te ballades dans la foret (dans ce cas, on pourrait dire la jungle), tu as faim, et tu vois un champignon. Tu n'as pas avec toi le "petit manuel des champignons dangereux" (et que même si tu l'as, tu ne trouve rien sur ce champignon), que fais-tu ? Perso, je ne mange pas le champignon... Remplace foret par développement, champignon par API, et le manuel par la documentation

L'analogie valable serait plutôt que le "petit manuel des champignons dangereux" te dise que tu peux manger ce champignon sans te préciser qu'il faut le faire bouillir avant. C'est ce qu'on appelle la documentation. si celle-ci est imprécise, l'API peut être mal utilisée.


Je n'avais pas compris le prob au départ, car pour moi je ne m'attendais pas à ce que createprocess appelle cmd (après je suis pas développeur), donc si je devais développer un programme appelant createprocess pourquoi je devrais formater les arguments comme si je passais par cmd ? Et après on va dire que c'est mon code qui est pas bon, alors que comme il n'est pas précisé dans la doc que je dois échapper les arguments comme si j'appelais cmd, je ne l'ai pas fait.

[OuftiBoy]

... Tu n'es pas le principal coupable, je comprend très bien qu'on puisse se faire avoir de la sorte. On sait très bien qu'on ne peut pas vérifier tout tout le temps. Et même si on tente de le faire, c'est loin d'être évident. Je peux comprendre tous les arguments qui repoussent la faute sur la mauvaise documentation de microsoft, mais, comme tu le dis toi même, tu n'es pas développeur. Dans mon domaine, tout est plus "limité" et donc tout est hyper contrôlé, et je comprend que tout le monde ne vit pas dans le même domaine que le mien.

Je comprend que tu développes sans être développeur (ce n'est pas une critique), mais je pense que je ne me laisserais pas opérer par mon garagiste, ni que je ferais réparer ma voiture par mon chirurgien. Il y a parfois des choses incroyables qui sont "tolérées" quant on parle de "développement" et qui ne serait même pas envisagées dans un autre domaine.

Bah, c'est que du codage pensent certains qui sont au-dessus de nous, comme si c'était pas un domaine compliqué, puisque l'enfant de 10 ans de la RH a réussi a la dépanner pour une erreur dans une formule d'un tableau excel. Elle voulait la casse en rouge quand le montant était négatif. Le petit a regardé, et a su lui colorier sa casse correctement. Nickel, parfait, le voilà avec un diplôme de super informaticien qui sait tout sur tout. Maman l'a fait imprimer en encadrer par le voisin du cousin de la soeur de sa nièce (un cador en informatique, il joue toujours sur son C64), car chez elle, ça n'imprimait pas...

Avec ironie, si ce n'était pas dramatique, on voit avec boeing ce qui arrive quand les choses ne sont pas faites en prenant un maximum de sécurité, ni par des personnes compétentes, ni avec le temps pour bien faire.

Je suppose que tu ne monterais pas dans un avion piloté par un gus qui a fait 3h de deltaplane :-) Mais en "informatique", on trouve normal qu'une équipe qui développe un compilateur (donc pas des manchots à la base je suppose) qui sera utilisé partout dans le monde, utilise quelque chose dont elle n'a aucune idée du résultat. La documentation est une excuse trop facile, et si elle n'est pas bonne, bah, pas grave, on comprend pas mais "ça va aller"... Et on va pas faire de test, on a pas le temps. Non, je pense que la réalité, c'est qu'ils n'ont même pas chercher à lire la doc, l'intellisence a certainement proposé une fonction après 3 caractère, et hop, on passe dessus... Je ne chercherais pas plus loin la "cause" de cette affaire.

Et bientôt, quand une IA pondra un brol en assemblant des morceaux, si ça fait tomber l'avion, ce sera la faute à qui ? Pas à un manque de documentation, ils ont pompés le moindre byte disponible sur internet :-)

Le tout a prendre avec humour hein ;-)

Peace & Love.

[chrtophe]

Que je sois développeur ou non, j'ai accès à la même documentation technique. Le prob. n'est pas là.

Pour reprendre tes exemples :
Un garagiste tout compétent qu'il soit ne pourra pas correctement réparer ta voiture si il n'a pas accès à une documentation technique fiable, sauf si il a lui-même fabriqué le moteur.

Un médecin te prescris un médicament qui a pignon sur rue. Plusieurs années plus tard, on découvre que ce médicament provoque de graves problèmes, le médecin est responsable ?

Un développeur utilise un OS incluant des fonctions, si celle-ci ne sont pas correctement documentées, ou ne réagit pas comme documenté, on ne peut pas incriminer le développeur en question.

[OuftiBoy]

Que je sois développeur ou non, j'ai accès à la même documentation technique. Le prob. n'est pas là.

Sincèrement, je ne pense pas que ce soit pertinent. J'ai accès à toutes les lois et normes d'un juriste, mais ça ne fait pas de moi un avocat...

Pour reprendre tes exemples :
Un garagiste tout compétent qu'il soit ne pourra pas correctement réparer ta voiture si il n'a pas accès à une documentation technique fiable, sauf si il a lui-même fabriqué le moteur.

Je préfère en effet qu'un garagiste n'ayant pas toutes les informations nécessaire ne touche pas à ma voiture, tout comme un dev qui n'a pas toutes les informations nécessaire n'utilise pas qlq chose de non documenté ou mal documenté. C'est exactement ce que je dis, rien de plus. On parle ici de gens (d'une équipe) qui devraient être à la pointe. Pas d'un dev qui fait un petit projet dans son garage...

Un médecin te prescris un médicament qui a pignon sur rue. Plusieurs années plus tard, on découvre que ce médicament provoque de graves problèmes, le médecin est responsable ?

Avec toutes mes excuses, non, ce n'est pas une bonne analogie. Un médicament cherche a solutionner un problème, ça n'a rien à voir avec un "outil" qui fait ce qu'il a toujours fait, et tu utilises mal (sans avoir trouvé la notice ou sans l'avoir comprise ou sans même l'avoir cherchée peut-être). Je vais chez mon toubib quand j'ai besoin, je ne prend pas un médicament acheté sur internet. Lors de la "crise covid", je n'ai pas voulu me faire vacciner, mon médecin était tout à fait d'accord avec moi. On a dit pendant les cinquante dernières années qu'il fallait 10 ans pour mettre au point un vaccin. Donc en sortir un du chapeau en 1 ans, perso, je trouvais ça suspect. Surtout que les "sachant" affirmaient une chose le lundi et complètement le contraire avec un même aplomb le mardi.

Un développeur utilise un OS incluant des fonctions, si celle-ci ne sont pas correctement documentées, ou ne réagit pas comme documenté, on ne peut pas incriminer le développeur en question.

Apparemment, tous les langages et ou compilateurs ne sont pas touchés. Donc les gens qui s'occupent de ces langages ont soit trouvé l'information ou l'on bien comprise, ou l'on bien testée. Il n'y a pas de miracles. Je peux comprendre qu'un devs se fasse avoir, mais pas qu'une équipe de devs de "haut niveau" se fasse avoir de la sorte pour un outil aussi important qu'un compilateur. Ils n'ont donc pas testé ? Ils n'ont pas lu la doc ? Ils l'ont mal comprise ? Et si elle était "mal foutue", ça aurait justement dû les mettre en alerte. Je n'arrive pas à penser que dans l'équipe, personne ne ce soit soucié de la chose... Effectivement le gars qui utilise ce compilateur lui fait confiance, et qu'il se fasse avoir, je peux le comprendre. Mais bon, j'ai passé ma carrière dans le monde de l'embarqué, et des compilateurs qui foiraient, j'ai ai vu passer plus d'un.

BàT... et peace & love ;-)

[chrtophe]

'ai accès à toutes les lois et normes d'un juriste, mais ça ne fait pas de moi un avocat

Certes, mais l'avocat va se baser sur les textes de loi, la documentation. si celle-ci n'est pas assez précise, un demandeur pourra ne pas obtenir gain de cause même si dans un monde parfait il l'aurait obtenu ou un coupable peut échapper à une sanction. A cela vient s'ajouter des jusrisprudences qui vont avoir le même rôle qu'un correctif en informatique.

Je préfère en effet qu'un garagiste n'ayant pas toutes les informations nécessaire ne touche pas à ma voiture

Encore une fois un garagiste aura accès à tout la documentation technique disponible. Si celle-ci est erronée ou incomplète, on ne le sait pas forcément tout de suite.

Avec toutes mes excuses, non, ce n'est pas une bonne analogie. Un médicament cherche a solutionner un problème, ça n'a rien à voir avec un "outil" qui fait ce qu'il a toujours fait, et tu utilises mal (sans avoir trouvé la notice ou sans l'avoir comprise ou sans même l'avoir cherchée peut-être).

Sauf que des médicaments ont été retiré du marché suite à probs alors qu'ils étaient prescrit correctement par les médecins selon les posologies prévues, je ne parle pas d'un médicament pris sur Internet.

Effectivement le gars qui utilise ce compilateur lui fait confiance

Ce n'est pas un prob de compilateur mais de paramètre d'API. Tant que tu fourni les arguments attendus à une fonction, le compilateur ne verra pas de prob.

[Uther]

Je préfère en effet qu'un garagiste n'ayant pas toutes les informations nécessaire ne touche pas à ma voiture, tout comme un dev qui n'a pas toutes les informations nécessaire n'utilise pas qlq chose de non documenté ou mal documenté. C'est exactement ce que je dis, rien de plus. On parle ici de gens (d'une équipe) qui devraient être à la pointe. Pas d'un dev qui fait un petit projet dans son garage...

La problème c'est qu'il n'est pas évident de savoir qu'il nous manque une information. Rétrospectivement, et sur un cas connu, c'est toujours facile d'imaginer pourquoi l'API peut réagir particulièrement. Mais un développeur ne peut pas systématiquement anticiper tous les comportements internes potentiellement tordus d'une API : on peut toujours en imaginer plus. Si on ne fait rien sans être sur, on ne fait rien du tout, jamais. A un moment, il faut accorder un minimum de confiance au service fourni et on le fait sur la base d'une spécification ou à défaut d'une doc de référence.

Supposons qu'un développeur utilise la fonction système de copie de fichiers dans son application et que l'on découvre plus tard que cette fonction modifie certains types de fichiers images à la volée pour ajouter un watermark invisible sans le préciser. Est-ce qu'on devrait rendre le développeur responsable du fait que son application leake des informations, parce qu'il aurait du l'anticiper en vérifiant le comportement de la fonction pour tous les types de fichiers possibles ?
Et des exemple du genre, on peut en imaginer des dizaines sur quasiment toutes les fonctions possibles d'une API. Si on doit anticiper tous les cas imaginables de mauvais fonctionnement, on ne peut plus rien utiliser.

[OuftiBoy]

Le dev final (celui qui utilise le compilateur), je suis d'accord avec toi. Mais ça dépend du domaine... (logiciel embarqué devant atteindre le zéro défaut dans mon domaine, on a eu cette discussion il y'a qlq semaine).

Je conçois très bien que tout le monde ne travail pas sur des logiciel critiques, et que oui, il faut faire un minimum confiance.

Les "devs" responsables du compilateur, eux, j'ai du mal à leur trouver une excuse, même si ça peut arriver, personne n'est a l'abris de faire une bêtise. Mais quand même, ils livrent un outil "critique", puisque l'on va utiliser leur compilateur de part le monde. Certains langages et leur compilateur n'ont apparemment pas le soucis, c'est donc qu'ils ont chercher/trouver/compris la doc et/ou surement fait un test.

Si je prends ton exemple avec l'image, le dev qui utilise un logiciel fait pour manipuler les images, il lui fait confiance. Il ne va pas tout vérifier, je l'accepte sans soucis.

Mais les devs du logiciel en question, c'est pas "par erreur" qu'ils ajoutent un watermark. Soit c'est ce qu'ils veulent et ils "trompent" leurs utilisateurs (qui perdrons leur confiance), soit c'est vraiment "par erreur" (admettons) et là, pour un logiciel de traitement d'image, tester que la sortie correspond à ce que l'on veut est un minimum je pense.

Si word n'imprime pas ce la secrétaire a tapé, je ne mets pas en cause cette dernière, mais word et donc microsoft. On est bien d'accord ? C'est pareil avec le compilo.

Mais comme ça a été découvert sur Rust, qui a comme argument une meilleur sécurité, ça me fais un peur rire :-)

Tu sais depuis quand elle existe cette faille ? A mon avis, depuis un certains temps je pense, et peut-être moins sur des langages plus anciens dont les équipes connaissaient le comportement de cmd.exe ? Je n'affirme rien, je demande ton avis et/ou si tu as des infos à ce sujet ?

Je n'aime pas vraiment les discussions par chat/mail/sms. On peut vite mal comprendre (ou mal s'expliquer) ou penser que l'autre abuse ou prend un ton qui ne passe pas... Je t'assure que si je donne cette impression, c'est pas le but que je recherche. On a tous des vécus et des expériences différentes. Moi je suis certainement tatillon sur certains soucis par "déformation professionnel"

BàT. et... peace & love

[chrtophe]

Mais ça dépend du domaine... (logiciel embarqué devant atteindre le zéro défaut dans mon domaine, on a eu cette discussion il y'a qlq semaine).

Dans le cas d'un logiciel embarqué, tu n'utiliseras pas CreateProcess, tu ne seras donc pas concerné par le prob évoqué. Tu pourras par contre être concerné par des bugs de bibliothèques que tu utilises. Ensuite tu as de bonnes pratiques à appliquer comme utiliser les options du compilateur les plus restrictives, si tu l’autorise à laisser passer des aspects pouvant être problématiques, c'est pas le compilateur en cause. D'autres bonnes pratiques comme celles de la Nasa sont aussi une bonne idée, j'avais lu un truc là-dessus, et non exhaustif car ce n'est pas mon cœur de métier.
Les bugs viennent rarement du compilateur.

Si word n'imprime pas ce la secrétaire a tapé, je ne mets pas en cause cette dernière, mais word et donc microsoft. On est bien d'accord ? C'est pareil avec le compilo.

Alors là je suis dans mon domaine et peut donc t'affirmer sans aucune réserve que si Word n'imprime pas, ce n'est pas lui que je met en cause en 1er car c'est rarement lui la cause du prob. La 1ère cause d'un prob d'impression va être le pilote, donc il faut régler le prob au niveau de l'OS (qui est de Microsoft je te l'accord, mais Word existe aussi sur MacOS), le second ça va être l'utilisateur qui va lancer une impression US Letter ou mauvaises marges et s'étonner que le doc ne sorte pas alors que l'imprimante bipe en affichant la source de l'erreur. Je n’incrimine pas la secrétaire, elle n'est pas formée là-dessus, le seul éventuel reproche que je pourrais lui faire c'est de ne pas me donner le msg d'erreur et de râler en disant ça marche jamais. Mais la plupart du temps, quand je lui explique, elle peut gérer ou elle m’appelle non plus en me disant ça marche pas mais en me demandant de l’assistance pour régler correctement la mise en page. Ensuite va venir un doc "pourri" ou là on peut effectivement mettre Word en cause, mais sans avoir l’explication exacte,
on peut pas incriminer Word de façon absolue.

[OuftiBoy]

L'histoire de la secrétaire, c'était juste une métaphore, par analogie avec le sujet. J'ai rien contre Word, j'ai pas dis du mal de word, ni de personne en fait. Et oui, je te rassure, pas un commit ne peut se faire si le moindre warning ou même info du genre de ne pas respecter un certains formalisme du code. Toutes les options disponibles et même plus, genre MISRA, sont obligatoires. Toutes les "bonnes pratiques". Et pas de lib externe. Sauf un RTOS qu'on maîtrise bien, le même depuis des années. Nos lib "internes" sont éprouvées depuis des années. On ne se permet même pas de changer de version de compilateur pendant la vie d'un produit. ça n'apporterait rien comme profit, et ça ne peut qu'apporter des soucis. On vérifie même jusqu'au niveau de l'assembleur si le compilo a bien fait son travail. En 30 ans, pas un seul soucis. On ne change pas juste pour changer.

J'applique la même rigueur dans mes projets "perso". On pourrait croire qu'on perd du temps a appliquer une rigueur très strict, mais sur la durée, on est toujours gagnant. ça semble contraignant qd un nouveau dev arrive dans l'équipe, mais qd il voit qu'en fait ça permet de gagner du temps et d'avoir un sentiment de confiance, ce qui réduit le stress, ils adhèrent. Mais on reste vigilant, toujours. Parce que des compilo qui font une bourde, ou généraient pas correctement, on en vu passer. Et venant d'entreprises ayant "pignon sur rue" dans le domaine.

C'est pour ça que j'ai du mal a trouver une excuse pour cette fameuse faille. C'est tellement énorme que j'arrive pas a comprendre comment ça peut arriver. On l'a découverte sur Rust, mais d'autres langages et compilo on aussi eu le soucis, mais pas tous. Franchement, on parle d'une équipe de "Pro", financée par Mozilla. Même google donne du pognon pour faire avancer les choses. Avec tous ces moyens, c'est impardonnable de laisser passer un truc aussi énorme. Enfin, c'est que mon avis et je le partage :-)

Personne n'est obligé de penser comme moi, chacun pense et fait ce qu'il veut. Mais l'excuse de "la mauvaise doc", c'est pitoyable dans ce cas.

[chrtophe]

La métaphore pointe justement un mauvais diagnostic.