IsNotGood a écrit 5009 commentaires

> Il faut noter que cette version de Fedora est importante car elle servira de base à la prochaine RedHat Entreprise Linux

Pas sûr du tout. Les beta de RHEL ont toujours été basées sur une beta de Fedora.
Pas de beta de RHEL durant le développement de F11, donc très probablement la prochaine RHEL ne sera pas basée sur F11.
Le prochaine RHEL sera aussi l'occasion de pousser de Ovirt et Freeipa qui sont des projets très ambitieux mais non encore prêt à la consommation. KVM qui sera le coeur pour la virtualisation de RHEL 6 n'est pas encore au niveau de Xen (les drivers paravirtualisé pour Windows ne sont pas terminés). Enfin, SPICE (bureau distant et qui sera intégré à Fedora et RHEL) n'a pas encore été ouvert, c'est une promesse de Red Hat, et est très important dans son offre de virtualisation du desktop.
On commence à bien deviner ce que sera la futur offre de Red Hat autour de RHEL, donc RHEL 6 sera probablement basée sur F12.

Il y aura au moins 6 versions de Fedora pour une version majeure de RHEL ! Avant c'était 3 ou 4.

La situation avec gcc/egcs n'est pas comparable.
Des développeurs de gcc n'étaient pas contents de la gestion du projet. On n'est pas cette situation pour le libc.

C'est quoi ce linchage d'Ulrich Drepper ?
Ulrich Drepper n'a pas le monopole de la libc. Il n'y a pas que lui qui refuse ces patchs.
Si vous êtes si balaise et Drepper si mauvais, faites un fork.
Ulrich Drepper a fait un boulot considérable. Il n'a pas fait que critiquer.

A croire qu'il n'y a que Ulrich Drepper qui bosse sur la libc quand on te lit...
S'il ferme le rapport de bug et qu'aucun développeur de la libc ne lui donne tort, ben c'est qu'il a raison.

J'ai l'impression que ça fait dix ans qu'on lit des papiers de keith packard bossant sur des trucs géniaux qui vont sortir xfree86 xorg de la préhistoire et qui nous annonce qu'on est au bout du tunnel
...
En attendant j'ai une carte ati et c'est pas la joie.

Keith Parckard a au début été connu sur des travaux innovants. Il faisait un boulot de "laboratoire". Maintenant on passe à la production. Je crois que F11 a kms et dri2 pour certains chipsets par défaut.
Il n'a pas promis au début de ses travaux que tout serait réglé dans la semaine. Ici encore, il dit que ça va prendre du temps et que cette période est délicate.

Désolé, je ne t'ai pas compris.

> Bah si quand même, ça monopolise ton attention

Le système Ubuntu monopolise autant l'attention que la version classique. Dans la version classique, tu peux ignorer les notifications qui te sont sans importances.

> sauf que tu ne peux rien en faire

Dans le cas Ubuntu, ce qui est frustrant.

http://dictionnaire.sensagent.com/notifier/fr-fr/
faire connaître expressément, informer, annoncer, faire part de.

Informer != notifier.
dlp m'informe, il ne me notifie rien.

> À notifier ?

- Attention, machin t'envoit une balle.
C'est con, t'as les mains menottées au dos.

Notifier c'est demander l'attention. Mark S. fait le non sens de vouloir faire des notifications qui ne demandent pas d'attention. Ce n'est plus qu'un gadget. Autant les virer.

Les gens voient toujours l'incompatibilité de la GPL à cause de la GPL.
Mais une incompatibilité c'est dans les deux sens. Je ne peux pas mettre du non compatible GPL dans du GPL, je ne peux pas mettre du GPL dans du non compatible GPL.

> Pour autoriser certains développeurs à interdire l'accès à leur code aux drivers propriétaires.

C'est l'inverse. Qu'importe.
Pour le noyau qui est sous GPL, il y a deux écoles : Linus et RMS (ils ne sont pas uniquement en opposition). Certains pensent qu'un modules noyau est seulement une utilisation du noyau et d'autre qu'un module est un travail dérivé du noyau. Pour satisfaire presque tout le monde il y a ce que tu qualifies d'horreur A TORT !

Vu sur lwn.net, ça m'a trop fait rire.

Je dois reconnaitre que je ne comprend pas toutes ses "diabolisations".
De toute manière Sun mourait.

Je ne voyais pas l'intérêt pour IBM d'acheter Sun (trop de doublon), mais pour Oracle c'est sensé.

En tout cas ça ne peut pas être moi, j'en avais fait un journal il y a plusieurs semaines...

> D'ailleurs je me demande comment Fedora a pu mettre cela comme version final,

Comme d'habitude, avec talent.

> Comme tout les gestionnaires de paquets que je connais

Ce n'est pas le cas de smartrpm ni de apt (ou synaptic ?).

> d'où l'intérêt des epochs.

C'est un autre problème. On peut avoir une mise à jour qui diminue la version du logiciel si l'epoch est supérieur. Ça reste une mise à jour.
Afin ça ne peut pas être utilisé pour l'attaque donnée.

Bien vu. J'aurais dû réfléchir un peu plus.

> Les meta données vont dire A a besoin de C et B a besoin de C alors que c'est faux

Mais A, B et C doivent être des paquets signés.
Imaginons que C est httpd, ben httpd (comme presque tous les services) n'est pas activé par défaut. Il faut une opération manuelle.
Et pour les bécanes qui ont déjà httpd, ça ne change rien (le downgrade sera refusé). On peut trouver quelques cas spéciaux. Par exemple l'ajout de php active son support dans httpd.
Tu as raison, mais c'est assez la galère...

> Donc l'idée c'est que quand tu sait qu'un paquet quelconque du dépôt a un trou de sécurité tu peux forcer son installation lors de l'installation de n'importe quel autre paquet.

Certes, mais ce n'est que du théorique.
S'il y a une faille, il y a une mise à jour rapidement (si la faille est sérieuse).
Celui qui veut exploiter ce type de faille n'est pas plus en avance que ceux qui maintiennent la distribution.
La distribution met à jour, j'installe la mise à jour.
Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade. "Pire", si un paquet ne peut être mis à jour car un autre paquet l'empêche, Yum signale une erreur. Par exemple si le craket a mis un paquet avec "require kernel = 2.6.28.6-52" et qu'il y a un kernel supérieur, il y a alors une erreur. NB: dans ton scénario le cracker ne peut fixer la version, il doit utiliser une vieille version.
Yum récupère les mirroirs auprès de http://mirrors.fedoraproject.org/ . Le mirroir utilisé par yum varie d'une exécution à l'autre.
N'est pas dans la liste de mirrors.fedoraproject.org qui veut. Les mirroirs sont validés. Certes ce n'est pas une validation poussée, mais si un mirroir déconne, il est viré.

Dans tout ça, le cracker a bien meilleur temps d'attaquer les machines non encore à jour (et elles sont nombreuses !) que de se casser les couilles a faire un fake de mirroir.
Le problème des machines non à jour est BEAUCOUP plus grave. Les applets qui invitent à mettre à jour le système lorsque nécessaire sont indéniablement une avancée.

Enfin, contrairement à d'autre, Yum ne tolère pas qu'un paquet ne soit pas mis à jour.
Exemple qui marche avec apt (ou smartrpm) :
- installation de titi qui demande "kernel = 2.6.28"
- arrivée de la mise à jour de kernel vers 2.6.29
- apt ne dit rien alors qu'il ne peut appliquer une mise à jour ! Yum gueule.

Ceci est un problème bien plus grave que celui que tu donnes.
Autre problème grave, l'exécutions des scripts rpm. Ces scripts sont exécutés sous root. Il serait bon que ses scripts ne soient autorisés que pour certaines signatures. Dans le même esprit, ses paquets ne pourraient pas installer de fichiers dans /etc/rc.d/ , etc, ni de fichier sid, etc.

Certes Yum a tendance à pester souvent. Mais c'est intentionnel, c'est pour des raisons de sécurité. Ce rapport n'a fait que survoler les problèmes de système de paquet et sous un angle bien classique...

> Ca veut dire qu'il fait n fois la resolution de dépendances

C'est même fait 3 fois...
- 1 fois par yum afin de savoir ce qu'il faut télécharger. Ben oui, et tout le monde doit le faire, ça n'a rien de spécifique à Yum.
- 1 fois par rpmlib (demandé par yum) dans une transaction "à blanc" (pas de modification du système de fichier ou de la base rpm). Mieux vaut voir les problèmes au plus tôt que durant l'installation.
- 1 dernière fois par rpmlib qui fait enfin le boulot.

Mais en fait la résolution de dépendance pour déterminer les paquets nécessaires n'est faite qu'une fois. Les fois suivantes ne sont que des vérifications. Par mesure de sécurité, Yum ne demande pas à rpm (librpm) d'installer des paquets avec "--nodeps" ou autre (le comme fait (ou faisait ?) apt-rpm).

> ca serait vraiment très très lent

Le seul truc que fait Yum en plus des autres, c'est la transaction de test. Si elle échoue, il y a un bug au niveau de Yum.
Yum ne cherche pas à être rapide au détriment de la sécurité/fiabilité.

> Donc l'idée c'est que quand tu sait qu'un paquet quelconque du dépôt a un trou de sécurité tu peux forcer son installation lors de l'installation de n'importe quel autre paquet.

Certes, mais ce n'est que du théorique.
S'il y a une faille, il y a une mise à jour rapidement (si la faille est sérieuse).
Celui qui veut exploiter ce type de faille n'est pas plus en avance que ceux qui maintiennent la distribution.
La distribution met à jour, j'installe la mise à jour.
Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade. "Pire", si un paquet ne peut être mis à jour car un autre paquet l'empêche, Yum signale une erreur. Par exemple si le craket a mis un paquet avec "require kernel = 2.6.28.6-52" et qu'il y a un kernel supérieur, il y a alors une erreur. NB: dans ton scénario le cracker ne peut fixer la version, il doit utiliser une vieille version.
Yum récupère les mirroirs auprès de http://mirrors.fedoraproject.org/ . Le mirroir utilisé par yum varie d'une exécution à l'autre.
N'est pas dans la liste de mirrors.fedoraproject.org qui veut. Les mirroirs sont validés. Certes ce n'est pas une validation poussée, mais si un mirroir déconne, il est viré.

Dans tout ça, le cracker a bien meilleur temps d'attaquer les machines non encore à jour (et elles sont nombreuses !) que de se casser les couilles a faire un fake de mirroir.
Le problème des machines non à jour est BEAUCOUP plus grave. Les applets qui invitent à mettre à jour le système lorsque nécessaire sont indéniablement une avancée.

Enfin, contrairement à d'autre, Yum ne tolère pas qu'un paquet ne soit pas mis à jour.
Exemple qui marche avec apt (ou smartrpm) :
- installation de titi qui demande "kernel = 2.6.28"
- arrivée de la mise à jour de kernel vers 2.6.29
- apt ne dit rien alors qu'il ne peut appliquer une mise à jour ! Yum gueule.

Ceci est un problème bien plus grave que celui que tu donnes.

Certes Yum a tendance à pester souvent. Mais c'est intentionnel, c'est pour des raisons de sécurité. Ce rapport n'a fait que survoler les problèmes de système de paquet et sous un angle bien classique...

C'est limite n'importe quoi car c'est un problème sans solution (sauf à accèpter une "autorité", par exemple Red Hat ou Novell, qui dit ce qui est bon ou non).
C'est le problème classique de la chaine de confiance.

> - YUM, URPMI et Portage ne signent pas le fichier racine des métadonnées des paquets mais seulement les paquets eux-mêmes. Ces gestionnaires sont donc vulnérables aux attaques par manipulation des métadonnées.

Pour yum, bof.
Si tu manipules les métadonnées de Yum, ça n'ira pas loin. Ce qui est pris en compte pour l'installation sont les informations des paquets (pas de yum). Les informations de Yum sont seulement une optimation (afin de ne pas avoir à télécharger tous les paquets rpm). Les informations de yum sont (normalement) seulement l'extraction des informations des paquets rpm.
Si les métadonnées de Yum sont manipulées, il y aura échec de l'installation des paquets. Yum accèpte, mais rpm qui a le dernier mot refuse. Notons bien que Yum ne fait pas d'installation de paquet, il demande à rpm (librpm qui fera les vérifications avec les données des rpm et non de yum) de le faire.

C'est vraiment à mon avis un petit problème. Un problème que je juge grave et que malheureusement Fedora refuse de prendre en compte depuis des années, est la non-signature systématique des rpm de Rawhide. Certe Rawhide n'a pas à être utilisé en production. Mais Rawhide est souvent installé en parallèle avec un installation qui a des données sensibles (clée gpg, etc).
A moins de débrancher les disques avec des données sensibles ou de faire une installation sur une machine virtuelle, il n'y a pas de parade.

C'est à toi tout ces p0rns ?

Si tu veux.

> si tu te fait attaquer en justice pour non-respect des brevets

Mais MS attaque aussi... Donc qu'on attaque MS, "légitime" les attaques de MS.
MS est un mauvais joueur, mais un joueur. Linux ne veut pas être un joueur et c'est ça que n'aime pas MS.

> Mais je trouve assez amusant que cette condamnation tombe si peu après l'affaire TomTom.

Ça n'a rien d'amusant, MS montre qu'il joue le jeux. MS n'a jamais remis en cause le principe des brevets. MS attaque TomTom, d'autres attaquent MS. Tout est normal dans le pays des brevets, circulez.

> Rien à voir rien à voir, c'est un peu rapide ta conclusion.

Rien à voir de chez rien à voir, le bench en question n'est même pas un bench graphique. Donc inutile de chercher un troll là où il n'y en a pas.

> Sinon pour l'optimisation, je comprends pas, quelle bonne raison y-a-t-il pour qu'elle ne soit pas activée aujourd'hui

Je n'en sais rien. Mais la théorie du complot ne doit certainement avoir aucun rapport.

Linux a pas mal de code sous BSD/GPL.