Globalement, Torvalds nous explique que selon lui, les failles de sécurité doivent être traitées comme les autres bugs. Ni plus important, ni moins, juste pareil.

So I personally consider security bugs to be just "normal
bugs". I don't cover them up, but I also don't have any
reason what-so-ever to think it's a good idea to track them
and announce them as something special.

On peut certes débattre sans fin sur cet argument, mais au fond, ce n'est pas débile. Un bug est un bug, et beaucoup de ceux considérés comme normaux peuvent avoir des incidences en terme de sécurité, au sens large, ne serait-ce qu'au niveau de la disponibilité du système. Un crash ou des pertes de performance sur un serveur de production ne sont jamais du meilleur effet...

Quoi qu'il en soit, un changelog étoffé décrivant tous les bugs corrigés permettrait à chacun de prendre les mesures qui s'imposent. Certains ne patchent que face à des bugs de sécurité, d'autres lorsqu'un bug spécifique est corrigé. Chacun sa politique, et il serait à mon sens un poil présomptueux de prétendre détenir la vérité en la matière.

Le problème de son discours vient lorsque son interlocuteur lui fait remarquer que les failles de sécurité ne sont pas décrites comme telles dans les changelog, et que par conséquent, les utilisateurs ne disposent pas des informations adéquates. Et c'est effectivement parfois le cas. Ce qui est dommage. Parce qu'à mon sens, les conséquence d'un bug, même normal, doivent être documentées. Et donc s'il y a une implication de sécurité connue, elle doit être mentionnée. Je ne pense pas que la plupart des gens soient intéressés par des informations sur l'exploitation de la faille. Ils veulent juste comprendre ce que fait le patch et s'ils sont concernés. Et de mon point de vue, la réponse de Torvalds est un enfumage de première :

So as far as I'm concerned, "disclosing" is the fixing of
the bug. It's the "look at the source" approach.

Parce que parti comme ça, vous n'aurez pas fini d'analyser votre changelog avant la prochaine release. Regardez plutôt. Le 2.6.26 vient de sortir, avec un changelog de 6,2Mo. Celui du 2.6.25, sorti il y a à peine trois mois[1], en faisait 7,4. Il y a plus de 10000 commits dans cette nouvelle version, parmis lesquels se trouvent potentiellement des problèmes de sécurité. Votre mission, si vous l'acceptez, sera de vous palucher le changelog pour identifier tout ce qui sent la poudre, puis aller lire le diff pour voir ce qui se passe réellement pour savoir si oui ou non, il s'agit bien de sécurité et si oui ou non, vous êtes impacté. Le tout avant la sortie du 2.6.27, bien évidemment, et préférentiellement avant la sortie du moindre exploit sur Milw0rm. Good luck Jim.

Le trait est certes un poil grossier, mais c'est je pense un peu l'esprit de la réponse. Donc de choses l'une. Ou les bugs de sécurité sont des bugs comme les autres qui doivent être documentés comme tels, auquel cas la mention de l'impact de sécurité devrait être là. Ou alors, ce ne sont pas comme les autres.

Et le passage sur les gens d'OpenBSD et autres gens de la sécurité, c'est bonus. Vous remarquerez que Dave Miller n'est pas en reste, avec un argument d'autorité :

This complaint about "full disclosure" is coming from
someone who isn't even willing to communicate with the
world using his real name.

Décidemment, il y a des sujets qui fâchent...


Updates : les liens s'empilent. Bonne lecture.

Notes

[1] Et encore, c'est un délai plus long que d'habitude...