Il y a plus de trois mois, l'un des pontes de la PHP Secrity Response Team, Stephan Esser, décidait de quitter le navire. Il était alors en total désaccord avec la manière dont étaient gérées les réactions aux découvertes de failles et bogues PHP, qui étaient selon lui bien trop lentes.



À cette occasion, ce dernier avait annoncé qu'il programmerait un « Month of PHP Bugs », à traduire « Mois des Bugs PHP ». Au programme de ce mois des bogues : publication, chaque jour, d'une faille ou d'un bogue PHP, accompagné de détails le concernant ainsi que sa méthode d'exploitation. Toutes sortes de failles seront visées lors de ce mois, mais elles ne concerneront aucunement l'usage potentiellement dangereux pouvant émaner de l'utilisation du langage de programmation.

Aujourd'hui, nous sommes déjà au onzième jour de ce mois très médiatisé pour PHP.

Le but d'un tel mois, selon ses créateurs, est d'améliorer la sécurité de PHP, en exposant de manière brutale les différentes failles dont il est composé. Ces derniers précisent d'ailleurs qu'il ne s'agit pas « d'une attaque, d'une revanche ou d'une conspiration » contre PHP, ni contre ses créateurs.

L'intention est louable, puisqu'elle exposera à la lumière de tous les utilisateurs de PHP les différentes failles qu'il comporte, et permettra ainsi aux créateurs du langage d'être plus réactifs face à ces dernières. On peut cependant remettre en question l'étique d'un tel projet. En effet, les créateurs publieront (et publient déjà) systématiquement, à la vue de tous (et surtout des pirates), la faille, sa documentation, ainsi qu'une démonstration de son utilisation, et ce, à l'aide d'un code d'exploitation.
Toutes ces mesures sont vivement critiquées, puisqu'elles donnent toutes les cartes aux mains des pirates, leur permettant d'exploiter le plus facilement possible ces failles, mettant ainsi en danger des dizaines de millions d'utilisateurs.
Les auteurs se défendent en prétextant que ce code est « très » important. En effet, selon eux, de nombreuses personnes croient que la faille n'est réellement exploitable qu'avec un exemple. Ils avancent également que l'absence de démonstration est la raison essentielle du retard de correction des failles.

D'accord, mais qui cherche-t-on à appâter ? L'utilisateur lambda ne comprenant strictement rien à ces histoires de failles et bogues (et qui n'en a, généralement, rien à faire) ? Les créateurs de PHP (ouéééé, on est plus fort que vous) ?
Les créateurs de ce mois vous répondront qu'ils ne cherchent à appâter personne, qu'ils ne veulent que l'amélioration de PHP. Cependant, n'y avait-il pas de meilleurs moyens pour y parvenir ? Des moyens moins dangereux pour les dizaines de millions d'utilisateurs ? Officieusement, sans doute que oui. Officiellement, non.

Le site du « Mois des bogues PHP »