Après peut-être faudrait il que les projets fournissent une suite de tests pour que les mainteneurs puissent vérifier que rien n'a rien régressé au moment du packaging ?
Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire make test après la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.
Dans le cas de la faille qui nous intéresse, toutefois :
– je n’ai aucune idée si Kurt Roeckx a testé son patch ainsi, ni plus généralement si cela fait partie du « workflow » Debian de systématiquement exécuter ces suites de test quand elles existent ;
– même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?
[^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
Posté par gouttegd . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 4.
Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire
make testaprès la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.Dans le cas de la faille qui nous intéresse, toutefois :
– je n’ai aucune idée si Kurt Roeckx a testé son patch ainsi, ni plus généralement si cela fait partie du « workflow » Debian de systématiquement exécuter ces suites de test quand elles existent ;
– même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?