> Je veux dire par là que tous les constructeurs actuels "empêchent" le
> flashage de leurs téléphones (sauf éventuelles bidouilles, je ne sais pas
> trop), alors on aura beau avoir n'importe quel soft, on ne pourra rien
> en faire. Quel intérêt pour le "libre" et la liberté des utilisateurs ?
Et bien, on peut porter le logiciel sur une autre plateforme, et l'utiliser ainsi. Et réutiliser des composants du logiciel dans d'autres logiciels (tient, par exemple, dans une bibliothèque pour linux permettant d'interagir/échanger avec des téléphones Symbian...).
Qui n'a pas révé de faire tourner Symbian OS (ahh, ses C:\programs, ses .exe ... ;) sur son desktop, hein, je vous le demande ?
Plus sérieusement, on devrait pouvoir porter l'OS sur des téléphones peu vérouillées (le FreeRunner ? des émulateurs basés sur Qemu ? sur un Zaurus ? ...).
Considérer le logiciel comme « fermé » parce que le matériel (ou une partie du matériel supporté) est vérouillé, c'est se tromper de cible. Linux est libre, même s'il tourne sur Tivo (la preuve : on peut aussi le porter sur autre chose que Tivo).
> Les drivers, ils sont écrits par l'opération du saint esprit ?
Tu semble dubitatif.
Lorsqu'un matériel courant ne dispose pas de driver et que le constructeur fournis les specs, le driver pour linux ne tarde jamais.
à pasBill pasGates : je ne comprends pas ta réponse. Note que
1) je suis relativement d'accord avec ce que tu dis au sujet des applicatifs (mais pas des drivers)
2) la méthode que j'évoque est certainement la moins couteuse, puisque le constructeur n'a, basiquement, rien à faire
3) enfin, cette méthode marche généralement fort bien : il n'y a presque plus de constructeur notable non coopératif (nvidia, atheros et broadcom sont les grandes exceptions).
> mais plutot de bosser sur les problemes techniques qui font que les editeurs ne portent pas leurs softs / drivers sous Linux, a mon avis c'est ca qui est le plus gros obstacle.
En ce qui concerne les drivers, je ne crois pas qu'il s'agisse fondamentalement d'un problème technique (dans la mesure où ce qui est demandé aux éditeurs est de simplement fournir les specs, et le driver libre est écrit rapidement ensuite).
En fait il en existe au moins un à ma connaissance, c'est l'excellent Antidote, de Druide Informatique. Mais il est propriétaire et payant.
Cette indication simplement pour corriger ton exemple, mais je suis d'accord en ce qui concerne l'idée : un utilisateur lambda migrant de Windows à Linux doit souvent accepter de se passer de certaines fonctionnalités ou cas d'utilisations auxquels il était habitué. La situation s'améliore progressivement, mais tout n'est pas résolu. Certains jeux ne marchent pas sous wine (pour les gamers), par exemple. Les logiciel de montage audio et vidéo (ou de conception d'animation flash) ne sont pas forcément très nombreux ni fonctionnels, et là encore, wine n'est pas toujours au rendez-vous.
Je crains que la situation n'empire lorsque le Blu-Ray (ou HD-DVD), qui sont et resteront généralement inutilisable sous Linux (du fait des DRM...), auront totalement remplacé le DVD. Imaginez que vous n'êtes pas très intéressés par l'informatique et le libre, et qu'aujourd'hui, on vous dise : « voila un super OS pour remplacer ton OS actuel ; il marche très bien, mais tu ne peux pas lire les DVD (ou les mp3) ». C'est l'anti killer-feature par excellence. Et c'est pourtant la situation qui nous attends, dans un avenir proche.
Il ne faut pas oublier que udev et hal étant responsable du chargement des modules (et d'une partie du paramétrage du matériel), on leur attribue facilement une lenteur qui est en pratique celle du temps d'initialisation des périphériques (et de leurs pilotes) ; ne serait-ce que demander au lecteur de cd s'il a quelque chose dans le ventre prends beaucoup de temps.
udev & hal sont donc la partie « visible » (ou userspace) de ce temps d'initialisation des périphériques, mais n'en sont pas responsable pour autant. Le symptôme, pas la maladie, etc.
De toutes façons le noyau d'OpenBSD est mono-threadé.
Ils auraient donc d'autres chantiers à abattre avant que l'élimination du BKL ait un réel intérêt.
Cela dit, étant donné que NetBSD bosse activement sur le sujet, ce sera beaucoup moins difficile pour OpenBSD de s'y mettre, le jour où ça leur chantera (plus facile que ça ne l'a été pour Linux ou FreeBSD, par exemple).
> le site d'openssl indique que openssl-dev est pour la librairie et pas les applis
Oui, je l'avais indiqué dans un post précédent mais j'aurais du le rappeller dans celui-ci aussi. Cest aussi ce qui est écrit dans le README des sources de la lib :
« If you would like to submit a patch, send it to openssl-dev@openssl.org with the string "[PATCH]" in the subject. Please be sure to include a textual explanation of what your patch does. »
La remarque de Damien Miller semble la plus pertinente : selon lui, la meilleur façon de s'adresse à upstream en étant lu (et qu'upstream sache qu'on s'adresse à lui, pas qu'on cherche du support end-user), ça reste le patch (diff -u) dans le bugtracker. Ce qui, dans le cas présent, aurait peut-être même permis au développeur Debian d'y trouver la précédente discussion sur le sujet.
Oops, au temps pour moi, c'est en fait briaeros007, qui dit plus haut :
« Les dev d'openssl ont un poil la responsabilité vu la superbe documentation
du code incriminé, et le fait que valgrind gueule bien. »
Les ressources techniques et humaines motivées ne manquent que rarement chez Debian. Le support des archis exotiques ne devrait plus être un frein non plus (celle qui ne suivent pas sont déclassées). Le plus clair de l'efficacité et de la belle énergie de Debian est absorbé par la lourdeur bureaucratique et l'effet de groupe (inertie "conservatrice", résistance au changement).
Il est juste impossible de prendre une grande décision qui implique de vastes changements « parce que c'est toujours mieux à vent » , et qu'après avoir proposé un tel changement sur une mailing-list, avoir débatus des mois sur des mailing-lists, retoqué son projet parce qu'il impliquerai un changement de la constitution debian ou autre formalité administrative, on déclencherai une grande bataille généralisée par mailing-list interposée, jusqu'à ce qu'épuisement s'ensuive. L'aspect administratif et bureaucratique a aussi préséance sur l'aspect méritocratie (quelqu'un d'hyper compétent ne peut pas prendre une décision importante dans son domaine, ou presque). Exemple facile : décider de compiler toute (ou presque) l'archive avec "-fstack-protector" demanderait qu'une personne puisse prendre la décision, et on s'y tient ; mais chez Debian la seule option pour arriver à ça serait d'engager un très long débat sur m-l, essayer de convaincre tout le monde, s'engueuler, peut-être lancer un vote, ...
Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel (et surtout pas une décision du type : tout commit sur les logiciels a, b et c doivent être audités, revues et approuvés par un groupe de relecteurs qualifiés). Ca continuera comme avant.
Au temps pour moi. Cela dit, aux vues du changelog que tu présente :
> Quels paquets devraient être patchés et pourquoi ?
Le paquet openssh-server (et l'ajout d'une dépendance sur le nouveau paquet openssh-blacklist). Pour que ce serveur refuse l'authentification avec une clef connue comme compromise, comme le font désormais les OpenSSH de Etch et celui de Hardy. Et accessoirement, pour disposer de l'outil ssh-vulnkeys (mais c'est moins urgent).
Encore une fois : ce n'est pas parce qu'une machine utilise une distribution qui n'est pas une dérivée Debian, ou n'a pas inclus la version saccagée d'openssl, que cette machine est à l'abri. Il suffit qu'un utilisateur de la machine y ai placé une clef ssh vérolée (générée sur une Gutsy, par exemple) pour que la machine soit compromise.
> C'est surtout que si Debian ne fait rien, elle ne regagnera pas la confiance qu'elle avait et risque des perdre "beaucoup" d'utilisateurs.
Clairement. Je suis aussi un amateur de Debian, adminsys (avec environ 100 serveurs sous Debian a auditer dans l'urgence, youpi ...), et je vais aussi passer à RHEL/Centos/Fedora. La coupe est pleine :
* En novembre 2003, la clef d'un développeur Debian a été compromise, des serveurs Debian ont été piratés. Gros problème. Mais rien n'a changé.
* En juin 2005, plus de mises à jour de sécurité pendant plusieurs semaines (alors que des failles dans spamassassin et sudo couraient), tout ça parceque la security "team" (Martin Schulze) était occupé au LinuxTag et que la nomenclatura Debian (ftp-masters, security team) n'aime pas déléguer ou partager leur pouvoir. Outre les mises à jour, même les annonces de problèmes n'étaient plus faites. Gros problème. Mais rien n'a changé.
* En mai 2008, on apprend cette nouvelle affaire.
* Une intégration très à la traine (parfois inexistante) des technologies de fiabilisation modernes, au moins dans la dernière version dite stable : support SELinux moins que sommaire, pas d'Exec-Shield, pas encore de version intégralement recompilée avec -fstack-protector, pas de FORTIFY_SOURCE, pas de compilation intégrale de l'archive avec -fPIE -pie (Position Independant Executables), pas de restrictions de l'accès à /dev/mem, pas de ELF Data Hardening systématique (ld -z relro), pas de support de la glibc pour les mots de passes chiffré plus sérieusement que DES/MD5, bref, toutes ces bonnes choses dont Red Hat, SuSE et Gentoo disposent depuis un bon moment déjà... chez Debian, la sécurité est la 4em roue de la charrette. Si seulement le suivi des problèmes de sécurité chez Debian était si bon qu'il permetait de se passer de tout ça...
L'erreur est humaine, et ce sont des bénévoles, mais cette liste se concentre uniquement sur les problèmes d'organisation et leurs conséquences, pas le manque de travail : incapacité à décider (ie. forcer l'augmentation da secu team, forcer la compilation avec -fstack-protector, ne pas accépter de packager des progs trop mal codés, ne pas avoir pris de résolution drastique après les deux précédents énormes fiascos, etc) et de laxisme à l'égard de la sécurité, et on voit qu'ils sont énormes. J'adore la souplesse de Debian, j'adore apt, j'adore le fait qu'elle supporte autant de paquets et d'architectures, mais au bout du compte cette distro n'est pas faite pour moi : pour mes besoins, la sécurité compte plus que le reste, et ce n'est donc pas un bon choix de distro.
1- Comme l'indique Ben Laurie, cette liste est de fait surtout utilisée par les développeurs d'applications basées sur openssl, et pas vraiment par les gens qui développent openssl. Ce qui change la façon d'interpréter les mails qui y sont soumis (cf. ci-dessous).
2- Kurt commence son email par "When debbuging applications that make use of openssl using valgrind [...]", et les devs ont clairement pensé qu'il voulait simplement une astuce / un hack lui permettant débugguer/valgrind localement une application utilisant openssl (cf. la réponse du dev openssl : "If it helps with debugging, I'm in favor of removing them."). L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
3- Son email à la forme d'une simple question, et n'envoie pas son code sous forme de patch proposé pour intégration dans openssl. S'il avait envoyé un patch pour intégration upstream, les développeurs l'aurait lu attentivement et refusé (comme ils l'ont fait à chaque fois qu'un patch pour "corriger MD_Update pour valgrind" leur est présenté, ce qui était déjà arrivé avant le mail de Kurt, y compris dans le bugtracker d'openssl, et ce dernier aurait du googler), ce qui lui aurait permis de comprendre que c'est une mauvaise idée.
4- Il ne s'est pas présenté comme "mainteneur du paquet Debian", et il a encore moins annoncé son intention de balancer cette modif pour tout les utilisateurs d'openssl chez Debian et Ubuntu (on en revient au point 2).
Bref, "remonter ses modifications upstream", c'est ouvrir une entrée dans le bugtracker et y attacher sa modification sous forme de patch, et annoncer son statut et son intention de distribuer le patch.
En fait l'initialisation depuis la lib openssl réduit un poil l'entropie de l'aléas retourné par la lib lorsque l'application utilisatrice appelle RAND_add()/RAND_byte() avec un buffer pré-remplis par de l'aléas (par ex. venant de /dev/random), ou lorsque l'OS ne nettoie pas la pile.
Mais effectivement, ce n'est qu'un car particulier et non nécessaire : même si le buffer passé à openssl est non initialisé et remplis de 0 par l'OS, l'aléas retourné par openssl est suffisamment bon. Les devs d'openssl auraient pu décider de se passer de ce petit plus d'aléas potentiel sans grande perte.
ps: et, encore une fois, ce n'est pas le fait de virer l'utilisation de mémoire non initialisée qui pause problème, en soi, c'est le fait d'enlever au passage l'appel à la fonction qui mixe cette zone de mémoire avec du vrais aléas.
* Le second appel à MD_Update(), celui qui était dès le départ encadré par
un '#ifdef PURIFY' est totalement facultatif. Donc :
1) contrairement à ce qui a été écrit plus haut par iZnogood, un openssl
standard compilé avec -DPURIFY ne pause aucun problème . Et
2) on peut aisément comprendre qu'une lecture rapide/superficielle du code
ou du patch conduise à croire que le premier appel à MD_Update(), dans le
même fichier, puisse être traité de la même manière (ce qui n'est en fait pas le cas).
* 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], ce qui n'a pas
suscité de mise en gardes (mais l'upstream n'a pas choisi d'intégrer ce
patch, et pour cause). Cette façon d'échanger avec l'upstream présentait
cependant plusieurs graves défauts, comme le signale d'ailleurs Damien Miller
(le développeur principal d'OpenSSH)[1] :
1) openssl-dev est en pratique une liste d'utilisateur d'openssl (ou de
développeurs d'applications utilisant openssl), et pas la liste des
développeurs de la lib openssl (openssl-team), et encore moins le bugtracker.
Seulement la description de la liste sur le site d'openssl ne reflète pas ce
fait.
2) Il n'a pas du tout précisé qu'il était mainteneur du paquet debian et
qu'il comptait y intégrer ce patch et le distribuer à tout les utilisateurs.
Vu que son mail parle seulement de problème avec valgrind (utilisation de la
lib en condition de debug), et sur une m-l pour les devs de programmes
utilisateurs, son messsage a vraissemblablement été interprété comme
"salut, je n'arrive pas à valgrinder mon appli sur mon poste perso parce
qu'elle utilise openssl, est-ce que ce quick hack peut me tirer d'affaire ?"
3) Ce qu'il a envoyé sur la mailing-list n'est pas un patch, mais une
question (ce qui n'aidait pas à deviner ses réelles intentions).
4) S'il s'était donné la peine de googler "valgrind openssl", ou simplement
de chercher dans le bugtracker d'openssl, il aurait vu, des tonnes de fois,
la réponse des devs à ce problème[3].
* Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal compris
pourquoi cette fonction peut utiliser de la mémoire non initialisée. Si
openssl fait brailler valgrind, ce n'est pas que leur code est sale. Et non,
openssl ne compte pas sur cette zone de mémoire pour vraiment contenir un
aléas solide et suffisant. La fonction :
"static void ssleay_rand_add(const void *buf, int num, double add)" ,
celle dont les appels à "MD_Update(&m,buf,j);" ont été commentés par Debian,
est une fonction interne d'openssl appellée par la fonction "publique"
(documentée et exposée aux utilisateurs de la lib) :
"int RAND_bytes(unsigned char *buf, int num);".
La page de man de RAND_bytes(3ssl) explique clairement :
"The contents of buf is mixed into the entropy pool before retrieving the
new pseudo-random bytes unless disabled at compile time (see FAQ)."
Bref, c'est un comportement parfaitement documenté, le buffer "buf" (transmis
depuis l'application utilisatrice jusqu'à MD_Update()) sera accédé en
lecture, et pas seulement en écriture.
Si l'utilisateur le souhaite, il peut "pré-remplir" le buffer "buf" avec des
données venant de /dev/random, ou autre, avant d'appeler RAND_bytes(), et ainsi
augmenter à souhait l'entropie du système tout en faisant taire valgrind. Le cas
échéant, openssl lit quand même la zone mémoire "buf" (parce que MD_Update()
ne sait pas si elle a été initialisée de la sorte, et parce que même si elle
ne l'a pas été, elle peut contenir n'importe quoi, ce qui est toujours un
petit poil d'aléas bon à prendre même si non vital). Ensuite, le MD_Update()
mixe le contenu de "buf" avec du vrai aléas obtenu de façon dépendante de la
plateforme (/dev/urandom /dev/arc4random, etc.) : on ne dépend pas du fait
que le contenu, initialisé ou pas, dans "buf" soit réellement aléatoire ou pas.
Mais on dépend du fait que l'appel à MD_Update() soit bien éffectué, sinon
ce mélange de buf et de vrai aléas n'a pas lieu. Ceci explique pourquoi une
solution telle que : "memset(buf, 0, sizeof buf); MD_Update(&m,buf,j);",
qui aurait fait taire valgrind, aurait plutôt diminué la qualité du code
et de l'entropie. Le probleme ici est que le développeur Debian a purement
et simplement enlevé l'appel à MD_Update().
* Debian et Ubuntu distribuent désormais une versions d'openssh patchée pour
rejeter les clefs fragiles, et contenant un nouvel outil (ssh-vulnkeys)
censé aider à trouver les clefs fragiles sur le système. Il sera
malheureusement nécéssaire que les autres distribs (et les *BSD, et Solaris,
etc.) fassent de même *très rapidement*. Et il serait de bon ton de la part de
ces deux distributions responsables d'y aider, et aussi de distribuer l'openssh
patché pour Sarge et Ubuntu 6.06 LTS (arrétons l'hypocrisie et les résolutions
psychorigides : même si ces deux distribs ne sont plus officiellement supportées
depuis peu (un ou deux mois), elles sont encore utilisées).
* Complètement ahurissant et irresponsable : le correctif sécurité Debian a été
commité, publiquement 5 jours avant la publication de l'advisory ![4]
Pourtant, même la doc officielle pour les développeurs Debian rappelle
l'évidence, qu'il ne faut pas faire ça.[5]
### Aussi, pour éviter que ça se reproduise, on peux facilement en déduire que :
* Les mainteneurs de paquets dans les distributions devraient toujours
soumettre leurs patchs à l'upstream, *en n'omettant pas d'indiquer qu'ils
sont maiteneurs du paquet et ce qu'ils comptent faire du patch* (qu'ils
comptent l'intégrer dans le paquet, qu'il ne s'agit pas d'un simple
quick hack sur leur poste perso pour pouvoir mieux débugguer une appli
en cours de développment avec valgrind).
* Comme le rappelle Ben Laurie[6] (dev openssl), un mainteneur de paquet ne
devrait jamais distribuer sa correction d'un problème qu'il ne comprends pas
(une résolution "à tatons") ou dans un segment de code qu'il ne comprends
pas. Surtout si ce patch touche une composant central d'une bibliothèque
vitale pour la sécurité de l'OS et très utilisée.
* Les outils automatiques de fiabilisation (de valgrind à SELinux en passant
par snort ou gcc -fstack-protector) ne peuvent rien pour prévenir ce type de
bourdes ou leurs conséquences. Autrement dit, retenons qu'ils ne remplaceront
jamais la nécessité d'une relecture et validation humaine systématique du code
par un pair "expert". Le bon vieux modèle "audit et relecture systématique par
un ancien" à la façon OpenBSD a du bon (ce qui ne signifie pas que le modèle
"prévention automatisée à la SELinux/Red Hat est moins bon, mais le premier
reste nécessaire). Debian devrait imposer la validation des patchs, au moins
sur les composants critiques.
* Le problème aurait aussi été évité si le développeur Debian avait regardé le
bugtracker d'openssl (où il a déjà été question de son problème) - et je
considère que regarder ce bugtracker est son boulot ; il aurait aussi été
évité si les développeurs openssl suivaient les "vendor patchs" dans les
distros, ou simplement les bugtrackrs des distros. Il y a de grosses marges
de progrès là (et des "meta" bugtrackers pourraient aider).
* Documenter les pièges de ce genre dans la code (un simple commentaire...) ne
mange pas de pain. Même si c'est documenté dans la page de man, le
bugtracker et sur la mailing-list (via goole).
Non en fait l'association, c'est Wikimedia ( http://www.wikimedia.org/ ).
Pour récapituler, car les ressemblances de ces noms portent à équivoque :
- La Fondation Wikimedia est, au regard de la loi française, un hébergeur. Elle s'occupe des serveurs, mais pas du contenu. Accessoirement, elle a d'autres activités (emploi des devs, fundraising, etc). L'association Wikimedia France est légalement indépendante de la Fondation.
- Les projets Wikimedia sont l'ensemble des projets en interconnexion, gérés par la fondation : Wikibooks, Wikisources, Wiktionary, Wikipédia, Wikiversity ... (mais attention, pas Wikitravel ni Vikidia, qui sont des projets totalement indépendants);
- Le logiciel libre Mediawiki, qui est utilisé par les projets.
- L'encyclopédie Wikipédia, le plus célèbre des projets Wikimedia.
En réponse à quelques remarques lues plus haut :
- Non, la NPOV etc. ne sont pas des lignes éditoriales dont la fondation serait responsable : ce sont des lignes éditoriales décidées par les utilisateurs de Wikipédia.
- Les contenus de l'encyclopédie Larrousse sont propriétaires, et propriété de Larrousse. Oui, les rédacteurs sont exploités sans retour. En conférence de presse, Larousse disait ne pas exclure d'y adjoindre de la pub.
- En l'état, leur argument de « non anonymat » et « articles signés » est totalement pipeau. On doit se présenter sous un nom, qui n'est pas vérifié. C'est la porte ouverte aux usurpations (ce que Wikipédia cherche justement à éviter, en autorisant les pseudos et pas les noms de célébrités).
- L'association Wikimedia France a rédigé un communiqué de presse. Comme d'hab, la presse s'en fout et préfère le FUD et les communiqués des éditeurs, qui payent la pub... ; dommage, parce que ce communiqué est l'occasion de signaler au grand public, par l'exemple pratique, la notion de libre :
« Enfin, Wikimédia France déplore la mise en place de barrières à la circulation du contenu. Le contenu d'une encyclopédie doit être librement réutilisable. C'est pour cette raison que l'encyclopédie Wikipedia est placée sous licence libre, ce qui permet par exemple à des ONGs de la distribuer sans contrainte dans des pays en développement. »
Exact, le xorg d'OpenBSD est patché pour révoquer ses privilèges très tôt, et depuis longtemps (mais le - petit - processus root restant continue à accéder à l'espace mémoire global, d'où le machdep.allowaperture sur x86).
Ce que viens de faire David Airlie, si j'ai bien compris, est nouveau : il s'agit d'un X11 avec le DRI etc, qui n'a pas besoin de deviser directement d'un accès direct au périphérique PCI / à l'espace dma, ce travail naturellement noyau étant délégué au TTM. C'est un superbe progrès.
Pour le "Ça concerne le long terme" du journal : peut-être, mais surement pas à cause du modsetting : ce dernier est vraiment en voie d'intégration imminente parrait-il.
On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.
Sauf que c'est exactement l'inverse.
Les développeurs OpenBSD (en particulier Reyk Floeter) ont développé le driver (basé sur un travail initial de Sam Leffler pour FreeBSD), et surtout ce HAL libre par rétro-engenérie.
Certains développeurs linux ont assez longuement fudé sur la légalité de ce HAL libre (arguant qu'il n'aurait pas été rétro-engéniré dans les règles de l'art), jusqu'à ce que le Freedom Law Center se penche sur le cas et publie un communiqué lavant le code de tout soupçon.
Peut de temps après, un développeur du projet ath5k (vaguement soutenu par quelques camarades) a décidé de récupérer tout ce bon code d'OpenBSD, sous licence ISC, de trasher la licence et de coller une GPL à la place. Sûrement histoire de favoriser les échanges cordiales entre projets.
> Ça fait 3 ans au moins que il dit que tant que launchpad est pas
> indispensable il peut pas ouvrir le code sinon ca fragmenterait.
>
> Le but c'est d'être la plate-forme incontournable et de ne liberer
> que si aucun concurrent ne peut se mettre à l'égal.
Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.
Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.
En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.
Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.
Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.
Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).
Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
> J’ai l'impression que certains dirigeants de cette organisation n'ont rien compris du libre.
> Pour eux ce n'est qu'un composant à bas coût.
Bah, j'ai l'impression qu'ils ont au contraire très bien compris.
Très bien compris que le libre, c'est aussi une large communauté d'ingénieurs hyper qualifiés qu'on peut faire travailler gratos, pendant longtemps, sur un projet contraire à leur convictions. Pour peu qu'on pipote un brin sur les objectifs (ou qu'on reste « discret » suffisamment longtemps concernant les « changements d'objectifs »).
La comparaison est amusante, surtout mise en perspective par ce judicieux commentaire sur slashdot. Bah, et bien Wozniac, comme tant d'autres, s'est fait arnaquer sur la marchandise :
Among the same lines:
According to a report in the Wall Street Journal, Apple boss Steve Jobs offered to equip each of the machines with a gratis copy of Mac OS X.
Seymour Papert, a professor emeritus at MIT and one of the project's founders, said the scheme had refused Jobs' offer on the grounds that Mac OS X is a proprietary system.
Papert told the WSJ: "We declined because it's not open source," adding the $100 laptop creators will only choose an operating system where the source code is open and can be altered.
This is what Steve Wozniac had to say a while ago:
I was on a panel with Nicholas in Seoul this year and admired the fact that he'd turned down an offer from Jobs for the Macintosh OS on the OLPC because it wasn't open sourced. I both donated to the program and also bought the give-one get-one and I do have it.
I wonder how he feels about the project now that they are going to use XP...
Comme si le « portable qui sera 100% libre, du firmware à l'OS » (et la ré-écriture systématique des logiciels python sur le framework Sugar) était surtout une belle stratégie pour raccoller des centaines de développeurs bénévoles pendant des années, attendre qu'ils aient fait un truc livrable, et annoncer, comme par hasard à la dernière minute, que finalement ce sera du Windows XP.
Combien de développeurs talentueux se seraient donné tant de peine pour contribuer à l'OLPC si on leur avait dit, dès le départ, qu'il s'agissait d'un portable sous WinXP ?
Combien de wikipédiens auraient participé à la selection et au nettoyage d'articles pour les enfants ? Aurions nous fait autant de publicité au projet ?
Negroponte est un fin stratège...
Allons, il faut réveler le projet sous son vrai nom :
- One Licence Per Children
- HOWTO get a thousand ultra qualified IT workers build your Windows commercial project for free
- Comment créer une dépendance technologique chez les moins de 10 ans pauvres
- ...
Je saisis l'occasion pour signaler ce joli petit texte de Cory Doctorow, traduit en français par Libé au début du mois, et qui explique aussi pourquoi le terme « propriété intellectuelle » est un abus de langage.
Moins formel que le texte de Stallman, mais plus vivant et plus léger, avec des exemples très parlants (par ex. : ma fille, elle est mienne, mais n'est pas ma propriété), bref, un texte plus adapté pour faire sentir le problème au grand public :
Bon, ça n'a pas grand chose à voir avec le contenu de la dépêche, mais puis qu'on parle d'astuces OpenSSH...
Depuis la version 4.2, OpenSSH est capable de réduire fortement le temps d'initialisation de la connexion (en éliminant le besoin de re-négociation des algos, ré-authentification, ...), car il permet de multiplexer les connexions vers un même hôte.
Les cas d'utilisations qui bénéficient typiquement de cette fonctionnalité sont ceux qui requiert des re-connexions régulières à une même machine, par exemple pour accéder à un serveur Subersion, ou CVS, ou un distcc, ou ceux qui ont l'habitude de se connecter pour lancer une seule commande à la fois (« ssh user@serveur commande »)...
Le principe est simple : on crée une connexion « maitre » initiale, celle-ci est maintenue en fond et sera réutilisée pour toutes les connexions suivantes vers le même hôte.
En pratique :
1) Placer ceci dans son ~/.ssh/config (ce fichier doit être en mode 0600) :
Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p
2) Ensuite, on crée une socket « maître » utilisée pour le multiplexage (cela crée aussi un processus ssh qui maintient cette socket, en arrière plan) vers monhotedistant:
ssh -fMN monhotedistant
Et voila ! On peut maintenant profiter de nouvelles connexions très rapides. Exemple chez moi :
# Avant la mise en place du multiplexage :
$ time ssh monserveur exit
real 0m0.530s
# Avec le multiplexage :
$ time ssh monserveur exit
real 0m0.018s
Autant dire que les opérations courantes (svn diff, log, up, ...) sur mon dépôt subversion sont beaucoup plus confortables.
Une autre astuce dont il faudrait parler : les dernières versions d'OpenSSH permettent de créer des VPN (utilisant des tunnels sur des interfaces virtuelles tun(4), à la façon d'OpenVPN) de façon très simple et ne nécessitant que OpenSSH. Je suis sûr que ça aurait pu être utilisé pour arriver à des résultats similaires à ce qui est présenté dans la dépêche, mais en n'utilisant qu'OpenSSH.
[^] # Re: Hourra !
Posté par herodiade . En réponse à la dépêche Bilan positif pour Linux à l'Assemblée nationale. Évalué à 10.
En français, on dit tout simplement : « ergonomie ».
[^] # Re: Paquet d'aspirines...
Posté par herodiade . En réponse à la dépêche Sortie de Eclipse 3.4 - Ganymede. Évalué à 4.
Ça se comprends ; ed(1) et eclipse, c'est bonnet blanc et blanc bonnet.
[^] # Re: Quel intérêt d'un OS libre si on ne peut pas l'utiliser sur le har
Posté par herodiade . En réponse à la dépêche Nokia s'offre Symbian pour le rendre libre. Évalué à 1.
> flashage de leurs téléphones (sauf éventuelles bidouilles, je ne sais pas
> trop), alors on aura beau avoir n'importe quel soft, on ne pourra rien
> en faire. Quel intérêt pour le "libre" et la liberté des utilisateurs ?
Et bien, on peut porter le logiciel sur une autre plateforme, et l'utiliser ainsi. Et réutiliser des composants du logiciel dans d'autres logiciels (tient, par exemple, dans une bibliothèque pour linux permettant d'interagir/échanger avec des téléphones Symbian...).
Qui n'a pas révé de faire tourner Symbian OS (ahh, ses C:\programs, ses .exe ... ;) sur son desktop, hein, je vous le demande ?
Plus sérieusement, on devrait pouvoir porter l'OS sur des téléphones peu vérouillées (le FreeRunner ? des émulateurs basés sur Qemu ? sur un Zaurus ? ...).
Considérer le logiciel comme « fermé » parce que le matériel (ou une partie du matériel supporté) est vérouillé, c'est se tromper de cible. Linux est libre, même s'il tourne sur Tivo (la preuve : on peut aussi le porter sur autre chose que Tivo).
[^] # Re: Bonne nouvelle.
Posté par herodiade . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 3.
Tu semble dubitatif.
Lorsqu'un matériel courant ne dispose pas de driver et que le constructeur fournis les specs, le driver pour linux ne tarde jamais.
Si tu as un doute, jette un oeil sur les Linux Driver Project Status Reports :
- [http://www.kroah.com/log/linux/linux_driver_project_status-2(...)].
- [http://www.kroah.com/log/linux/devices_lacking_linux_support(...)]
à pasBill pasGates : je ne comprends pas ta réponse. Note que
1) je suis relativement d'accord avec ce que tu dis au sujet des applicatifs (mais pas des drivers)
2) la méthode que j'évoque est certainement la moins couteuse, puisque le constructeur n'a, basiquement, rien à faire
3) enfin, cette méthode marche généralement fort bien : il n'y a presque plus de constructeur notable non coopératif (nvidia, atheros et broadcom sont les grandes exceptions).
[^] # Re: Bonne nouvelle.
Posté par herodiade . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 2.
En ce qui concerne les drivers, je ne crois pas qu'il s'agisse fondamentalement d'un problème technique (dans la mesure où ce qui est demandé aux éditeurs est de simplement fournir les specs, et le driver libre est écrit rapidement ensuite).
[^] # Re: Bonne nouvelle.
Posté par herodiade . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 4.
En fait il en existe au moins un à ma connaissance, c'est l'excellent Antidote, de Druide Informatique. Mais il est propriétaire et payant.
Cette indication simplement pour corriger ton exemple, mais je suis d'accord en ce qui concerne l'idée : un utilisateur lambda migrant de Windows à Linux doit souvent accepter de se passer de certaines fonctionnalités ou cas d'utilisations auxquels il était habitué. La situation s'améliore progressivement, mais tout n'est pas résolu. Certains jeux ne marchent pas sous wine (pour les gamers), par exemple. Les logiciel de montage audio et vidéo (ou de conception d'animation flash) ne sont pas forcément très nombreux ni fonctionnels, et là encore, wine n'est pas toujours au rendez-vous.
Je crains que la situation n'empire lorsque le Blu-Ray (ou HD-DVD), qui sont et resteront généralement inutilisable sous Linux (du fait des DRM...), auront totalement remplacé le DVD. Imaginez que vous n'êtes pas très intéressés par l'informatique et le libre, et qu'aujourd'hui, on vous dise : « voila un super OS pour remplacer ton OS actuel ; il marche très bien, mais tu ne peux pas lire les DVD (ou les mp3) ». C'est l'anti killer-feature par excellence. Et c'est pourtant la situation qui nous attends, dans un avenir proche.
[^] # Re: udev sux
Posté par herodiade . En réponse au journal Gestion du matériel gourmande en resources (udev, hal) ?. Évalué à 6.
udev & hal sont donc la partie « visible » (ou userspace) de ce temps d'initialisation des périphériques, mais n'en sont pas responsable pour autant. Le symptôme, pas la maladie, etc.
[^] # Re: et les autres OS ?
Posté par herodiade . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 3.
Ils auraient donc d'autres chantiers à abattre avant que l'élimination du BKL ait un réel intérêt.
Cela dit, étant donné que NetBSD bosse activement sur le sujet, ce sera beaucoup moins difficile pour OpenBSD de s'y mettre, le jour où ça leur chantera (plus facile que ça ne l'a été pour Linux ou FreeBSD, par exemple).
[^] # Re: Discussion avec upstream sur la suppression des lignes incriminées
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
Oui, je l'avais indiqué dans un post précédent mais j'aurais du le rappeller dans celui-ci aussi. Cest aussi ce qui est écrit dans le README des sources de la lib :
« If you would like to submit a patch, send it to openssl-dev@openssl.org with the string "[PATCH]" in the subject. Please be sure to include a textual explanation of what your patch does. »
La remarque de Damien Miller semble la plus pertinente : selon lui, la meilleur façon de s'adresse à upstream en étant lu (et qu'upstream sache qu'on s'adresse à lui, pas qu'on cherche du support end-user), ça reste le patch (diff -u) dans le bugtracker. Ce qui, dans le cas présent, aurait peut-être même permis au développeur Debian d'y trouver la précédente discussion sur le sujet.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
« Les dev d'openssl ont un poil la responsabilité vu la superbe documentation
du code incriminé, et le fait que valgrind gueule bien. »
Toutes mes exkiouzes.
[^] # Re: Mesures qui seront prises ?
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 5.
Les ressources techniques et humaines motivées ne manquent que rarement chez Debian. Le support des archis exotiques ne devrait plus être un frein non plus (celle qui ne suivent pas sont déclassées). Le plus clair de l'efficacité et de la belle énergie de Debian est absorbé par la lourdeur bureaucratique et l'effet de groupe (inertie "conservatrice", résistance au changement).
Il est juste impossible de prendre une grande décision qui implique de vastes changements « parce que c'est toujours mieux à vent » , et qu'après avoir proposé un tel changement sur une mailing-list, avoir débatus des mois sur des mailing-lists, retoqué son projet parce qu'il impliquerai un changement de la constitution debian ou autre formalité administrative, on déclencherai une grande bataille généralisée par mailing-list interposée, jusqu'à ce qu'épuisement s'ensuive. L'aspect administratif et bureaucratique a aussi préséance sur l'aspect méritocratie (quelqu'un d'hyper compétent ne peut pas prendre une décision importante dans son domaine, ou presque). Exemple facile : décider de compiler toute (ou presque) l'archive avec "-fstack-protector" demanderait qu'une personne puisse prendre la décision, et on s'y tient ; mais chez Debian la seule option pour arriver à ça serait d'engager un très long débat sur m-l, essayer de convaincre tout le monde, s'engueuler, peut-être lancer un vote, ...
Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel (et surtout pas une décision du type : tout commit sur les logiciels a, b et c doivent être audités, revues et approuvés par un groupe de relecteurs qualifiés). Ca continuera comme avant.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
Au temps pour moi. Cela dit, aux vues du changelog que tu présente :
> Quels paquets devraient être patchés et pourquoi ?
Le paquet openssh-server (et l'ajout d'une dépendance sur le nouveau paquet openssh-blacklist). Pour que ce serveur refuse l'authentification avec une clef connue comme compromise, comme le font désormais les OpenSSH de Etch et celui de Hardy. Et accessoirement, pour disposer de l'outil ssh-vulnkeys (mais c'est moins urgent).
Encore une fois : ce n'est pas parce qu'une machine utilise une distribution qui n'est pas une dérivée Debian, ou n'a pas inclus la version saccagée d'openssl, que cette machine est à l'abri. Il suffit qu'un utilisateur de la machine y ai placé une clef ssh vérolée (générée sur une Gutsy, par exemple) pour que la machine soit compromise.
[^] # Re: Mesures qui seront prises ?
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 10.
Clairement. Je suis aussi un amateur de Debian, adminsys (avec environ 100 serveurs sous Debian a auditer dans l'urgence, youpi ...), et je vais aussi passer à RHEL/Centos/Fedora. La coupe est pleine :
* En novembre 2003, la clef d'un développeur Debian a été compromise, des serveurs Debian ont été piratés. Gros problème. Mais rien n'a changé.
* En juin 2005, plus de mises à jour de sécurité pendant plusieurs semaines (alors que des failles dans spamassassin et sudo couraient), tout ça parceque la security "team" (Martin Schulze) était occupé au LinuxTag et que la nomenclatura Debian (ftp-masters, security team) n'aime pas déléguer ou partager leur pouvoir. Outre les mises à jour, même les annonces de problèmes n'étaient plus faites. Gros problème. Mais rien n'a changé.
* En mai 2008, on apprend cette nouvelle affaire.
* Une intégration très à la traine (parfois inexistante) des technologies de fiabilisation modernes, au moins dans la dernière version dite stable : support SELinux moins que sommaire, pas d'Exec-Shield, pas encore de version intégralement recompilée avec -fstack-protector, pas de FORTIFY_SOURCE, pas de compilation intégrale de l'archive avec -fPIE -pie (Position Independant Executables), pas de restrictions de l'accès à /dev/mem, pas de ELF Data Hardening systématique (ld -z relro), pas de support de la glibc pour les mots de passes chiffré plus sérieusement que DES/MD5, bref, toutes ces bonnes choses dont Red Hat, SuSE et Gentoo disposent depuis un bon moment déjà... chez Debian, la sécurité est la 4em roue de la charrette. Si seulement le suivi des problèmes de sécurité chez Debian était si bon qu'il permetait de se passer de tout ça...
L'erreur est humaine, et ce sont des bénévoles, mais cette liste se concentre uniquement sur les problèmes d'organisation et leurs conséquences, pas le manque de travail : incapacité à décider (ie. forcer l'augmentation da secu team, forcer la compilation avec -fstack-protector, ne pas accépter de packager des progs trop mal codés, ne pas avoir pris de résolution drastique après les deux précédents énormes fiascos, etc) et de laxisme à l'égard de la sécurité, et on voit qu'ils sont énormes. J'adore la souplesse de Debian, j'adore apt, j'adore le fait qu'elle supporte autant de paquets et d'architectures, mais au bout du compte cette distro n'est pas faite pour moi : pour mes besoins, la sécurité compte plus que le reste, et ce n'est donc pas un bon choix de distro.
[^] # Re: Discussion avec upstream sur la suppression des lignes incriminées
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 6.
1- Comme l'indique Ben Laurie, cette liste est de fait surtout utilisée par les développeurs d'applications basées sur openssl, et pas vraiment par les gens qui développent openssl. Ce qui change la façon d'interpréter les mails qui y sont soumis (cf. ci-dessous).
2- Kurt commence son email par "When debbuging applications that make use of openssl using valgrind [...]", et les devs ont clairement pensé qu'il voulait simplement une astuce / un hack lui permettant débugguer/valgrind localement une application utilisant openssl (cf. la réponse du dev openssl : "If it helps with debugging, I'm in favor of removing them."). L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
3- Son email à la forme d'une simple question, et n'envoie pas son code sous forme de patch proposé pour intégration dans openssl. S'il avait envoyé un patch pour intégration upstream, les développeurs l'aurait lu attentivement et refusé (comme ils l'ont fait à chaque fois qu'un patch pour "corriger MD_Update pour valgrind" leur est présenté, ce qui était déjà arrivé avant le mail de Kurt, y compris dans le bugtracker d'openssl, et ce dernier aurait du googler), ce qui lui aurait permis de comprendre que c'est une mauvaise idée.
4- Il ne s'est pas présenté comme "mainteneur du paquet Debian", et il a encore moins annoncé son intention de balancer cette modif pour tout les utilisateurs d'openssl chez Debian et Ubuntu (on en revient au point 2).
Bref, "remonter ses modifications upstream", c'est ouvrir une entrée dans le bugtracker et y attacher sa modification sous forme de patch, et annoncer son statut et son intention de distribuer le patch.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
Mais effectivement, ce n'est qu'un car particulier et non nécessaire : même si le buffer passé à openssl est non initialisé et remplis de 0 par l'OS, l'aléas retourné par openssl est suffisamment bon. Les devs d'openssl auraient pu décider de se passer de ce petit plus d'aléas potentiel sans grande perte.
ps: et, encore une fois, ce n'est pas le fait de virer l'utilisation de mémoire non initialisée qui pause problème, en soi, c'est le fait d'enlever au passage l'appel à la fonction qui mixe cette zone de mémoire avec du vrais aléas.
# Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'est
Posté par herodiade . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 10.
un '#ifdef PURIFY' est totalement facultatif. Donc :
1) contrairement à ce qui a été écrit plus haut par iZnogood, un openssl
standard compilé avec -DPURIFY ne pause aucun problème . Et
2) on peut aisément comprendre qu'une lecture rapide/superficielle du code
ou du patch conduise à croire que le premier appel à MD_Update(), dans le
même fichier, puisse être traité de la même manière (ce qui n'est en fait pas le cas).
* 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], ce qui n'a pas
suscité de mise en gardes (mais l'upstream n'a pas choisi d'intégrer ce
patch, et pour cause). Cette façon d'échanger avec l'upstream présentait
cependant plusieurs graves défauts, comme le signale d'ailleurs Damien Miller
(le développeur principal d'OpenSSH)[1] :
1) openssl-dev est en pratique une liste d'utilisateur d'openssl (ou de
développeurs d'applications utilisant openssl), et pas la liste des
développeurs de la lib openssl (openssl-team), et encore moins le bugtracker.
Seulement la description de la liste sur le site d'openssl ne reflète pas ce
fait.
2) Il n'a pas du tout précisé qu'il était mainteneur du paquet debian et
qu'il comptait y intégrer ce patch et le distribuer à tout les utilisateurs.
Vu que son mail parle seulement de problème avec valgrind (utilisation de la
lib en condition de debug), et sur une m-l pour les devs de programmes
utilisateurs, son messsage a vraissemblablement été interprété comme
"salut, je n'arrive pas à valgrinder mon appli sur mon poste perso parce
qu'elle utilise openssl, est-ce que ce quick hack peut me tirer d'affaire ?"
3) Ce qu'il a envoyé sur la mailing-list n'est pas un patch, mais une
question (ce qui n'aidait pas à deviner ses réelles intentions).
4) S'il s'était donné la peine de googler "valgrind openssl", ou simplement
de chercher dans le bugtracker d'openssl, il aurait vu, des tonnes de fois,
la réponse des devs à ce problème[3].
* Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal compris
pourquoi cette fonction peut utiliser de la mémoire non initialisée. Si
openssl fait brailler valgrind, ce n'est pas que leur code est sale. Et non,
openssl ne compte pas sur cette zone de mémoire pour vraiment contenir un
aléas solide et suffisant. La fonction :
"static void ssleay_rand_add(const void *buf, int num, double add)" ,
celle dont les appels à "MD_Update(&m,buf,j);" ont été commentés par Debian,
est une fonction interne d'openssl appellée par la fonction "publique"
(documentée et exposée aux utilisateurs de la lib) :
"int RAND_bytes(unsigned char *buf, int num);".
La page de man de RAND_bytes(3ssl) explique clairement :
"The contents of buf is mixed into the entropy pool before retrieving the
new pseudo-random bytes unless disabled at compile time (see FAQ)."
Bref, c'est un comportement parfaitement documenté, le buffer "buf" (transmis
depuis l'application utilisatrice jusqu'à MD_Update()) sera accédé en
lecture, et pas seulement en écriture.
Si l'utilisateur le souhaite, il peut "pré-remplir" le buffer "buf" avec des
données venant de /dev/random, ou autre, avant d'appeler RAND_bytes(), et ainsi
augmenter à souhait l'entropie du système tout en faisant taire valgrind. Le cas
échéant, openssl lit quand même la zone mémoire "buf" (parce que MD_Update()
ne sait pas si elle a été initialisée de la sorte, et parce que même si elle
ne l'a pas été, elle peut contenir n'importe quoi, ce qui est toujours un
petit poil d'aléas bon à prendre même si non vital). Ensuite, le MD_Update()
mixe le contenu de "buf" avec du vrai aléas obtenu de façon dépendante de la
plateforme (/dev/urandom /dev/arc4random, etc.) : on ne dépend pas du fait
que le contenu, initialisé ou pas, dans "buf" soit réellement aléatoire ou pas.
Mais on dépend du fait que l'appel à MD_Update() soit bien éffectué, sinon
ce mélange de buf et de vrai aléas n'a pas lieu. Ceci explique pourquoi une
solution telle que : "memset(buf, 0, sizeof buf); MD_Update(&m,buf,j);",
qui aurait fait taire valgrind, aurait plutôt diminué la qualité du code
et de l'entropie. Le probleme ici est que le développeur Debian a purement
et simplement enlevé l'appel à MD_Update().
* Debian et Ubuntu distribuent désormais une versions d'openssh patchée pour
rejeter les clefs fragiles, et contenant un nouvel outil (ssh-vulnkeys)
censé aider à trouver les clefs fragiles sur le système. Il sera
malheureusement nécéssaire que les autres distribs (et les *BSD, et Solaris,
etc.) fassent de même *très rapidement*. Et il serait de bon ton de la part de
ces deux distributions responsables d'y aider, et aussi de distribuer l'openssh
patché pour Sarge et Ubuntu 6.06 LTS (arrétons l'hypocrisie et les résolutions
psychorigides : même si ces deux distribs ne sont plus officiellement supportées
depuis peu (un ou deux mois), elles sont encore utilisées).
* Complètement ahurissant et irresponsable : le correctif sécurité Debian a été
commité, publiquement 5 jours avant la publication de l'advisory ![4]
Pourtant, même la doc officielle pour les développeurs Debian rappelle
l'évidence, qu'il ne faut pas faire ça.[5]
### Aussi, pour éviter que ça se reproduise, on peux facilement en déduire que :
* Les mainteneurs de paquets dans les distributions devraient toujours
soumettre leurs patchs à l'upstream, *en n'omettant pas d'indiquer qu'ils
sont maiteneurs du paquet et ce qu'ils comptent faire du patch* (qu'ils
comptent l'intégrer dans le paquet, qu'il ne s'agit pas d'un simple
quick hack sur leur poste perso pour pouvoir mieux débugguer une appli
en cours de développment avec valgrind).
* Comme le rappelle Ben Laurie[6] (dev openssl), un mainteneur de paquet ne
devrait jamais distribuer sa correction d'un problème qu'il ne comprends pas
(une résolution "à tatons") ou dans un segment de code qu'il ne comprends
pas. Surtout si ce patch touche une composant central d'une bibliothèque
vitale pour la sécurité de l'OS et très utilisée.
* Les outils automatiques de fiabilisation (de valgrind à SELinux en passant
par snort ou gcc -fstack-protector) ne peuvent rien pour prévenir ce type de
bourdes ou leurs conséquences. Autrement dit, retenons qu'ils ne remplaceront
jamais la nécessité d'une relecture et validation humaine systématique du code
par un pair "expert". Le bon vieux modèle "audit et relecture systématique par
un ancien" à la façon OpenBSD a du bon (ce qui ne signifie pas que le modèle
"prévention automatisée à la SELinux/Red Hat est moins bon, mais le premier
reste nécessaire). Debian devrait imposer la validation des patchs, au moins
sur les composants critiques.
* Le problème aurait aussi été évité si le développeur Debian avait regardé le
bugtracker d'openssl (où il a déjà été question de son problème) - et je
considère que regarder ce bugtracker est son boulot ; il aurait aussi été
évité si les développeurs openssl suivaient les "vendor patchs" dans les
distros, ou simplement les bugtrackrs des distros. Il y a de grosses marges
de progrès là (et des "meta" bugtrackers pourraient aider).
* Documenter les pièges de ce genre dans la code (un simple commentaire...) ne
mange pas de pain. Même si c'est documenté dans la page de man, le
bugtracker et sur la mailing-list (via goole).
[1] Post de Kurt sur openssl-dev : http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
[2] Remarque de Damien Miller : http://marc.info/?l=openbsd-misc&m=121088162320794&w(...)
[3] Par exemple ici, en 2003 http://rt.openssl.org/Ticket/Display.html?id=521&user=gu(...)
[4] http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/cryp(...)
[5] http://www.debian.org/doc/developers-reference/ch-pkgs.en.ht(...)
[6] Ben Laurie : http://www.links.org/?p=327
[^] # Re: Interview de Line Karoubi, responcable du projet chez Larousse
Posté par herodiade . En réponse au journal Larousse.fr, se met au collaboratif et pourquoi Wikipedia vaincra. Évalué à 3.
Pour récapituler, car les ressemblances de ces noms portent à équivoque :
- La Fondation Wikimedia est, au regard de la loi française, un hébergeur. Elle s'occupe des serveurs, mais pas du contenu. Accessoirement, elle a d'autres activités (emploi des devs, fundraising, etc). L'association Wikimedia France est légalement indépendante de la Fondation.
- Les projets Wikimedia sont l'ensemble des projets en interconnexion, gérés par la fondation : Wikibooks, Wikisources, Wiktionary, Wikipédia, Wikiversity ... (mais attention, pas Wikitravel ni Vikidia, qui sont des projets totalement indépendants);
- Le logiciel libre Mediawiki, qui est utilisé par les projets.
- L'encyclopédie Wikipédia, le plus célèbre des projets Wikimedia.
En réponse à quelques remarques lues plus haut :
- Non, la NPOV etc. ne sont pas des lignes éditoriales dont la fondation serait responsable : ce sont des lignes éditoriales décidées par les utilisateurs de Wikipédia.
- Les contenus de l'encyclopédie Larrousse sont propriétaires, et propriété de Larrousse. Oui, les rédacteurs sont exploités sans retour. En conférence de presse, Larousse disait ne pas exclure d'y adjoindre de la pub.
- En l'état, leur argument de « non anonymat » et « articles signés » est totalement pipeau. On doit se présenter sous un nom, qui n'est pas vérifié. C'est la porte ouverte aux usurpations (ce que Wikipédia cherche justement à éviter, en autorisant les pseudos et pas les noms de célébrités).
- L'association Wikimedia France a rédigé un communiqué de presse. Comme d'hab, la presse s'en fout et préfère le FUD et les communiqués des éditeurs, qui payent la pub... ; dommage, parce que ce communiqué est l'occasion de signaler au grand public, par l'exemple pratique, la notion de libre :
« Enfin, Wikimédia France déplore la mise en place de barrières à la circulation du contenu. Le contenu d'une encyclopédie doit être librement réutilisable. C'est pour cette raison que l'encyclopédie Wikipedia est placée sous licence libre, ce qui permet par exemple à des ONGs de la distribuer sans contrainte dans des pays en développement. »
http://membres.wikimedia.fr/index.php/Presse/CP-Larousse
[^] # Re: Le futur ?
Posté par herodiade . En réponse au journal X11 sans droit root. Évalué à 10.
Ce que viens de faire David Airlie, si j'ai bien compris, est nouveau : il s'agit d'un X11 avec le DRI etc, qui n'a pas besoin de deviser directement d'un accès direct au périphérique PCI / à l'espace dma, ce travail naturellement noyau étant délégué au TTM. C'est un superbe progrès.
Pour le "Ça concerne le long terme" du journal : peut-être, mais surement pas à cause du modsetting : ce dernier est vraiment en voie d'intégration imminente parrait-il.
# Non, ce sont des devs. Linux qui ont tenté de changer la licence
Posté par herodiade . En réponse au journal Atheros veut être compatible avec Linux. Évalué à 10.
Sauf que c'est exactement l'inverse.
Les développeurs OpenBSD (en particulier Reyk Floeter) ont développé le driver (basé sur un travail initial de Sam Leffler pour FreeBSD), et surtout ce HAL libre par rétro-engenérie.
Certains développeurs linux ont assez longuement fudé sur la légalité de ce HAL libre (arguant qu'il n'aurait pas été rétro-engéniré dans les règles de l'art), jusqu'à ce que le Freedom Law Center se penche sur le cas et publie un communiqué lavant le code de tout soupçon.
Peut de temps après, un développeur du projet ath5k (vaguement soutenu par quelques camarades) a décidé de récupérer tout ce bon code d'OpenBSD, sous licence ISC, de trasher la licence et de coller une GPL à la place. Sûrement histoire de favoriser les échanges cordiales entre projets.
[^] # Re: Arg
Posté par herodiade . En réponse au journal Launchpad, enfin Libre ?. Évalué à 4.
> indispensable il peut pas ouvrir le code sinon ca fragmenterait.
>
> Le but c'est d'être la plate-forme incontournable et de ne liberer
> que si aucun concurrent ne peut se mettre à l'égal.
Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.
Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.
En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.
Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.
Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.
Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).
Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
[^] # Re: Une bataille de perdu mais une expérience de gagnée
Posté par herodiade . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 5.
> Pour eux ce n'est qu'un composant à bas coût.
Bah, j'ai l'impression qu'ils ont au contraire très bien compris.
Très bien compris que le libre, c'est aussi une large communauté d'ingénieurs hyper qualifiés qu'on peut faire travailler gratos, pendant longtemps, sur un projet contraire à leur convictions. Pour peu qu'on pipote un brin sur les objectifs (ou qu'on reste « discret » suffisamment longtemps concernant les « changements d'objectifs »).
[^] # Re: Évitons la caricature
Posté par herodiade . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 5.
Among the same lines:
According to a report in the Wall Street Journal, Apple boss Steve Jobs offered to equip each of the machines with a gratis copy of Mac OS X.
Seymour Papert, a professor emeritus at MIT and one of the project's founders, said the scheme had refused Jobs' offer on the grounds that Mac OS X is a proprietary system.
Papert told the WSJ: "We declined because it's not open source," adding the $100 laptop creators will only choose an operating system where the source code is open and can be altered.
This is what Steve Wozniac had to say a while ago:
I was on a panel with Nicholas in Seoul this year and admired the fact that he'd turned down an offer from Jobs for the Macintosh OS on the OLPC because it wasn't open sourced. I both donated to the program and also bought the give-one get-one and I do have it.
I wonder how he feels about the project now that they are going to use XP...
[^] # Ou « comment mobiliser des bénévoles qualifiés pour votre projet »
Posté par herodiade . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 10.
Comme si le « portable qui sera 100% libre, du firmware à l'OS » (et la ré-écriture systématique des logiciels python sur le framework Sugar) était surtout une belle stratégie pour raccoller des centaines de développeurs bénévoles pendant des années, attendre qu'ils aient fait un truc livrable, et annoncer, comme par hasard à la dernière minute, que finalement ce sera du Windows XP.
Combien de développeurs talentueux se seraient donné tant de peine pour contribuer à l'OLPC si on leur avait dit, dès le départ, qu'il s'agissait d'un portable sous WinXP ?
Combien de wikipédiens auraient participé à la selection et au nettoyage d'articles pour les enfants ? Aurions nous fait autant de publicité au projet ?
Negroponte est un fin stratège...
Allons, il faut réveler le projet sous son vrai nom :
- One Licence Per Children
- HOWTO get a thousand ultra qualified IT workers build your Windows commercial project for free
- Comment créer une dépendance technologique chez les moins de 10 ans pauvres
- ...
[^] # Re: hum
Posté par herodiade . En réponse au journal Mini-mémoire sur la propriété intellectuelle. Évalué à 4.
Tout à fait d'accord.
Je saisis l'occasion pour signaler ce joli petit texte de Cory Doctorow, traduit en français par Libé au début du mois, et qui explique aussi pourquoi le terme « propriété intellectuelle » est un abus de langage.
Moins formel que le texte de Stallman, mais plus vivant et plus léger, avec des exemples très parlants (par ex. : ma fille, elle est mienne, mais n'est pas ma propriété), bref, un texte plus adapté pour faire sentir le problème au grand public :
http://www.ecrans.fr/Propriete-intellectuelle-est-un,3502.ht(...)
# Astuces OpenSSH : le multiplexage
Posté par herodiade . En réponse à la dépêche Administration de serveur Unix en DMZ via serveur de rebond. Évalué à 7.
Depuis la version 4.2, OpenSSH est capable de réduire fortement le temps d'initialisation de la connexion (en éliminant le besoin de re-négociation des algos, ré-authentification, ...), car il permet de multiplexer les connexions vers un même hôte.
Les cas d'utilisations qui bénéficient typiquement de cette fonctionnalité sont ceux qui requiert des re-connexions régulières à une même machine, par exemple pour accéder à un serveur Subersion, ou CVS, ou un distcc, ou ceux qui ont l'habitude de se connecter pour lancer une seule commande à la fois (« ssh user@serveur commande »)...
Le principe est simple : on crée une connexion « maitre » initiale, celle-ci est maintenue en fond et sera réutilisée pour toutes les connexions suivantes vers le même hôte.
En pratique :
1) Placer ceci dans son ~/.ssh/config (ce fichier doit être en mode 0600) :
Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p
2) Ensuite, on crée une socket « maître » utilisée pour le multiplexage (cela crée aussi un processus ssh qui maintient cette socket, en arrière plan) vers monhotedistant:
ssh -fMN monhotedistant
Et voila ! On peut maintenant profiter de nouvelles connexions très rapides. Exemple chez moi :
# Avant la mise en place du multiplexage :
$ time ssh monserveur exit
real 0m0.530s
# Avec le multiplexage :
$ time ssh monserveur exit
real 0m0.018s
Autant dire que les opérations courantes (svn diff, log, up, ...) sur mon dépôt subversion sont beaucoup plus confortables.
Une autre astuce dont il faudrait parler : les dernières versions d'OpenSSH permettent de créer des VPN (utilisant des tunnels sur des interfaces virtuelles tun(4), à la façon d'OpenVPN) de façon très simple et ne nécessitant que OpenSSH. Je suis sûr que ça aurait pu être utilisé pour arriver à des résultats similaires à ce qui est présenté dans la dépêche, mais en n'utilisant qu'OpenSSH.