- toujours faire auditer le code par des personnes extérieures
Il faut des personnes compétentes, en particulier pour ce bug : des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui est très rare.
- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning
AHEM. La faille a été introduite à cause d'un faux positif Valgrind...
- avoir un code très propre et bien documenté aux passages critiques
- avoir une API simple et claire
L'API OpenSSL est très claire (pas juste l'API publique, l'API interne également).
- avoir une batterie de test la plus large possible
Le problème dans le cas de Debian OpenSSL est que le générateur était parfaitement aléatoire, il passe tous les tests, même les plus complets. Le problème était celui de la graine, et il semble qu'aucun outil ne teste la qualité de la graîne : s'assurer que N générateurs génèrent N suites différentes. Même s'il existe un tel outil, il faut que l'outil pense à exécuter chaque générateur dans un processus différent... Or pour des raisons pratiques, on va préférer tout faire dans le même processus.
Le bug Debian OpenSSL est un cas très particulier et il n'existait pas de test pour détecter le bug. Maintenant, il faut espérer que l'histoire ne se répête pas.
PS : Hasard contient un outil pour tester que N générateurs génèrent N suites différentes. Je parlais d'un test utilisant fork(). Et bien il semble que mon outil ait trouvé un (nouveau) bug, différent. fork() est encore un autre cas :-/
[^] # Re: Test / OpenSSL
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Générer des nombres aléatoires avec Hasard 0.9.6. Évalué à 4.
Il faut des personnes compétentes, en particulier pour ce bug : des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui est très rare.
- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning
AHEM. La faille a été introduite à cause d'un faux positif Valgrind...
- avoir un code très propre et bien documenté aux passages critiques
- avoir une API simple et claire
L'API OpenSSL est très claire (pas juste l'API publique, l'API interne également).
- avoir une batterie de test la plus large possible
Le problème dans le cas de Debian OpenSSL est que le générateur était parfaitement aléatoire, il passe tous les tests, même les plus complets. Le problème était celui de la graine, et il semble qu'aucun outil ne teste la qualité de la graîne : s'assurer que N générateurs génèrent N suites différentes. Même s'il existe un tel outil, il faut que l'outil pense à exécuter chaque générateur dans un processus différent... Or pour des raisons pratiques, on va préférer tout faire dans le même processus.
Le bug Debian OpenSSL est un cas très particulier et il n'existait pas de test pour détecter le bug. Maintenant, il faut espérer que l'histoire ne se répête pas.
PS : Hasard contient un outil pour tester que N générateurs génèrent N suites différentes. Je parlais d'un test utilisant fork(). Et bien il semble que mon outil ait trouvé un (nouveau) bug, différent. fork() est encore un autre cas :-/