IsNotGood a écrit 5009 commentaires

> il y a des moyens pour tester un générateur aléatoire et sa répartition

Je ne suis pas un mathématicien, et je suis peut-être dans l'erreur.
M'enfin, il n'y a une différence entre tester si du 32 bits est alétoire et le qualifier ; et si du 1024 bits (voire plus) est alétoire et évaluer sa qualité.
Juste pour vérifier si "seulement" 512 bits sont alétoires...

> Et les stats nous informe qu'on a pas besoin de tester tout l'ensemble des possibilité pour avoir une idée du générateur.

Les stats nous enseignent aussi que pour avoir une bonne présition, ben il faut beaucoup d'échantillons.

> Alors je dis pas que ca se fait en claquant des mains, mais ca reste faisable, et a mon avis , techniquement calculatoire dans un délai raisonnable (moins d'une semaine) meme pour des nombres de 1024 bits.

la racine carrée de la racine carrée de racine carrée de la racine raccée de 1024 bits donne seulement 18 milliard de milliard de combinaison.
Prenons (soyons fou) 1 milliard de combinaison par seconde, il faut seulement 585 années...

Petite vidéo du boss sur F9.
Intéressant pour ceux qui ne connaissent pas Paul Frields :
http://www.redhat.com/v/magazine/ogg/Fedora9PaulFrields.ogg

Dans le cas de ELF, PID aléatoire, etc, c'est très limité comparé à ssl.
Avec ssl il te faut des siècles pour faire toutes les combinaisons.

> Donc il faut bien vérifier la qualité de ces aléas via des mesures statistiques ET automatiques.

Ça semble tout à faire mesurable pour les adresses variables, PID, etc.
Pour des trucs de 1024 bits, à moins d'une "catastrophe" comme ici, ça doit être un sacré défi.

> Les brutes forces ont aussi des chances de réussir si on n'est pas capable de certifier la qualité de son aléa.

Pas vraiment. Si tu ne sais pas qu'openssl a une faille, la tentative de brute force peut prendre des plombes (comprendre siècle).

> Il y a bien un moyen d'écrire une mesure

Les brute-force n'ont des chances de réussir que si on connait déjà une faille...
Ça se mord la queue.

> Les dev d'openssl ont un poil la responsabilité vu la superbe documentation du code incriminé,

Donc le mainteneur ne savait pas ce qu'il fesait, mais il a bien de le faire...
Tu m'expliques ?

> et le fait que valgrind gueule bien.

Garde l'ancien OpenSSL de debian alors...


Oui, un code bien documenté c'est mieux qu'un code mal documenté.
Oui un programme qui passe Valgrind c'est mieux qu'un programme qui fout des tonnes de warning.

Mais un patch qui fout le bordel, c'est pire et de très loin des maux que tu cites.


C'est très bien d'expliquer ce qui c'est passé. Il est clair que le mainteneur Debian n'est pas un demeuré.
M'enfin, c'est de sa faute. Les excuses de code mal documenté, etc ne tiennent pas.
Et ça serait quoi un code bien documenté ?
Un code dans ce goût :

/* NB : ne pas supprimer cette ligne.
Elle n'est pas là pour rien. */
MD_Update(&m,buf,j);

Si le mainteneur pense que la ligne est la pour rien, ben il envoye un patch en upstream et il attend que le patch soit upstream. Pour une chose aussi sensible qu'OpenSSL, ça devrait être fait. Que le code soit mal documenté, qu'il passe mal valgrind, etc.
Si le patch est ignoré durant plus d'un mois, ben il l'envoie à nouveau en poussant gueulante et en demandant des explications.
Il a parfaitement le droit de le faire dans ce cas, car en envoyant un patch il devient un contributeur.

Je dis ce qui se fait en général, d'autres disent "ça dépend".
Très intéressant.

Et si tu laissais les "experts" avoir un avis en premier ?
Je suis neuneu quand ça touche à la sécurité.
Quand je trouve ce que je crois être un trou de sécurité, j'en informe les experts en privé. Je ne vais pas inventer dans mon coin ce que je crois être la meilleur solution pour gérer le problème.
Et toi ?

> J'aimerais savoir combien de développeur d'OpenSSH utilisent debian comme poste de travail ?

0 manifestement.
Si les patchs ne sont pas remontés upstream, c'est un signe qui ne trompe pas.

Très bien, exprique au trou du cul de prétentieux que je suis, ce qu'on doit faire ?
Ou du moins, ce qui devrait être fait et n'est pas fait.

Parce que les "je coupe les cheveux en quatre pour casser un raisonnement", ça me brise les couilles.

> Ce fiasco montre plusieurs disfonctionnements dans le developpement de Debian, faut arreter avec les "ça peut arriver à tout le monde"

Les deux sont vrais.
Debian a merdé, mais ça peut arriver à tout le monde.

Ce qui est agaçant c'est le :
- "ça peut arriver à tout le monde" DONC "Debian n'a rien à se repprocher".
Ceci est faux.

> Mais maintenant, tu prétends que si un cracker la découvre, elle est publique.

Si un cracker la connait, tu peux supposer que plusieurs crackers la connaissent, tu peux supposé qu'il n'a pas envis de coopérer à un embargo, etc.
Si un cracker la connait, tu peux supposé qu'elle est public (il peut la rendre public du jour au lendemain), que l'embargo à fourré, etc.
Si un cracker la connait (donc l'utilise), il faut prévenir les utilisateurs (désactiver sshd, réajuster les fichiers de configuration, etc). Prévenir les utilisateurs empêche tout embargo, donc la faille est public.
etc.

Mais c'est trop compliqué pour vous de réfléchir donc j'arrête ici.

> Sinon pour le reste pas la peine de te répéter

Manifestement tu n'as toujours pas compris.

Mouaif.

L'"embargo" est quelque chose pris très au sérieux. On peut trouver plein de rapports de bug de sécurité sur http://bugzilla.redhat.com/ ou le correctif est trouvé avant la fin de l'embargo. Et bien Red Hat attend la fin de l'embargo pour diffuser le correctif. C'est être "urbain" avec les autres utilisateurs/distributions.
Tant qu'on peut tenir l'embargo, ça donne du temps pour paufiner le correctif, ça donne du temps aux autres distributions, etc.
C'est quelque chose de très important. Et ce n'est pas obligatoire ! Ce n'est pas à confondre avec de la censure par exemple.
Enfin, on en voit pas des embargos se prolonger sans justification.

> un cracker qui aura découvert la faille à sa façon

Dans ce cas la faille est public !
Même si elle n'est pas annoncé sur les tois, elle est public !

Dans les autres cas, c'est à celui qui a découvert la faille de décider s'il veut la rendre public ou seulement contacter les responsables de la sécurité.
L'usage (ce n'est pas un obligation) veut qu'on contacte uniquement les responsable de la sécurité. Il y aura un "embargo", mais on ne te demande pas de signer un accord pour ne pas divulguer la faille. On compte sur ton intelligence, ta "courtoisie", pour ne pas le faire.

> C'est d'ailleurs pour ça que debian utilise iceweasel et non pas Firefox

Ce que manifestement tu ne veux pas comprendre, c'est que Debian n'est pas obligé d'utiliser tout le temps le nom Firefox !
Le "Firefox" dans Rawhide (Fedora) est souvent nommé Minefield (le nom donné automatiquement lorsqu'on ne demande pas explicitement Firefox). C'est Minefield si un patch n'a pas été édité, si c'est une version béta (pour FF3 beta 5 c'est OK), etc.
Et ça ne dérange personne chez Fedora.

Si vous ne voulez/pouvez pas utiliser le nom Firefox (et ses logos), c'est qu'une options à virer. Les autres le font sans problème. Mais virer une option pour Debian devient insurmontable...
Franchement, c'est être tête de mule.

Ajoutons aussi KVM dont les travaux sont à 2 / 3 terminé.

> Pour proposer un ext4 utilisable

Il me semble qu'il est clairement non raisonnable de proposer ext4 pour RHEL si ext4 n'a pas subit l'épreuve des utilisateurs via F10 (période béta + 3 ou 4 mois après la finale).
E2fsck n'est même pas encore finit pour ext4 (une mise à jour est prévue pour F9).

Il y a un évènement intéressant, c'est le prochain FUDCon. Ou le prochain Red Hat Summit. Ils auront lieu en même temps. L'occasion me semble excellente pour Red Hat d'annoncer que RHEL 6 va être basée sur F10.

> Pour avoir un JDK opensource officiel

Red Hat fait le portage pour RHEL 5.2.

> Forcément, là ça change tout.

Je n'ai pas dit que ça changait tout. Et j'ai dit que Red Hat n'était pas à l'abris d'une telle mésaventure.

> Il utilise quelle distrib Chuck Norris, histoire d'avoir un truc vraiment secure ?

http://www.vtech-jouets.com/index.php?art=54&th=384

> man scriptkiddies

Tu n'as pas mieux ?
Si le scriptkiddies la connais, alors la faille est public et même exploité.
On ne parle plus du tout de la même chose.

> Moi j'imagine que PLEIN de personnes ont vu ce patch.

Ce "patch" est noyé dans d'autres patchs (le tout fait 3876 insertions(+), 722 deletions(-)).

> En rendant publique des "o days" ou quasi, on force à la correction.

Non. Tu mets seulement un vent de panique (chez les développeurs et les utilisateurs).

> il vient de te dire que dans certains cas, tu préviens l'upstream d'une faille qui n'est pas corrigé au bout de N mois

Comme il connait cette faille si elle n'est pas public ?

> Or dans ce cas il est de bon ton de diffuser la faille afin de prévenir les usagers et faire bouger l'upstream...

Mouaif.

> d' ailleurs, ce n' est pas une des raisons du traitement à part, non public, dans le bugzilla de redhat ?

Lorsque tu fais un rapport de bug sur une faille de sécurité, il est proposé de mettre le bug en confidentiel. Tu accèptes ou non. Si tu n'accèptes pas de le mettre en confidentiel, il reste public (Red Hat n'y touche pas, il reste public).
Le bugzilla de Red Hat a aussi des rapports de bug de ses clients (via la hot line typiquement). Pour ses rapports de bug, la confidentialité est appliquée. Un client de Red Hat est libre d'utiliser directement http://bugzilla.redhat.com/ et de mettre le rapport de bug en public.

Les rapports de bug de sécurité sous "embargo" en sont pas publics jusqu'à la fin de l'"embargo". À la fin de l'embargo (ou si le bug a été publié), ils sont public.

> c'est donc qu'OpenSSL n'utilise pas /dev/random, non ?

OpenSSL utilise /dev/random (sous Linux), c'est le patch de Debian qui empêche OpenSSL d'utiliser /dev/random.

> C’est un problème dans la façon dont le paquet est distribué sur les miroirs, mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.

Apparament pas pour iceweasel :
http://svn.debian.org/viewsvn/pkg-mozilla/iceweasel/

> Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.

C'est faux.
Si les patchs ne sont pas audités (et validés) alors tu ne peux pas utiliser le nom Firefox. Mais tu peux publier les patchs faire iceweasel, etc. Tout ce que tu ne peux pas faire, c'est utiliser le nom Firefox et ses logos (ce qui est le cas par défaut, et il faut activer une option pour les utiliser).

Je dois être très con, car je ne vois toujours pas où tu veux en venir, quel est ton coup de gueule, etc.

Mais ça ne doit être que moi. Tes propos doivent être limpides pour tous les autres.

> euh .. tu sais voir l'ironie ?

Désolé :-)
J'avais vu que j'avais écrit une connerie, mais j'ai oublié de corriger.

> bon pour le reste tu es de mauvaise foi

Non.

> Et tu vas faire quoi ? Prendre la tapette a mouche et taper sur les méchants dvp de debian

L'erreur de Debian n'est pas innaccèptable. Ne pas la reconnaitre l'est.