IsNotGood a écrit 5009 commentaires

> Quand un logiciel est jugé stable il monte dans la branche 'stable' et tout le monde en profite.

Ce n'est pas pareil.
Avec Fedora, du jours au lendemain (ou presque) tous les paquets sont compilés avec gcc 4.3.
Il y a un release manager (ou un truc dans ce goût) pour tout coordonner. Ce n'est pas qu'un "bac sable".

> Mais je ne vois pas en quoi le fait qu'il y ait des releases améliore la qualité d'un paquet

Je ne parle pas de qualité, mais de développement.
Ces aspects ne sont pas forcément liés.

> tu bosses sur une version, tu apportes (ou pas) ta valeur ajoutée, tu tests et tu délivre le paquet !

Ben justement, Fedora ne fait pas que ça.
Fedora prends des trucs en CVS, bosse sur Rawhide, contribue upstream, etc.

Et tu as bien remarqué que Fedora contribue beaucoup en upstream. Fedora ce n'est pas et ça ne veut pas être seulement packager des logiciels.

> Il y a besoin d'une release pour ça ? Un repo de testing c'est pas suffisant ?

Fedora a aussi son dépôt testing...
Mais ce n'est pas suffisant.



Si t'es très content avec arch, et je n'en doute pas, pas de problème, éclate toi.

> mais j'ai souvent vu des RHEL qui n'étaient pas enregistrées et crois-le ou non, pour administrer ça, c'est la croix et la bannière.

Ce n'est pas vrai :-)
Depuis RHEL 3, RHEL support les dépôts yum.
Donc il suffit, par exemple, d'utiliser des dépôts CentOS.

Tu plaisantes un peu trop et on se sait plus ce que tu penses.
J'adore la plaisanterie !
Mais là... c'est le bordel.

> pour que Debian reste telle quelle est pendant des années !!

L'objectif de Debian n'est pas d'être troué de partout.
C'est d'être un système libre, libre aussi de contraites commerciales. Sur ce point c'est OK.
Mais par manque de décision, à vouloir trop contenter tout le monde, on flirte avec le fisco. Les moyens ne manquent pas vraiment (en tout cas c'est mon impression), mais ils sont mal utilisés/canalisés et le projet dans son ensemble en souffre.
Il me semble que c'est que c'est quelque chose comme ça qu'a voulu dire herodiade. Je ne pense pas que herodiade est devenu est dingue des distributions "commercialement" sponsorisé. Il y va "résigné".

Il me semble que tu fais une erreur de parler de manque de bénévoles.
Si le mainteneur n'avait fait que le minimum (en respectant sa mission de base évidemment), il n'y aurait pas eu problème.

> Ben justement : les développeurs ont moins de boulot dans les "Rolling Release" distros, paradoxalement.

Ce n'est pas ça le plus important.
Avec une release (et donc la phase de développement de celle-ci) tu peux te permettre de tout casser. Tu peux changer de compilateur (ce que fait encore une fois Fedora avec F9), etc.
Il y a une grande liberté et donc aussi une grande efficacité pour le développement (on ne se contente pas de packager, on va plus loins).

Enfin les mises à jours de distribution n à n+1 avec Fedora sont fait hors du système qui va être mise à jour. Tu peux alors passer de ext3 à ext4, changer le format rpm, changer init, etc. Il y a une grande liberté de développement.

Les développeurs Fedora ont une Fedora stable pour le boulot de tout les jours (une F8 ou F9 typiquement). Et ils ont aussi une Rawhide (la branche de développement) pour coder/tester/etc. Si la branche de développement explose, ce n'est pas grave (c'est même courrant et c'est aussi ce qui fait le charme de Fedora pour beaucoup de contributeurs).

> Heu ça je ne pense pas, pas de sitôt.

Il y en aura. Évidemment pas 30 % des utilisateurs Debian actuels.
Mais ceux qui hésitaient, ne vont plus hésiter.

> Et puis même, la QA de Debian est déjà je pense la meilleure que l'on puisse trouver.

QA pour Quality Assurance ?
Tu plaisantes ?
Oui tu plaisantes.

> Autant je ne comprend pas du tout Ubuntu Desktop ou Fedora ou Mandriva et leurs releases tous les 6 mois.

D'un point de vu utilisateur, je comprend que tu ne cromprennes pas :-)
D'un point de vu développeur, c'est sensé.

> Tu ne sais meme ou ca en est, et pourtant tu affirmes que c'est foiré.

Je n'es pas affirmé.
J'ai dit :
- "on a déjà vue des tentatives qui ont bien foiré"
Je n'ai pas dit :
- "TOUTES les tentatives ont foiré".

J'ai aussi ajouté avec un point d'intérogation :
- "Mandriva avec TurboLinux (où en est ce truc ?)"

> * Complètement ahurissant et irresponsable : le correctif sécurité Debian a été
commité, publiquement 5 jours avant la publication de l'advisory !

Heureusement que c'est passsé inaperçu, l'exploit a été publié le lendemain de l'advisory (à 2 heure du mat).
Sinon je vous raconte pas la catastrophe entre des mains mal intentionnées.

> J'ai parcouru les planets et les MLs naïvement pour voir, mais évidemment, la réponse est "rien".

Mouaif.
Disons que c'est le discours officiel aujourd'hui.
L'affaire est trop chaude pour réfléchir à des évolutions. On attend que la poussière retombe.

Je ne crois pas que Debian restera sans rien faire. Ce problème d'OpenSSL est hypra grave car il impacte toutes les distributions (pas seulement les dérivées de Debian). Tout le monde va maintenant vérifier s'il y a pas des clés "made in Debian/etc" dans sa bécane.
Il y a un problème de confiance entre Debian et les autres qui va se poser. J'ai beaucoup de mal à croire que Debian ne va rien faire. Si Debian ne faire rien, c'est très très grave.

> 1) contrairement à ce qui a été écrit plus haut par iZnogood, un openssl standard compilé avec -DPURIFY ne pause aucun problème

Je l'ai dit qu'une fois. Mais t'as raison.
M'enfin, c'est limite un coup de chance.

En tout cas, un développeur ne doit pas penser que c'est pour une version de production. Faire cette erreur est grave. C'est valable pour DEBUG, etc sauf s'il est clairement indiqué dans la doc que c'est supporté.

> Kurt (le développeur Debian à l'origine du patch problématique) a soumis son
patch pour revue sur la liste de diffusion openssl-dev[1]

Non.
Il a soumis ça :
247:
MD_Update(&m,buf,j);

467:
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif

Ce n'est pas son patch.

Ceci dit, ton commentaire est excellent.
Il aurait dû être la dépêche :-)

> Dans cette dernière version, gvfs a remplacé gnome-vfs, mais cette bibliothèque sera toujours présente, justement pour assurer la compatibilité.

Très juste.
C'est seulement la gestion de la compatibilité.
Ce n'est pas fixer la date de sorti de gvfs et ses fonctionnalités pour une distribution commerciale.
C'est une différence énorme.

> Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.

Et surtout ils ne bosseront pas sur la version upstream, ils ne participerons pas au projet en upstream.

> Ce que tu appelles difficulté est en fait une force du libre

C'est clair.


Il y a une chose intéressante. RHEL/SLES amène le libre (tel qu'il est, tel qu'il a évolué librement) aux sociétés commerciales dont beaucoup font du proprio. Mais elles n'imposent pas le monde commercial/proprio au libre.

> personnellement j'aime bien que les différentes distributions aient des versions différentes

C'est aussi plus d'opportunité. Après tout, c'est bien comme ça qu'est né Ubuntu :-)
Un fork de Debian.

> Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
>
> On y croit vachement.

Biensûr qu'on n'y croit pas deux secondes.

L'un des problèmes est aussi le mépris des forces en présence. Ce n'est pas "force" que dans le sens "celui qui a les plus grosses parts de marché où celui qui rapporte le plus pognon".
Si on prend l'aspect pognon, RHEL (et aussi SLES) gagne haut la main. Mais ses dernières ne vont pas imposer leurs calendriers/désires aux projets upstream ni aux autres distributions.
Pourtant Red Hat ne doit pas manquer de communiquants de talent pour enrober des fadaises du style : "synchronisez vous sur nous (ou 2 ou 3 distributions pour que l'intention soit moins criante), c'est bon pour le logiciel libre".
Red Hat ne le dira surtout pas car :
- RHEL répond à des exigences commericiales (pas aux exigences du libre)
- RHEL "se fout du libre", elle répond aux besoins des clients Red Hat, pas du libre.

Ubuntu est comme RHEL dans une certaine mesure.

Évidemment, Red Hat sera ouvert aux participations externes, accèpte très bien que le libre profite de RHEL (CentOS, etc), voire en est heureux. RHEL est aussi une distribution libre (mais commerciale) et Red Hat a toujours eu un comportement presque exemplaire avec le libre.

La "force" de RHEL pour le développement du libre est quasi nulle. Sauf le pognon que ça génère qui est ensuite en parti mis dans Fedora, développeurs upstream, etc. Mais c'est indirect.

Red Hat pourrait faire le coup de Mark S. avec Fedora. La force de Fedora est le développement et surtout le développement en bonne entente avec les développeurs upstreams. En bonne entente et non dans un rapport de force.
Debian pourrait aussi le faire, mais on touche à des problèmes quasi culturels et d'organisation. M'enfin, de par sa nature non commerciale, Debian est bien placé.
Mais même pour Fedora c'est malvenu. Fedora est aussi la base d'un produit commercial.

L'aide qu'a Fedora de la communauté, des développeurs upstream, Fedora la tient de ses participations au libre. Pas d'un calendrier commercial, pas d'un discours bisounours "c'est bon pour le libre". Fedora se met au service du libre (dans une certaine mesure évidemment mais une bonne et belle mesure). Via l'infrastructure (qui est libre dans le cas Fedora :-)), via des développeurs, etc. Pas l'inverse, le libre n'est pas au service de Fedora. Puis Fedora en tire profit car Fedora fait parti du libre et est dans la logique du libre.
Qu'es-ce qui "dicte" le calendrier de Fedora et ses fonctionnalités ?
Sa communauté qui veut une distribution vivante (donc qui sort souvent, avec le dernier cri du libre), ses objectifs (le développement du libre, rien à foutre si le driver proprio bidule explose), les développements upstream et la participation de Red Hat évidemment. Ce ne sont pas des besoins commerciaux (ou très accessoirement puisque Fedora est la base de RHEL).

On peut dire évidemment grosso-modo la même chose pour OpenSuSE.
On peut aussi le dire pour Ubuntu et Mandriva. Mais nettement moins.
Ce n'est pas une critique de Mandriva. Mandriva assume (aussi bien son choix d'être une distribution (partiellement) commerciale que son faible poid et ne joue le rôle de "nouveau leader du libre"). Si on veut un calendrier commercial, être driver proprio friendly, on assure. On ne demande pas gratuitement la coopération du libre pour vous aider à gagner du pognon.

Évidemment, tout ceci ne dit pas que la coopération est mauvaise. Si KDE aligne son calendrier sur Gnome, ça peut peut-être sympa, etc. Mais assurement, la demande ne doit pas venir de Canonical qui est clairement ici motivé par des enjeux commerciaux.


Donc, où veut en venir Mark S. avec cette magouille. Je fais ici une simple supposition.
Mark S. veut :
1) soit créer à une masse critique (Ubuntu + Debian + ....)
2) soit appartenir à une masse critique (RHEL ou SLES)

Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Pour le 2), ben il y a déjà CentOS, Oracle Linux, etc.

Le but est d'avoir, par exemple, Oracle supporté sur Ubuntu. Il n'y a pas de honte à ça. La méthode employée est par contre très très discutable pour ne pas dire pire.

Je vais parler que d'Oracle et RHEL, mais on peut généraliser.

Si Ubuntu est quasi la même chose que RHEL, Ubuntu va dire à Oracle : "on est populaire, vous avez fait tout le boulot pour RHEL, c'est trois fois rien pour vous de supporter Ubuntu".

Ubuntu pourrait faire une sorte de clone de RHEL (un clone pas aussi parfait que CentOS ou Oracle Linux). Mais les acheteurs ne sont pas dupes, ils savent que l'expertise est chez Red Hat et donc il achète du support Red Hat (du support c'est de l'expertise). L'échec d'Oracle Linux en dit long.

Cette voix doit être abandonnée. Ubuntu tente donc de diluer l'expertise de Red Hat. Ubuntu n'est plus alors une repompe de RHEL, mais Ubuntu et Red Hat des acteurs du noyau d'une distribution utilisée par Red Hat et Ubuntu (et d'autres).

C'est malin (quoique pas très nouveau), mais Red Hat (ou Novell) n'est pas con au point de se faire pièger. NB : On parle d'entreprises commerciales !


L'objectif, si je le comprend bien, est respectable. Canonical veut Oracle, etc sur Ubuntu. Mais le moyen utilisé est n'importe quoi.
Il est méprisant pour le libre. Il est irréaliste (sauf dans un cas, j'y reviens). Faut vraiment prendre Red Hat et Novell pour des gogos pour y croire.

Ça allège aussi les coûts d'Ubuntu mais je crois que l'essentiel n'est pas là.

Il serait très bien d'avoir une troisième acteur GNU/Linux pour les entreprises. Mais pas comme le fait Ubuntu. L'insistance de Mark S. montre qu'il y a un vent de panique chez Canonical.

Ou, si ça marche, c'est que Novell est aussi dans la même panique que Canonical et que sa survie dépend d'un partenariat avec Canonical.
Pourquoi pas. Mais le discours pipo de Mark S. me chauffe les oreilles.

Oui.
Ça change rien. Sauf qu'on sait maintenant, preuve à l'appui, que mon anglais est moyen :-)

Debian la distribution la plus sûr.

http://blog.drinsama.de/erich/en/linux/2008051401-consequenc(...)
In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.

Mais qu'elles sont nulles les autres distributions.

> Il est clair que le mainteneur Debian n'est pas un demeuré.

Quoique...
Si on cratte dans le détail, ça fait peur.

> A noter que les versions pristines upstream compilées avec -DPURIFY sont *aussi* vulnérables.

Oui mais on s'en fout car ce ne sont pas des versions de productions diffusées à des millions d'exemplaires.

Pitier, me dit pas que le mainteneur est capable de compiler par défaut avec -DPURIFY ?

Un peu plus tard il a ajouté ce perfectionnement (version 173) :
Index: md_rand.c
===================================================================
--- md_rand.c        (.../rand/md_rand.c)        (révision 164)
+++ md_rand.c        (.../crypto/rand/md_rand.c)        (révision 173)
@@ -468,11 +468,10 @@
                 MD_Update(&m,local_md,MD_DIGEST_LENGTH);
                 MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
 #ifndef PURIFY
-/*
- * Don't add uninitialised data.
+#if 0 /* Don't add uninitialised data. */
                 MD_Update(&m,buf,j); /* purify complains */
-*/
 #endif
+#endif
                 k=(st_idx+MD_DIGEST_LENGTH/2)-st_num;
                 if (k > 0)
                         {

Voici le patch vraiment appliqué :
Index: debian/changelog
===================================================================
--- debian/changelog        (révision 140)
+++ debian/changelog        (révision 141)
@@ -23,6 +23,9 @@
     - Make use of invoke-rc.d
   * Add comment to README.Debian that rc5, mdc2 and idea have been
     disabled (since 0.9.6b-3)  (Closes: #362754)
+  * Don't add uninitialised data to the random number generator.  This stop
+    valgrind from giving error messages in unrelated code.
+    (Closes: #363516)
 
  -- Kurt Roeckx <kurt@roeckx.be>  Thu,  6 Apr 2006 20:34:07 +0200
 
Index: rand/md_rand.c
===================================================================
--- rand/md_rand.c        (révision 140)
+++ rand/md_rand.c        (révision 141)
@@ -271,7 +271,10 @@
                 else
                         MD_Update(&m,&(state[st_idx]),j);
                         
+/*                
+ * Don't add uninitialised data.
                 MD_Update(&m,buf,j);
+*/
                 MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
                 MD_Final(&m,local_md);
                 md_c[1]++;
@@ -465,7 +468,10 @@
                 MD_Update(&m,local_md,MD_DIGEST_LENGTH);
                 MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
 #ifndef PURIFY
+/*
+ * Don't add uninitialised data.
                 MD_Update(&m,buf,j); /* purify complains */
+*/
 #endif
                 k=(st_idx+MD_DIGEST_LENGTH/2)-st_num;
                 if (k > 0)

> En effet il a demandé, c'est donc pas si simple ...

Si c'est simple.
On lui a dit de virer les lignes qu'il pointait *que* pour Valgrind, pour débugguer. Ce qu'il a fait pour un MD_Update() (avec "#ifndef PURIFY"). Mais il en a virée aussi pour la version en production. Pour la version de production il n'a pas utilisé "#ifndef PURIFY", il a simplement mis la ligne en commentaire...
La mise en commentaire de cette ligne n'a pas été proposé sur la mailing openssl-dev et c'est elle qui pose problème.
Il n'a pas eu de patch proposé.

Il a dit "voila, j'ai ça, vous en passé en quoi ?". Puis a un appliqué autre chose que ce qu'il a montré sur openssl-dev (il n'a pas montré qu'il allait inconditionnellement virer un MD_Update).
Suffit de comparer le mail qu'il a envoyé à openssl-dev et le svn.

> Quant à le traiter de sous merde

Non, il ne faut pas le traité de sous merde.
Mais il a merdé et il faudrait arrêter de dire qu'il n'a pas merdé.

> A chaque fois que tu ose faire une modif, tu l'envoie en upstream, tu attend qu'elle revienne (si elle revient!), puis tu continue a travailler (les autres modifs peuvent dépendre de la premiere)? Tu dois pas etre très efficient.

Si tu ne le fais pas, t'assume.
Tu ne viens pas pleurnicher après avoir fait ta connerie.

> bizarrement, le risque d'erreur (virer les deux lignes plutot qu'une seule, ...) en faisant le patch est ENORMEMENT diminué.

Et comme MD_Update() est utilisé 16 fois dans le même fichier source...
Et comme il n'y a pas que MD_Update qu'il ne faut pas virer...

Bref, tu finis par avoir plus de commentaires que de code.

Si tu veux virer une fonction et ne sait pas ce quel fait, ben tu lis le code de la fonction (ou sa doc). Et même s'il y a un commentaire, tu le fais.
Ça se retrouve une fonction :-)
Pour MD_Update, c'est un poil compliqué, mais c'est "int HASH_UPDATE ..." du fichier crypto/md32_common.h.
M'enfin, s'il voulait débugguer, le débuggueur te montre ça en deux cliques. Et un bon débuggueur (comme DDD) ne montre les variables modifiées durant l'appel de la fonction.
Et cette fonction fait clairement des choses (inutile dévoir un débuggueur). Certe je ne sais pas exactement ce que ça fait, mais ça le fait et pas qu'en lecture seule.
Sachant que la fonction modifie ses paramètres d'appel et que ces derniers sont utilisés ailleurs, la conclusion est toute trouvée : Ne pas y toucher !

> bizarrement, le risque d'erreur (virer les deux lignes plutot qu'une seule, ...) en faisant le patch est ENORMEMENT diminué.

Ben il te reste à le faire pour 1 ligne sur 2 d'OpenSSL.
Il y a seulement un peut plus de 440 000 lignes de codes.

Bon plaisir à toi.
Et tu dois le faire le faire puisque tu trouves normale qu'un développeur vire une ligne s'il n'y a pas un commentaire qui dit qu'elle est indispensable.

J'espère ne pas tomber sur ton code.

Mort de rire :
http://dilbert.com/strips/comic/2001-10-25/