Gentoo Weekly Newsletter: 14 février 2005Migration logicielle et matérielle des forums Gentoo Comme annoncé dans la Future zone d'il y a trois semaines, les Forums Gentoo sont maintenant hébergés sur une nouvelle machine et fonctionnent avec une version améliorée de phpBB qui inclue toutes les mises à jour de la version précédente, nettoyant ainsi le code et qui est plus riche en fonctionnalités que la précédente version utilisée. Parmi les embellissements, on trouve une meilleure internationalisation des forums non anglophones, de nouveaux styles URI avec des liens absolus qui permettent aux moteurs de recherche d'indexer l'intégralité du forum, ainsi que quelques fonctionnalités moins visibles comme la possibilité pour les modérateurs de joindre des discussions -- déplacer des posts d'une discussions où ils sont hors sujet vers une autre où ils sont plus appropriés n'était pas possible avant. Quelques petits ennuis mis à part, le basculement fut sans heurt et personne ne s'est rendu compte de rien jusqu'à ce que tout soit terminé. Félicitations à Christian Hartmann et Lance Albertson pour une migration sans faille ! Calendrier des évènements Gentoo pour Février/Mars 2005 Les journées des évangélistes de Gentoo vont être chargées : leurs rendez-vous n'ont jamais été aussi concentrés en manifestations, conférences et présentations qu'ils ne le seront dans les quatres semaines à venir. Voici la liste des évènements à venir, avec un dernier rappel pour une LWE (NdT : Linux World Expo) au sommet à Boston.
Gentoo Linux Security Team -- Interview de Thierry Carrez Si vous avez l'habitude de suivre les questions de sécurité et leurs réponses dans le monde Linux, vous avez probablement remarqué que les alertes Gentoo et les réponses à ces questions tendent à arriver rapidement après la découverte initiale. En fait, les Gentoo Linux Security Announcements (NdT : GLSAs -Annonces de Sécurité Gentoo Linux-) sont des ressources fréquemment citées pour les notifications de sécurité et états de correction, même en dehors de la communauté Gentoo. Cette réputation de responsabilité est un fait remarquable pour une communauté qui n'a pas de branche commerciale pour supporter un centre dédié de recherche en sécurité. Thierry Carrez (koon), un des Operational Managers (NdT : Managers Opérationnels) de l'équipe de sécurité Gentoo, a eu l'amabilité de prendre quelques minutes de son temps pour nous expliquer quelques unes des techniques qui ont permis à l'équipe de devenir aussi efficace dans l'identification et la correction des problèmes de sécurité. Pourriez-vous nous donner une rapide présentation du processus qui permet d'identifier et de corriger les failles de sécurité ? Quelles en sont les étapes ? Qui les réalise ? Quels sont les outils utilisés ? Nous suivons la Politique de traitement des vulnérabilités pour trouver les bugs de sécurité. En bref, les vulnérabilités publiques sont envoyées par les utilisateurs, nos éclaireurs sécurité ou les développeurs sécurité ; tout dépend de qui les trouve en premier. Quelques fois nous sommes avertis par des chaînes confidentielles (la liste sécurité des fabriquants ou par contact direct via les développeurs ou auditeurs). Le bug de sécurité passe alors par les statuts upstream -NdT : amont- (Nous attendons une correction de la part des mainteneurs en amont) ; ebuild (Nous demandons au mainteneur du paquet de fournir un ebuild stable) ; stable, lorsque nous demandons aux équipes de chaque architecture pour lesquelles un support sécurité existe de tester le paquet et de le marquer comme stable ; et finalement glsa, statut dans lequel nous emmetons une GLSA si besoin est. Parfois, nous sommes englués dans l'un de ces statuts intermédiaires et devons fournir un patch nous même. D'autres fois, nous ne trouvons pas de correction et masquons le paquet car c'est un risque de le laisser dans l'arborescence sans correction. La recherche de trous de sécurité consiste essentiellement à contacter les bonnes personnes au bon moment pour maintenir l'activité à tout instant. Cette tâche est accomplie par les coordinateurs GLSA et n'est pas automatisée. Nous comptons énormément sur les autres équipes de développement Gentoo (mainteneurs de paquets et équipes spécifiques aux architectures) pour effectuer les patchages et les tests. Comment trouvez-vous les failles de sécurité ? par mailing-list ? alertes ? Faisons nous des tests nous-même ? Nous comptons sur la communauté d'utilisateurs pour nous envoyer autant de vulnérabilités publiques qu'ils peuvent. L'équipe de sécurité essaye de regrouper toutes celles qui n'ont pas déjà été prises en compte. Les failles de sécurité viennent des mailing-lists publiques telles que BugTraq ou Full-Disclosure mais aussi d'avertissements de sécurité en amont ainsi que des avertissements d'autres distributions. Nous sommes de plus en plus acceptés dans la communauté globale de la sécurité Linux et par conséquent nous sommes avertis de vulnérabilités avant qu'elles ne soient rendues publiques. Pour apporter notre contribution, nous avons récemment démarré un sous-projet d'audit de sécurité pour trouver nous même les vulnérabilités et nos mainteneurs de paquets trouvent aussi beaucoup de vulnérabilités dans leurs tests. Quand une faille est identifiée, comment est-elle documentée ? La plupart du temps nous nous contentons de copier les informations de l'avertissement publique, vérifions qu'il s'applique à Gentoo Linux et notons sa gravité. Cette dernière amène des priorités car nous essayons de respecter les délais imposés par la politique de traitement des vulnérabilités. Y a-t-il une procédure selon laquelle la résolution d'une faille est assignée à quelqu'un ? Comment sont décidées les prioritées ? Comment la correction est-elle documentée et testée ? Chaque coordinateur GLSA peut prendre un bug en charge ou y être assigné pour s'assurer que la correction est en cours sur ce bug. Mais si un bug reste bloqué trop longtemps, n'importe quel développeur de l'équipe peut intervenir pour le débloquer. Les priorités sont décidées selon la gravité, en suivant les règles de la politique de traitement des vulnérabilités. Quand une correction est disponible, comment est-elle documentée ? Qui rédige la GLSA ? Comment sont transmises les GLSA ? Comment sont-elles archivées ? Nous documentons la correction avec un brouillon de GLSA qui doit recevoir au moins deux avis de relecture positifs avant d'être livré. Nous utilisons un outil appelé GLSAMaker pour assurer la cohérence de contenu entre les différentes GLSAs. La GLSA est écrite par le coordinateur GLSA ou parfois par un des apprentis sécurité (coordinateurs GLSA en apprentissage). Les GLSAs sont envoyées par mail à gentoo-announce et à d'autres listes de sécurité et apparaissent automatiquement sur la page RDF feed et sur la Page de sécurité Gentoo. Finalement, elles sont copiées par les modérateurs des forums pour apparaître comme annonce des forums. Les sources XML des GLSAs font partie de l'arborescence Portage (dans metadata/glsa) et sont synchronisées sur toutes les boîtes utilisateurs, pour permettre l'utilisation de l'outil (expérimental pour le moment) glsa-check (qui fait partie du paquet gentoolkit). Qui sont les consommateurs amont des GLSA ? en dehors des utilisateurs de Gentoo, y a-t-il d'autres organisations qui sont affectées ? Nous prévenons linuxsecurity.com pour qu'ils puissent inclure la GLSA sur leur page d'avertissement. Le dictionnaire MITRE CVE inclue aussi des références à la GLSA. Existe-t-il des outils automatiques ou des scripts que l'équipe utilise pour gérer ces tâches ? Nous utilisons GLSAMaker, un outil écrit par Tim Yamin (plasmaroo), pour écrire la source XML du GLSA et le texte correspondanti. Dans quel état est la fonctionnalité "emerge security" qui sert à identifier et corriger les problèmes de sécurité en utilisant portage ? La fonctionnalité "emerge security" est en ce moment en cours de test avec l'outil "glsa-check", qui fait partie du paquet gentoolkit. Cela nous permet d'identifier quelles GLSAs affectent votre système et de réparer automatiquement les paquets vulnérables. Quand ce sera prêt, l'équipe des outils portage l'intègrera avec les autres principaux outils tels qu'emerge. On encourage les utilisateurs à utiliser la dernière version de glsa-check et à rapporter toute anomalie en utilisant bugzilla. Où peut-on trouver des informations à propos de l'équipe de sécurité ? Notre page principale est le portail Gentoo Security security.gentoo.org. Il contient tous les liens vers nos documents de référence, les dernières GLSAs et tout un tas d'informations utiles. Les personnes voulant rejoindre le projet Gentoo Security devraient lire la page du projet, en particulier le guide des coordinateurs GLSA et la page des padawans pour se rendre compte de quoi il retourne et de quoi nous avons besoin. Quelles sont les initiatives entreprises récemment par l'équipe de sécurité ? L'année passée, nous avons mis en place des procédures de sorte que chaque règle suivie par l'équipe ait un document de référence. Nous avons aussi monté une équipe qui s'assurera que nous maintenons une surveillance de sécurité minimale à tout instant. Qu'avons nous oublié de demander que nous devrions savoir ? Peut-être notre structure de gestion. Kurt Lieber (klieber) est notre responsable stratégie, Sune Kloppenborg Jeppesen (jaervosz) et moi-même somme les responsables opérationnels. Open-Xchange dans Gentoo Linux Open-Xchange (OX) est le serveur de groupware Open Source sur lequel le serveur Openexchange de SuSE (par Novell) (SLOX) est fondé. Open-Xchange était « Closed Source » jusqu'au 30 août 2004, quand il a été édité sous la GNU Public License. OX s'appuye sur des technologies Open Source populaires en intégrant des projets existants (SMTP, IMAP, LDAP, Apache, Tomcat et PostgreSQL) afin d'offrir un puissant environnement pour la messagerie et la collaboration. Parmi les éléments d'intérêt, nous pouvons trouver l'e-mail, l'organisation de projet, un outil pour créer différentes versions de documents, un calendrier partagé et une base de connaissance. On peut accéder à OX via une interface web ou en se servant de clients comme Evolution ou la suite Mozilla (Thunderbird et Sunbird) et n'importe quelle autre application indépendante qui supporte le WebDAV. En ce moment, Open-Xchange est en développement avec une version stable prévue pour mars 2005. Si vous voulez voir à quoi ressemble OX avant d'entreprendre la tâche un peu intimidante de son installation, vous pouvez l'essayer en vous servant de la démonstration en ligne. Installation et support Il y a en ce moment deux façons d'installer OX sur Gentoo Linux : en se servant de l'ebuild de Bugzilla (pas dans l'arbre Portage en ce moment) ou en l'installant à la main. Une page WIKI explique l'installation avec l'ebuild, mais pour la plupart des étapes nécessaires pour faire tourner OX avec succès, un autre manuel d'installation couvre la configuration prérequise aussi bien que comment étendre et améliorer Open-Xchange. Pour des questions spécifiques à Gentoo, un fil de discussion sur le forum Gentoo a plusieurs centaines de posts qui couvrent la majorité des réponses qui sont disponibles jusqu'à présent. Si vous n'êtes pas déjà familier avec les serveurs qu'OX utilise, soyez préparé à une courbe d'apprentissage plutôt raide et à beaucoup lire. La majorité des problèmes rencontrés jusqu'à présent sont en rapport avec la configuration de LDAP, l'intégration de Apache/Tomcat et l'authentification SASL. Tous les serveurs sur lequel OX repose et dépend ont besoin d'être configurés correctement et d'être en marche avant que vous ne puissiez continuer avec l'installation d'Open-Xchange proprement dite.
OpenMotif : Multiple vulnérabilités dans libXpm De multiple vulnérabilités ont été découvertes dans libXpm, qui est inclus dans OpenMotif. Elles peuvent permettre potentiellement l'exécution de code à distance. (NB: Il s'agit des mêmes vulnérabilités que celles qui ont été supprimées dans xorgs-x11 en novembre dernier) Pour plus d'information, veuillez vous référer à l'annonce GLSA PostgreSQL : outrepassement des privilèges en local Le serveur PostgreSQL peut être manipulé par un assaillant local afin d'exécuter un code arbitraire. Pour plus d'information, veuillez vous référer à l'annonce GLSA Python : exécution de code arbitraire à travers SimpleXMLRPCServer Les servers XML-RPC basés sur Python peuvent être vulnérables à une attaque permettant l'exécution de code arbitraire à distance. Pour plus d'information, veuillez vous référer à l'annonce GLSA pdftohtml : vulnérabilités dans le code Xpdf pdftohtml contient du code Xpdf pour la lecture des fichiers PDF, le rendant vulnérable à l'exécution de code arbitraire à distance lorsqu'il convertit un fichier PDF malveillant. Pour plus d'information, veuillez vous référer à l'annonce GLSA Mailman : parcours possible des répertoires du serveur Mailman ne valide pas correctement ses entrées, ce qui permet de récupérer des informations. Pour plus d'information, veuillez vous référer à l'annonce GLSA Webmin : fuites d'information dans le paquet binaire Gentoo Les paquets binaires de Webmin construits avec Portage contiennent accidentellement un fichier avec le mot de passe root local crypté. Pour plus d'information, veuillez vous référer à l'annonce GLSA Perl : vulnérabilités dans le « wrapper » perl-suid (NdT : wrapper , exécutable réalisant un rôle d'emballage, permettant le lancement d'un autre exécutable dans des conditions d'exécutions particulières) Des vulnérabilités permettant l'écrasement de fichiers et l'exécution de code avec privilèges élevés ont été découvert dans le « wrapper » perl-suid. Pour plus d'information, veuillez vous référer à l'annonce GLSA mod_python : vulénrabilité du « Publisher Handler » (NdT : Publisher Handler, gestionnaire de publication) Le « Publisher Handler » de mod_python contient une vulnérabilté permettant potentiellement une fuite d'information. Pour plus d'information, veuillez vous référer à l'annonce GLSA Supprimer les drapeaux USE « no* » de l'arbre Michiel de Bruijne a écrit : « Il y a pas mal d'ebuilds dans l'arbre qui utilisent un drapeau USE « no* ». Désactiver un de ces drapeaux vous apporte donc en réalité plus de fonctionnalités. Il est également possible d'ajouter des dépendances supplémentaires en désactivant un drapeau USE. Cela a quelques effets collatéraux désagréables »... La suite de la discussion montre assez bien pourquoi ce type de drapeaux n'est pas bon. Stabilisation automatique des paquetages Tous les 6 mois environs la même discussion revient : « Comment maintenir à jour les paquets de portage » ? L'approche naïve voudrait une stabilisation automatique après une certaine période. Ce fil de discussion montre pourquoi dans la plupart des cas ce n'est pas une bonne idée... Fermeture ou résolution des bugs, que choisir ? Marius Mauch a écrit : « Je remarque une nouvelle tendance dernièrement introduite par quelques nouveaux développeurs : le changement du statut de bug de RESOLVED en CLOSED. Personnellement, je trouve cela ennuyeux et complètement inutile. Pouvons nous accepter de laisser faire cela à moins qu'il n'y ait une raison technique ? Je n'y vois aucun avantage, cela signifie juste que les bugs fermés sont maintenant séparés dans deux « catégories » sans réelle différence ». USA : Gentoo Bugday au LUG de l'université de l'État de l'Oregon NdT :
Les Gentoo Bugdays ont lieu régulièrement les premiers samedi de chaque mois, avec des développeurs et des utilisateurs partout qui recherchent par irc ou dans le bugzilla de Gentoo tout ce qui a l'air de devoir être réglé. Le 5 Février, le LUG de l'université de l'État de l'Oregon saisit l'opportunité et transforma l'évènement virtuel en un évènement réel. Douze membres de l'OSLUG sont réunis au Weatherford Hall, l'immeuble du collège résidentiel de l'université de l'État de l'Oregon. Aidés par une liste des bugs précompilée par les organisateurs du Gentoo Bugday pour cette occasion, ils écrasèrent les bogues de 9h00 à 16h00, avec le canal IRC officiel #gentoo-bugs projeté au dessus d'eux et des ordinateurs éparpillés dans la classe, chacun avec un chasseur de bogues déterminé derrière l'écran.
Allemagne : version d'outils de stockage pour Gentoo Linux La distribution d'applications commerciales pour Linux avec un support disponible pour d'autres distributions que le trio RedHat/SuSE/Mandrake est rare. Une entreprise Allemande, SEP AG, a maintenant annoncé la disponibilité de leur outil de gestion de stockage « SEP sesam » pour Gentoo Linux. « Nous sommes traditionnellement liés à SuSE Linux, mais avions Gentoo dans notre ligne de mire depuis que nous avons vu l'installation impressionnante que Lars Weiler a réalisé sur un cluster HP Proliant au LinuxTag de l'année dernière qui s'est déroulé à Karlsruhe », rappelle le responsable commercial de SEP Johann Krahfuss (cf. rapport GWN du 28 Juin 2004). « Ainsi, lorsque nos premiers clients nous ont demandé une adaptation de SEP sesam pour Gentoo Linux, cela ne nous a pas réellement pris par surprise ». L'institution fédérale de la recherche allemande Fraunhofer Gesellschaft a été la première à demander une installation de SEP sesam dans un environnement Gentoo Linux, « et depuis nous n'avons rencontré aucun problème de quelque nature que ce soit, nous sentons que nous sommes prêts pour la version officielle », déclare Krahfuss. Une version d'essai de 30 jours (support compris) peut être téléchargée depuis la section download du site web de l'entreprise. SEP sesam est développé pour la gestion de stockage de données dans des réseaux hétérogènes, incluant Linux, BSD, Solaris, TRU/64, OpenVMS, Windows et Mac OS X. L'entreprise sera présente au CRN Storage Solution Days 2005 (NdT : Journée des solutions de stockage CRN 2005) de la semaine prochaine à Neuss (lien uniquement en allemand). Newsforge (8 et 9 février 2005) Newsforge a publié un article en deux parties concernant l'utilisation de MySQL pour tester les performances du système d'exploitation, comme analysé et écrit par Tony Bourke. Les tests de performances couvrent les systèmes d'exploitation serveur Open-, Net- et FreeBSD, Solaris 10 et Linux comme plates-formes pour l'exécution de bases de données MySQL et Gentoo fut choisie « parmi une multitude de distributions » pour la partie Linux du test, avec les deux kernels 2.4 et 2.6 (gentoo-sources) sur ReiserFS. « avec Gentoo c'était également relativement facile d'installer NTPL pour 2.6, que j'ai utilisé dans les tests 2.6 », a déclaré Tony Bourke, « même si il n'y a pas eu de différence après comparaison avec les résultats de 2.6 sans NTPL ». Alors que la première partie ne fait qu'expliquer les outils et la méthodologie, la comparaison des performances proprement dite est publiée dans un article séparé - avec des résultats impressionants, Gentoo Linux l'emportant clairement sur tous les tests de performances individuels. Assez curieusement, les performances exceptionnelles de Gentoo ont même déclenché des plaintes à propos de « L'avantage injuste » d'utiliser une distribution basée sur les sources, et donc potentiellement optimisée pour le processeur, comme plate-forme de comparaison. Le président de Sun Jonathan Schwartz approuve l'effort OpenSolaris de Gentoo dans une interview publiée par CNET la semaine passée. Pendant qu'il expliquait le modèle de gouvernance d'OpenSolaris au journaliste Stephen Shankland, il revendique « Solaris est maintenant officiellement neutre par rapport à la plate-forme » et espère « 10 ou plus » distributions OpenSolaris non-Sun. Security Focus (2 Février 2005) Le chroniqueur Jason Miller déclare que la gestion de la sécurité du kernel est déficiente « et doit être réparée tout de suite ». L'article de securityfocus.com, une publication lue majoritairement par des professionels de la sécurité, est hautement critique dans la manière dont les bugs de sécurité du kernel Linux sont adressés. Mais l'auteur qui s'est auto-proclammé « grand adepte des systèmes d'exploitations basés sur BSD » a également de bonnes nouvelles : « une fois que l'on commence à regarder les distributions existantes du kernel Linux comme un système d'exploitation complet, on peut trouver certaines distributions avec des contacts de sécurité officiels, ainsi que des pages concernant la sécurité similaires à celles fournies par les distributions majeures des systèmes d'exploitations basés sur BSD. La sécurité de Gentoo Linux en est un bon exemple ». Réseaux & Télécoms (3 Février 2005) Répondant directement à la chronique de Security Focus de Jason Miller, le magazine francais Réseaux et Télécoms regarde plus loin que le kernel en tant que problème de sécurité : les failles dans des applications individuelles ne dépendant pas du kernel et la distribution d'informations relatives à la sécurité sont identifiées comme des champs d'activités aussi importants pour les « chasseurs de bogues de l'open-source ». L'article « Noyau Linux : Mais où est la sécurité ? » témoigne de la conclusion de Miller des « choses qui changent, vite et dans la bonne direction » et félicite Thierry Carrez (voir notre interview plus haut) comme exemple de « travail impressionnant ». Avec le rythme actuel de discussion autour de la structure de la gestion de la sécurité et la distribution de l'information, il est « temps de se montrer optimiste », déclare l'auteur Marc Olanie, qui met en évidence que cela prit 18 ans à Microsoft pour standardiser leurs propres procédures de sécurités -- « mais l'ont ils réellement fait? ». Blogs de Sun (31 January 2005) Eric Boutilier, ingénieur chez Sun Inc., passe à la vitesse supérieure pour les développements de Gentoo sur OpenSolaris et a posté ses premières approches de Portage sur Linux dans son blog sur le site web de Sun. Alors que son choix sur le medium d'installation est particulier - Le clone de Gentoo Vidalinux plutôt que l'installation standard et sur un portable Portégé agé de cinq ans - il s'est rapidement aligné sur le comportement classique d'un utilisateur de Portage pour les grosses compilations : « Et bien, ... je l'ai tranquillement laissé construire et suis retourné au travail ». La communauté Gentoo utilise Bugzilla (bugs.gentoo.org) pour répertorier et suivre les bugs, notifications, suggestions et autres interactions avec l'équipe de développement. Entre le 06 février 2005 et le 13 février 2005, l'activité sur le site se résume à :
Parmi les 8036 bugs actuellement ouverts, 102 sont marqués 'bloquant', 243 sont marqués 'critique' et 600 sont marqués 'majeur'. Les développeurs et équipes qui ont fermé le plus de bugs durant cette période sont :
Les développeurs et équipes à qui le plus de bugs ont été assignés durant cette période sont :
La magie de Portage : identifier les paquets obsoletes Le dévelopeur Gentoo Brian Harring a mis au point une façon astucieuse d'identifier tous les paquets installés qui ne sont plus disponibles dans Portage -- à la fois ceux de l'arbre officiel et ceux de PORTDIR_OVERLAY. Voici la méthode qu'il a présenté, concentrant autant d'habilité en Python qu'il peut en tenir sur une seule ligne de commande :
Si cela vous a paru un poil obscur, regardons ce que cela fait exactement. Par exemple, supposons qu'un paquet, disons foo-1.2.3, est installé et que la version 1.2.3 n'est plus disponible dans l'arbre. Ce script vous l'indiquera. Une vérification des paquets qui ne sont plus disponibles quelle que soit la version prendra la forme :
Ensuite, si vous ne désirez pas vous voir signalé le paquet foo-1.2.3 s'il n'est pas dans l'arbre mais qu'une révision foo-1.2.3-r1 elle l'est, le script suivant ignorera le paquet, ne signalant que les applications qui ont complètement disparu de Portage.
Pour finir, aucune des méthodes ci-dessus ne prend en compte les paquets injectés, mais uniquement ceux qui ont été installés depuis un arbre disponible. Maintenant, si vous désirez ignorer ces paquets également, voici ce qu'il faut faire :
Vous aimez, n'est-ce-pas ? Tout ceci fonctionne pour les paquets que vous conservez dans un arbre en sur-couche, par exemple dans /usr/local/portage, ceux-ci étant pris en compte avec ceux de l'arbre Portage officiel. Essayes, vous ne pouvez rien casser, le script ne fait que vous signaler ce qu'il trouve, laissant à l'utilisateur le soin de décider ce qu'il fera de l'information. 9. Départs, arrivées et changements Les développeurs suivants ont quitté l'équipe de développement de Gentoo Linux :
Les développeurs suivants se sont joints récemment à l'équipe de Gentoo Linux :
Les dévelopeurs suivants ont récemment changé de rôle dans le projet Gentoo Linux :
Vous souhaitez contribuer à la GWN ? Envoyez-nous un courriel. Aidez-nous à améliorer la GWN, envoyez-nous vos commentaires. Pour vous abonner à la Gentoo Weekly Newsletter, envoyez un e-mail vierge à gentoo-gwn-subscribe@gentoo.org. Pour vous désabonner de la Gentoo Weekly Newsletter, envoyez un e-mail vierge à gentoo-gwn-unsubscribe@gentoo.org depuis l'adresse utilisée pour votre abonnement. La GWN est aussi disponible dans les langues suivantes :
|
|
