Et puis citer le cas d'Ariane 5, je ne vois pas trop ce que ça apporte au débat. Aucun langage ne permet de faire un programme parfait ? Big news! Si on désactive sciemment un catch d'exception pour des raisons de performance, c'est au détriment de la sécurité ? Big news!
Que la sécurité dépend clairement du développeur et quel que soit le langage. Ce comportement est typique. Le bug d'Ariane : on a une erreur, on désactive; le bug SSL Debian : erreur, on commente le code; un "buffer overflow", on double la taille du buffer ...
Actuellement on invente des langages pour corriger les problèmes typiques des langages précédents, des développeurs qui connaissent 30 langages mais à moitié et donc on a des programmes affreusement buggé, des solutions basées sur le langage "hype" du moment (qui seront inutilisables dans 3 ans), ...
D'un autre côté on un langage populaire et connu de tous, dont les "bonnes manières" sont connues, avec des algos testés, efficaces et décrits dans les livres, des compilateurs testés et optimisés, ...
Maintenant, personne n'a dit ici que le langage était l'élément clef en matière de sécurité, ça ressemble un peu à un homme de paille.
Heu :
Des langages de haut niveau qui se compilent et qui ont des performances comparables à C, c'est pas ce qui manque. Et ces langages ont au moins le bon goût de ne pas permettre de buffer overflows, le bug de base qu'on trouve dans au moins 100% des logiciels écrits en C.
Je comprend un peu comme "le langage défini le niveau de sécurité, C est au fond (non, creuse un peu encore)".
Que l'avis initial qui critiquait le choix du C pour écrire un serveur http sur le plan de la sécurité te semble idiot, c'est une chose.
Oui la deuxième partie est aussi dénuée de sens, mais j'avais déjà bondis.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 2.
Que la sécurité dépend clairement du développeur et quel que soit le langage. Ce comportement est typique. Le bug d'Ariane : on a une erreur, on désactive; le bug SSL Debian : erreur, on commente le code; un "buffer overflow", on double la taille du buffer ...
Actuellement on invente des langages pour corriger les problèmes typiques des langages précédents, des développeurs qui connaissent 30 langages mais à moitié et donc on a des programmes affreusement buggé, des solutions basées sur le langage "hype" du moment (qui seront inutilisables dans 3 ans), ...
D'un autre côté on un langage populaire et connu de tous, dont les "bonnes manières" sont connues, avec des algos testés, efficaces et décrits dans les livres, des compilateurs testés et optimisés, ...
Maintenant, personne n'a dit ici que le langage était l'élément clef en matière de sécurité, ça ressemble un peu à un homme de paille.
Heu :
Des langages de haut niveau qui se compilent et qui ont des performances comparables à C, c'est pas ce qui manque. Et ces langages ont au moins le bon goût de ne pas permettre de buffer overflows, le bug de base qu'on trouve dans au moins 100% des logiciels écrits en C.
Je comprend un peu comme "le langage défini le niveau de sécurité, C est au fond (non, creuse un peu encore)".
Que l'avis initial qui critiquait le choix du C pour écrire un serveur http sur le plan de la sécurité te semble idiot, c'est une chose.
Oui la deuxième partie est aussi dénuée de sens, mais j'avais déjà bondis.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell