IsNotGood a écrit 5009 commentaires

> http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)

Ce patch ne pause pas de problème. Mais ce n'est pas ce patch qui a été appliqué, mais celui ci (je le réécris) :

/* MD_Update(&m,buf,j);*/
...
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif
Oui, le premier MD_Update a été mis en commentaire. Or c'est lui qui ajoute de l'entropie.

> et le "responsable disclosure" qui va avec ?

Qu'es-ce tu racontes ?
Si t'es assez con de divulguer publiquement une faille non encore connue, ben fait le. Personne ne t'en empêche.
Mais il est d'usage, et intelligent, d'en informer que ceux qui s'occupe de la sécurité.

Il faudrait savoir de quoi tu parles...
Il y des failles de sécurité connues, mais connues d'un petit groupe (ceux en charge de la sécurité). Ses failles sont sous "embargos" tant qu'un correctif n'est pas réalisé ou que personne n'a rendu la faille public ou qu'il n'y a pas un exploit.

Je me demandais d'où il tenait cette fausse information. Et donc la question n'est pas bonne.

Sous Linux /dev/random est utilisé.
Notons que beaucoup d'OS n'ont pas un générateur de nombres aléatoires de qualité.

> Les paquets avec un gros patch debian/ + upstream n'existent quasiment plus

J'ai regardé pour iceweasel (2.0.0.14), ça ne semble toujours pas le cas :-)
J'ai manqué de chance ?
Je dis que ça ne semble pas le cas, car je n'en suis pas sûr.
En passant, alors que iceweasel n'est pas audité par Mozilla, il est plus patché que celui de F8 :-) (même version).

Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.

> C'est valable pour énormément de paquets des multiverse, universe et compagnie.

Certe. Mais openssl/gnupg/etc font partit des programmes hypra sensibles (ça n'a rien à voir avec la connerie de LG).

Je veux bien faire un bisou aux pieds du puissant GeneralZod, mais pas plus.

Es-ce qu'on pourrait savoir pourquoi tu poses cette question ?

> On ne peut pas savoir.

Oui.
Mais pour information, Red Hat emploie Mark J. Cox qui est un des quatres "core team" d'OpenSSL.

> On ne peut pas savoir.

On peut le savoir (après coup). Red Hat publie tous les infos. En voici un résumé (par Mack J. Cox :-)) :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)

Il serait bien que les autres distributions fassent de même.

> Une pareille boulette ne s'est pas emcore produite chez RedHat, Novell/Suse, Mandriva....

Certes, mais ça peut arriver. Le 0 risque n'existe pas.

Debian est un projet basé sur le volontariat, ça a ses limites. Le proprio a aussi ses limites.
Ce n'est pas la connerie du mainteneur qui pose question. C'est-à-dire d'avoir virer une ligne de code alors qu'il ne fallait pas. Tout le monde peut ajouter des conneries (par "bêtise" (et ça touche tout le monde) ou simplement par inattention).
Ce qui pose question, c'est d'avoir une faille d'un patch spécifique durant presque 2 ans ! Où est l'audite ?
Ce qui pose question, c'est que les paquets Debian sont assez "obscures". Un gros patch (108 files changed, 3876 insertions(+), 722 deletions(-)) au-lieu de séparer les patchs. Les autres distributions (non basées sur Debian) séparent les patchs, ça facilite grandement l'audit et les remontés upstream.
Ce qui pose question, est que Debian veut faire de la sécurité et se prétend meilleur que les projets upstreams (voire par exemple le débat avec Mozilla/Firefox où Debian voulait faire les patchs de sécurité et n'aimait pas que Mozilla audite ses patchs). Dans le domaine de la sécurité, c'est l'upstream qui faut absolument privilégier.

Ce qui pose question aussi, c'est Canonical. Ça la fout mal pour sa crédibilité en entreprise (genre "on vous vend un truc, mais on audite rien").

Je pense qu'il serait bien bête de mener le mainteneur au bucher. Debian est sur la base du volontariat, si quelqu'un peut faire mieux, qu'il donne un coup de main au mainteneur. Beaucoup apprécient cet esprit de Debian et en connaissent les atouts et faiblesses.

Pour les drivers (et non les logiciels "buzz"), j'ai toujours trouvé les sources.

> et le mot "alien" est un peu trop utilisé à mon goût.

Ben que Debian passe à rpm :-)

> Novell?

Ah bon ?
Ce n'est pas Canonical :-)

> Proliant Support Pack, qui n'est dispo que pour ces deux distros

Pas vraiment. C'est aussi dispo pour Debian si j'ai bonne mémoire.

Le rapport de bug :
https://bugzilla.redhat.com/show_bug.cgi?id=442457

> "il savait absolument pas ce qu'il faisait"

QU'IL NE LE FASSE PAS !

> il acceptait pour le debugging AUSSI des applications contenants openssl.

Il a dit "I'm in favor of removing them". Il n'a pas dit "OK, ça roule ma poule".

Il y a un autre développeur OpenSSL qui répond :
On May 1, 2006 03:14 pm, Kurt Roeckx wrote:
> The code in question that has the problem are the following 2
> pieces of code in crypto/rand/md_rand.c:
>
> 247:
> MD_Update(&m,buf,j);
>
> 467:
> #ifndef PURIFY
> MD_Update(&m,buf,j); /* purify complains */
> #endif

There's your first clue, build with -DPURIFY :-)

Cheers,
Geoff

Mais le "247: MD_Update(&m,buf,j);" est devenu "/* MD_Update(&m,buf,j); */" sans que le développeur OpenSSL le savent.

Regarde la version 199 :
http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
C'est :
/*
* Don't add uninitialised data.
MD_Update(&m,buf,j); MD_Update(&m,buf,j);
*/
Ceci n'a jamais été validé. Et c'est ça qui pose problème.

> I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
> etc

Il n'est pas développeur OpenSSL.


Le mainteneur Debian a fait une connerie. Je ne demande pas une "lapidation". Mais il a fait une connerie et ça peut arriver à toi ou à moi.
Il faut reconnaitre qu'il a fait une connerie. Je ne demande pas qu'il arrête d'être mainteneur !
Si tu ne reconnais pas qu'il y a connerie, tu ne remets pas en cause. Si tu reconnais qu'il y a une connerie, ben tu ne mets pas en place une solution. Par exemple il ne faut plus toucher au "noyau" OpenSSL sans que le patch soit approuvé en upstream (donc il doit être upstream). Etc.

Quand MS fait une connerie, on ne lui cherche pas d'excuses bidons. MS a fait une connerie, point barre. (Ici il faut évidemment distinguer "connerie" de manoeuvre volontairement mal intentionnée).


Parce qu'en gros tu nous dis "tout va bien, tout c'est passé normalement, et ça va recommencer car il n'y a pas de raison qu'on revoir notre façon de faire".
C'est inacceptable.

> enfin la même ceux qui maitrisait le code (les dvp d'openssl) on dis que pour eux c'était ok comme modif.

Arrêtes de répéter ça, ce n'est pas vrai.
Et si c'est vrai, c'est uniquement pour une version de debug.
Hors le mainteneur n'a pas fait sa bourde uniquement sur la version de debug.

Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.

Cet été n'est pas encore.

Place boursière.
NYSE Euronext n'est pas qu'une place boursière.

> c'est faux (pas forcément vrai).

Sauf si les repères ont les mêmes axes (quelque soit la norme). La passage d'un repère à un autre est alors une translation suivant qu'un axe.
Deux repères orthogonaux n'ont pas forcément les mêmes directions. On peut passer de l'un à un autre avec une translation, une rotation, etc.

Je ne vois pas le rapport.
Dans tout repère (et un seul), si tu changes, par exemple, l'ordonnée d'un point, ben tu ne changes pas les autres coordonnée (par définition).
Ceci pour un même repère.
Pour différentes repères, qu'il soient orthonormé ou autre c'est faux (pas forcément vrai).

Comprend pas.

D'autres infos ici :
http://customers.press.redhat.com/2008/05/12/nyse/?intcmp=70(...)
“Too many people forget that the cost of leaving a technology can be substantial. We didn’t want to get locked into any certain technologies, and desired the flexibility to jump to a different hardware platform if necessary,” said Rubinow. “Linux gives us that flexibility. We felt that Linux was right for our environment, so we decided to pursue it full speed ahead.”

> Xguest aurait effectivement pu avoir sa place dans l'annonce.

J'avais fait la remarque pour montrer que SeLinux progresse. Il n'était pas un atout pour le desktop, ça pourrait changer.

Une annonce est un compromis, on ne peut pas tout y mettre.

> NéanmoinsMark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE.

Mais je pene qu'il a tord :-)
En tout cas aujourd'hui.

> Le récent billet de Mark S. est suffisamment explicite à ce sujet.

On peut aussi dire qu'il est implicite dans LTS != RHEL :-)
Cette sorte d'"appel au secours" le montre.

Je suis d'accord, il y a ambiguïté. Commerciallement Canonical veut chasser chez RHEL/SLES, mais techniquement/support/doc/etc ça ne le fait pas.

Si on met en concurrence Ubuntu LTS avec RHEL ou SLES, alors Ubuntu LTS est naze.

Juste un exemple, la doc :
Ubuntu : https://help.ubuntu.com/8.04/serverguide/C/index.html
RHEL : http://www.redhat.com/docs/manuals/enterprise/

Pas de ppc64, pas de s390, pas de ia64.

Il y a un monde entre les deux.

Damned, il n'est pas dit dans l'annonce que Fedora marche sur i386 et x86_64.
Certe, comme tout le monde.
Mais ppc et ppc64 fait aussi parti des architectures supportées.

En passant, F9 n'installe plus les librairies 32 bits et 64 bits en parallèle par défaut.
On peut toujours les installer à la main.

Côté SeLinux, notons que les utilisateurs commencent à être "confinés".
Plus d'info ici :
http://www.redhatmagazine.com/2008/04/17/fedora-9-and-summit(...)

La police "targeted" n'est plus si "targeted".