Trouver puis corriger une faille de sécurité (ou un bug en général) est évidemment un travail non trivial. La procédure va impliquer des échanges comme tu l'indiques avec les principaux partenaires. Mais quand tu en es au point d'être sûr d'avoir une faille de sécurité (tu as circonci le domaine d'application, etc), le correctif n'est souvent pas loin.
L'annonce d'une faille et de son patch sont la plupart du temps simultanés (tu ironisait la dessus et c'est à ça que je répondais à l'origine). Il parait que c'est le cas pour de sombre histoire de politique de sécurité qui sont le sujet ici de beaux trolls a propos de la sécurité par l'obscurité :)
[^] # Re: SIGTROLL
Posté par Hank Lords . En réponse au journal Évaluation des risques de RHEL 4. Évalué à 2.
Trouver puis corriger une faille de sécurité (ou un bug en général) est évidemment un travail non trivial. La procédure va impliquer des échanges comme tu l'indiques avec les principaux partenaires. Mais quand tu en es au point d'être sûr d'avoir une faille de sécurité (tu as circonci le domaine d'application, etc), le correctif n'est souvent pas loin.
L'annonce d'une faille et de son patch sont la plupart du temps simultanés (tu ironisait la dessus et c'est à ça que je répondais à l'origine). Il parait que c'est le cas pour de sombre histoire de politique de sécurité qui sont le sujet ici de beaux trolls a propos de la sécurité par l'obscurité :)
Pour infos, les patches pour la version 4.2 de OpenBSD sont là : http://openbsd.org/errata42.html
La plupart sont 'triviaux' et ne font que quelques lignes, sauf un qui en fait dans les 600 (je ne les ai pas vraiment étudiés non plus).
Maintenant on peut éventuellement revenir au sujet du journal qui concerne RedHat, et pas OpenBSD :)