Ce n'est pas défendre les debian maintainers (si un peu quand même), étant moi même utilisateur de Debian à titre particulier et professionnel. Toutes les machines que j'utilise sont donc sous debian (excepté les quelques redhats (pour les certifs) et sun (raisons historiques) et un hpux (plus utilisé)).
Donc je me trouve bien embêté pour les certificats que je génère en moyenne hebdomadairement pour le parc de machines et les utilisateurs dont j'ai la charge. À titre personnel, ouf, mes clés ssh et certificats sont suffisamment anciens.
Maintenant on peut avoir deux attitudes :
* Jeter le bébé avec l'eau du bain, adopter une attitude à la OpenBSD/De Raadt "tous des cons ils ne pensent pas comme nous".
* Tenter de voir ce qui n'a pas fonctionné dans la chaîne et tenter de l'améliorer, histoire que ça n'arrive plus (le moins souvent possible).
Cela fait un certain temps que je me suis fait la réflexion que le logiciel libre est une chaine dont les maillons les plus faibles sont :
* La compétence des divers acteurs.
* La confiance que l'on peut accorder à ces différents acteurs.
Je comptais faire un journal là dessus pour partager cette réflexion avec des personnes qui pourront peut être m'apporter des éclairages nouveaux et d'autre points de vue sur ma façon de voir les choses. Je vais me contenter d'un post ici (à moins qu'on plébiscite ce post et que la foule en délire me demande genoux à terre d'en faire un journal, auquel cas, je serais magnanime et accèderai à un telle requête).
Le mythe veut que le logiciel libre prévienne contre les codes malintentionnés (spywares ou pas). C'est certainement vrai pour les logiciels les plus populaires. Cependant, pour les logiciels plus confidentiels, trouvés sur une page obscure sur le net, je serais moins catégorique.
Pour peu que le code soit assez conséquent, je doute que le mainteneur prenne le temps de lire tout le code avant de packager le soft.
Et encore là on a un référent. Si le logiciel n'est pas packagé, il faut le compiler soi même. Autant je peut concevoir qu'une personne prenne le temps de relire ce qu'il package. Autant une personne quia un besoin (potentiellement urgent) va, selon moi, compiler le logiciel et l'utiliser le plus vite possible pour répondre à son besoin.
Les limites d'un tel système sont que le logiciel doit être innovant/performant pour attirer des mainteneurs.
Ou alors il faut qu'il package lui même son logiciel. Mais pour ça, il faut montrer patte blanche auprès de la distrib. Ce qui n'est pas facile, mais une proposition d'aide n'est jamais refusée, car, malheureusement, ce n'est pas du luxe.
Donc les logiciels libres sont sûr si :
* Le développeur est clean et compétant (ou que le mainteneur regarde ce que fait le développeur).
* Le mainteneur est clean également.
Et
* Tous les miroirs proposant une iso de la distrib sont proposés par des personnes qui ne sont pas malintentionnées.
* Tous ces miroirs sont sécure (et n'ont pas été rootés).
Aussi quelque chose qui est amusant. De nombreux espaces de téléchargement proposent des logiciels, et, pour vérifier que l'archive a bien été téléchargée, un md5sum ou un sha1sum. Pourquoi pas. Parfois on trouve également une signature (un .asc en général), histoire d'être sûr de la provenance de l'archive. Mais bon si le miroir est corrompu tu as beau avoir 15 signatures, ça ne te dis pas que le source signé est bien celui que tu cherches. À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.
Après cette (trop) longue disgression (toutes mes excuses, je n'ai pas réussi à condenser plus), revenons en à notre exemple Debian/OpenSSL.
Dans ce cas, ce n'est pas la chaine de confiance qui a été brisée, mais la chaine de compétence. Il ne suffit de pas grande chose. Une personne dans une team (dev ou mainteneur) peut à elle seule compromettre un paquet. C'est peut être différent pour openssl qui est une pierre angulaire de la sécurité, mais dans les devs que j'ai suivit, officiellement, toutes les modifications étaient validés par au moins un autre membre de l'équipe (normalement deux).
Or avec le temps et l'habitude, lorsque les patchs venaient d'une personne en particulier, qui est connue pour faire du code propre et bien maitriser son sujet, les codes étaient regardés de plus en plus vite, plus au niveau de l'indentation et des commentaires que l'algorithme autour du patch (comprendre le patch en profondeur et le code qui appelle la fonction modifiée et comment ça peut l'impacter). Or notre dev compétant s'est retrouvé limite sur une sous partie (infime) du projet qu'il maitrisait super bien (euphémisme). Ça a toujours passé jusqu'au jour où ça ne passait plus. Heureusement dans ce cas, pas trop de casse.
Je déborde beaucoup bien sûr. C'était juste pour faire partager mes réflexions. Dans notre cas, il aurait simplement fallu une meilleure communication entre la team de dev et la team de mainteneurs.
Peut être faut-il rapprocher un peu plus les team de mainteneurs des teams de devs . (ce qui semble-t-il a été tenté par les devs de debian, mais sur la mauvaise mailing list).
Pour une erreur mise en lumière, combien passeront inaperçues ?
# Pour info
Posté par ß ß . En réponse au journal Vulnérabilité Debian. Évalué à 10.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332498
Ce n'est pas défendre les debian maintainers (si un peu quand même), étant moi même utilisateur de Debian à titre particulier et professionnel. Toutes les machines que j'utilise sont donc sous debian (excepté les quelques redhats (pour les certifs) et sun (raisons historiques) et un hpux (plus utilisé)).
Donc je me trouve bien embêté pour les certificats que je génère en moyenne hebdomadairement pour le parc de machines et les utilisateurs dont j'ai la charge. À titre personnel, ouf, mes clés ssh et certificats sont suffisamment anciens.
Maintenant on peut avoir deux attitudes :
* Jeter le bébé avec l'eau du bain, adopter une attitude à la OpenBSD/De Raadt "tous des cons ils ne pensent pas comme nous".
* Tenter de voir ce qui n'a pas fonctionné dans la chaîne et tenter de l'améliorer, histoire que ça n'arrive plus (le moins souvent possible).
Cela fait un certain temps que je me suis fait la réflexion que le logiciel libre est une chaine dont les maillons les plus faibles sont :
* La compétence des divers acteurs.
* La confiance que l'on peut accorder à ces différents acteurs.
Je comptais faire un journal là dessus pour partager cette réflexion avec des personnes qui pourront peut être m'apporter des éclairages nouveaux et d'autre points de vue sur ma façon de voir les choses. Je vais me contenter d'un post ici (à moins qu'on plébiscite ce post et que la foule en délire me demande genoux à terre d'en faire un journal, auquel cas, je serais magnanime et accèderai à un telle requête).
Le mythe veut que le logiciel libre prévienne contre les codes malintentionnés (spywares ou pas). C'est certainement vrai pour les logiciels les plus populaires. Cependant, pour les logiciels plus confidentiels, trouvés sur une page obscure sur le net, je serais moins catégorique.
Pour peu que le code soit assez conséquent, je doute que le mainteneur prenne le temps de lire tout le code avant de packager le soft.
Et encore là on a un référent. Si le logiciel n'est pas packagé, il faut le compiler soi même. Autant je peut concevoir qu'une personne prenne le temps de relire ce qu'il package. Autant une personne quia un besoin (potentiellement urgent) va, selon moi, compiler le logiciel et l'utiliser le plus vite possible pour répondre à son besoin.
Les limites d'un tel système sont que le logiciel doit être innovant/performant pour attirer des mainteneurs.
Ou alors il faut qu'il package lui même son logiciel. Mais pour ça, il faut montrer patte blanche auprès de la distrib. Ce qui n'est pas facile, mais une proposition d'aide n'est jamais refusée, car, malheureusement, ce n'est pas du luxe.
Donc les logiciels libres sont sûr si :
* Le développeur est clean et compétant (ou que le mainteneur regarde ce que fait le développeur).
* Le mainteneur est clean également.
Et
* Tous les miroirs proposant une iso de la distrib sont proposés par des personnes qui ne sont pas malintentionnées.
* Tous ces miroirs sont sécure (et n'ont pas été rootés).
Aussi quelque chose qui est amusant. De nombreux espaces de téléchargement proposent des logiciels, et, pour vérifier que l'archive a bien été téléchargée, un md5sum ou un sha1sum. Pourquoi pas. Parfois on trouve également une signature (un .asc en général), histoire d'être sûr de la provenance de l'archive. Mais bon si le miroir est corrompu tu as beau avoir 15 signatures, ça ne te dis pas que le source signé est bien celui que tu cherches. À moins de connaitre la personne qui développe le soft, d'être sûr que c'est toujours lui qui signe les releases et d'avoir sa clé dans ta chaine de confiance.
Après cette (trop) longue disgression (toutes mes excuses, je n'ai pas réussi à condenser plus), revenons en à notre exemple Debian/OpenSSL.
Dans ce cas, ce n'est pas la chaine de confiance qui a été brisée, mais la chaine de compétence. Il ne suffit de pas grande chose. Une personne dans une team (dev ou mainteneur) peut à elle seule compromettre un paquet. C'est peut être différent pour openssl qui est une pierre angulaire de la sécurité, mais dans les devs que j'ai suivit, officiellement, toutes les modifications étaient validés par au moins un autre membre de l'équipe (normalement deux).
Or avec le temps et l'habitude, lorsque les patchs venaient d'une personne en particulier, qui est connue pour faire du code propre et bien maitriser son sujet, les codes étaient regardés de plus en plus vite, plus au niveau de l'indentation et des commentaires que l'algorithme autour du patch (comprendre le patch en profondeur et le code qui appelle la fonction modifiée et comment ça peut l'impacter). Or notre dev compétant s'est retrouvé limite sur une sous partie (infime) du projet qu'il maitrisait super bien (euphémisme). Ça a toujours passé jusqu'au jour où ça ne passait plus. Heureusement dans ce cas, pas trop de casse.
Je déborde beaucoup bien sûr. C'était juste pour faire partager mes réflexions. Dans notre cas, il aurait simplement fallu une meilleure communication entre la team de dev et la team de mainteneurs.
Peut être faut-il rapprocher un peu plus les team de mainteneurs des teams de devs . (ce qui semble-t-il a été tenté par les devs de debian, mais sur la mauvaise mailing list).
Pour une erreur mise en lumière, combien passeront inaperçues ?