Comme indiqué plus haut, je factorise mon code à outrance, ce qui fait qu'une grosse partie est commune à toutes les applications que je développe. Lors du développement de ce code, dont le cœur l'a été il y a plus de dix ans, j'avais à l'esprit les problématiques de sécurité, et j'ai fait mon maximum pour éviter les failles. Ce qui, je le concède volontiers, ne garantit en rien qu'il n'y en ai pas. Toujours est-il que ce code est déployé chez de nombreux clients, dans certains cas dans le cadre d'applications client/serveur accessibles au grand public et avec une fréquentation élevée.
Jusqu'à présent, aucun client ne m'a remonté de problèmes de sécurité. Cela peut arriver demain, auquel cas, après correction de la faille, je développerais une batterie de tests pour tester la correction, et pour tenter de détecter d'autres failles similaires. Mais, à ce jour, je ne vais perdre de temps à développer des tests pour tenter de déceler des failles dont on n'a jamais détecté la moindre trace...
Quand au code que je mets à disposition sous licence Libre, comme celui faisant l'objet de ce journal, j'attire l'attention sur la section 15 et la section 16 du fichier LICENCE fournit avec les sources. Partant de là, libre à l'utilisateur de, au choix,
auditer mon code (tâche ardue, mais pas impossible ; c'est de l'Open Source après tout),
le soumettre à une batterie de tests,
me demander de développer une batterie de tests.
Pour la dernière option, cela sera bien entendu réalisé contre rémunération, sauf s'il parvient à me fournir un test case mettant en évidence une faille qui justifie le développement de cette batterie de tests.
Encore une fois, même si moi-même je ne le fais pas, je conseille fortement tout un chacun de soumettre son code à un maximum de tests. Mais, concernant mon code, avec l'historique qu'il a, le gain que m'apporterait ces tests par rapport au temps que je passerais à les développer n'est pas rentable, à aucun point de vue, en particulier, mais pas seulement, du point de vue financier. D'autant plus que, et ton commentaire va également dans ce sens, aucune batterie de test ne peut garantir l'absence de failles.
Pour résumer, compte tenu de l'historique de mon code, de la manière dont il se comporte chez moi (j'utilise quotidiennement plusieurs logiciels que j'ai développés et qui contiennent donc ce code) et chez mes clients, je considère qu'il n'est pas plus vulnérable que la majorité des codes réalisés avec un minimum de sérieux et, de ce fait, probablement soumis à une batterie de tests. Mais je suis tout à fait disposé à réviser mon jugement, pour peu que l'on me soumette un test case prouvant mon erreur, et non pas seulement des considérations théoriques.
Quoi qu'il en soit, je te remercie pour tes remarques qui m'ont données l'occasion de m'expliquer davantage sur le sujet.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Mais je t'en prie...
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 3.
Comme indiqué plus haut, je factorise mon code à outrance, ce qui fait qu'une grosse partie est commune à toutes les applications que je développe. Lors du développement de ce code, dont le cœur l'a été il y a plus de dix ans, j'avais à l'esprit les problématiques de sécurité, et j'ai fait mon maximum pour éviter les failles. Ce qui, je le concède volontiers, ne garantit en rien qu'il n'y en ai pas. Toujours est-il que ce code est déployé chez de nombreux clients, dans certains cas dans le cadre d'applications client/serveur accessibles au grand public et avec une fréquentation élevée.
Jusqu'à présent, aucun client ne m'a remonté de problèmes de sécurité. Cela peut arriver demain, auquel cas, après correction de la faille, je développerais une batterie de tests pour tester la correction, et pour tenter de détecter d'autres failles similaires. Mais, à ce jour, je ne vais perdre de temps à développer des tests pour tenter de déceler des failles dont on n'a jamais détecté la moindre trace...
Quand au code que je mets à disposition sous licence Libre, comme celui faisant l'objet de ce journal, j'attire l'attention sur la section 15 et la section 16 du fichier LICENCE fournit avec les sources. Partant de là, libre à l'utilisateur de, au choix,
Pour la dernière option, cela sera bien entendu réalisé contre rémunération, sauf s'il parvient à me fournir un test case mettant en évidence une faille qui justifie le développement de cette batterie de tests.
Encore une fois, même si moi-même je ne le fais pas, je conseille fortement tout un chacun de soumettre son code à un maximum de tests. Mais, concernant mon code, avec l'historique qu'il a, le gain que m'apporterait ces tests par rapport au temps que je passerais à les développer n'est pas rentable, à aucun point de vue, en particulier, mais pas seulement, du point de vue financier. D'autant plus que, et ton commentaire va également dans ce sens, aucune batterie de test ne peut garantir l'absence de failles.
Pour résumer, compte tenu de l'historique de mon code, de la manière dont il se comporte chez moi (j'utilise quotidiennement plusieurs logiciels que j'ai développés et qui contiennent donc ce code) et chez mes clients, je considère qu'il n'est pas plus vulnérable que la majorité des codes réalisés avec un minimum de sérieux et, de ce fait, probablement soumis à une batterie de tests. Mais je suis tout à fait disposé à réviser mon jugement, pour peu que l'on me soumette un test case prouvant mon erreur, et non pas seulement des considérations théoriques.
Quoi qu'il en soit, je te remercie pour tes remarques qui m'ont données l'occasion de m'expliquer davantage sur le sujet.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...