On est sûr qu'il n'y a pas de faille qui traine dedans depuis 20 ans ?
Je n'ai pas dit ça. Et je n'ai pas dit non plus que du vieux code était forcément parfait et bien éprouvé. Ce serait tomber dans un extrême inverse.
Par contre, le poste critique bash car il utilise pas le dernier style de codage à la mode. Est-ce là raison de shellshock ? Probablement pas.
Je suis un partisent du « Ne corrige pas si ce n'est pas cassé ». Ça ne veux pas dire qu'il ne faut pas chercher à améliorer les vieux truc. Mais ça veux dire que refactoriser pour le plaisir n'est pas toujours une bonne idée. Pour un programme tel que bash, un petit changement de comportement peux casser plein de script. Il vaux mieux être prudent.
Je vais prendre un en exemple la CVE-2007-1381 dans PHP, où un développeur voulant rendre le code plus « sécure » a remplacé une utilisation parfaitement valide de strncpy par un emploi erroné de strlcpy causant un trou béant de sécurité. Et parce que cette leçon n'est pas suffisante, php refait une erreur similaire 4 ans plus tard en remplaçant un strcat par un strlcathttps://bugs.php.net/bug.php?id=55439
Vive les bonne pratiques, hein !
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 5.
Je n'ai pas dit ça. Et je n'ai pas dit non plus que du vieux code était forcément parfait et bien éprouvé. Ce serait tomber dans un extrême inverse.
Par contre, le poste critique bash car il utilise pas le dernier style de codage à la mode. Est-ce là raison de shellshock ? Probablement pas.
Je suis un partisent du « Ne corrige pas si ce n'est pas cassé ». Ça ne veux pas dire qu'il ne faut pas chercher à améliorer les vieux truc. Mais ça veux dire que refactoriser pour le plaisir n'est pas toujours une bonne idée. Pour un programme tel que bash, un petit changement de comportement peux casser plein de script. Il vaux mieux être prudent.
Je vais prendre un en exemple la CVE-2007-1381 dans PHP, où un développeur voulant rendre le code plus « sécure » a remplacé une utilisation parfaitement valide de
strncpypar un emploi erroné destrlcpycausant un trou béant de sécurité. Et parce que cette leçon n'est pas suffisante, php refait une erreur similaire 4 ans plus tard en remplaçant unstrcatpar unstrlcathttps://bugs.php.net/bug.php?id=55439Vive les bonne pratiques, hein !