FreeBSD Quand le dragon est de sortie

Posté par (page perso) . Modéré par Nÿco.
Tags :
25
3
nov.
2010
FreeBSD
Tout le monde était tellement occupé par la récente sortie d'OpenBSD (sic!) que l'on en a presque oublié le monde « des autres » !

En effet, deux jours avant cet événement interplanétaire, s'est produite une anomalie, qui aurait pu passer inaperçue (mais j'ai un œil de lynx combo aigle (+10 acuité visuelle), moi Monsieur !), à des années-lumière d'ici. En effet, l'équipe de DragonFly BSD, après avoir couvé son œuf pendant de longs mois, a sorti la version 2.8.2 de son petit protégé.

Pour ceux qui ne connaissent pas DragonFly BSD, il s'agit d'une cuillère (euh non excusez moi, d'un fork... L'émotion sans doute !) de FreeBSD. On prend nos masques, nos tubas et nos palmes, et on plonge un peu plus profond pour découvrir les principales nouveautés :
  • Retour de l'interface graphique. Cette version inclut une image USB qui contient un environnement X fonctionnel (ainsi que ses sources)
  • Au niveau du chiffrement, on peut noter l'apparition d'un framework compatible avec cryptsetup qui vous permet de chiffrer vos partitions DragonFly BSD (par exemple, /home, / ou même la swap)
  • PacketFilter est dorénavant disponible en version OpenBSD-4.2
  • Sans fil : la pile WiFi de FreeBSD a été portée
  • Améliorations des performances multiprocesseurs
Au niveau des disponibilités (32 et 64 bits), vous trouverez tout ce qu'il vous faut pour vos galettes, vos sticks et j'en passe :
  • Une ISO gravable ou à utiliser avec une solution de virtualisation
  • Une image amorçable en USB
  • Une image contenant un environnement X amorçable en USB
Tout ceci est disponible, comme toujours, sur le oueb [0].

Pour ceux qui seraient mieux équipés que moi et qui aiment les grands fonds, je vous laisse jeter un œil aux notes de version [1].

[0] http://www.dragonflybsd.org/download/
[1] http://www.dragonflybsd.org/release28/
(41 commentaires).

  • # Ohai

    Posté par (page perso) . Évalué à 5.

    À noter: une news un peu plus complete sur cette release de PwetpwetBSD:

    http://www.gcu-squad.org/2010/11/flap-flap-flap-fait-la-libe(...)

    • [^] # Re: Ohai

      Posté par (page perso) . Évalué à 9.

      En passant, quelques détails/nouveautés évoquées dans aucune des deux news:

      - L'importation de LVM, depuis NetBSD pour la partie kernel, les outils GNU pour le userland, LVM commence donc à être pas mal multi plateformes (Linux, HPUX, NetBSD, Dragonfly BSD) et donc de device-mapper, ce qui a permis l'implémentation de dm-crypt (qui se veut compatible avec linux) et qui est une bonne chose pour l'utilisation de disques externes chiffrés entre différents OS. À noter que la cible "stripe" de device mapper est également présente.

      L'importation de dm-crypt et LVM a poussé à fournir un systeme d'initrd ainsi qu'un mkinitrd pour pouvoir booter sur ce type de volumes.

      - La réécriture du surranné bootloader écrit en Forth, hérité de FreeBSD en C, et renommé dloader (http://leaf.dragonflybsd.org/cgi/web-man?section=8&comma(...) ).

      - L'apparition de dsched, framework générique pour diffents schedulers I/O dans le kernel, ainsi que l'implémentation de dsched_fq, une politique de "fair queuing", ainsi que de "ioprio", un ionice like.

      - Un gros boulot d'optimisation de la gestion de la mémoire virtuelle, dont le retrait du Global Lock, remplacer par un lock spécifique aux opérations de la VM, l'implémentation de "Idle Page Zeroing", qui consiste à "nettoyer" les pages mémoires inutilisées sur le temps d'idle du systeme afin d'accélérer leur allocation le moment venu. Une très bonne explication est disponible ici:

      http://www.mail-archive.com/kernel@crater.dragonflybsd.org/m(...)

      Et last but not least, _enfin_ l'apparition de la commande swapoff.

      Bien entendu, plein d'autres choses, mais au moins j'ai fait un effort plutot que pomper et raccourcir la news de GCU, sur un ton qui sonne mal, et sans vérification des sources.

      --
      twisla

      • [^] # Re: Ohai

        Posté par (page perso) . Évalué à -3.

        Aigritude spoted !

        Je suis sûr qu'un modérateur se serait le plaisir de fusionner deux dépêches si tu en avais proposé une aussi.

        • [^] # Re: Ohai

          Posté par (page perso) . Évalué à 8.

          C'est fou comme une pique presque caricaturale vous donne l'occasion de poster.

          Alors qu'il serait si simple de parler des 90% informatifs du commentaire - qui, ajoutés à la dépeche originale sur GCU et son résumé ici (porteur de la bonne parole aux masses) - ne fait que détailler les choses intéressantes apportées par cette nouvelle version.

          DragonFly est un des OS les plus dynamiques, en constante évolution, doté d'une communauté acceuillante et d'un excellent niveau technique. Sa confidentialité est à mon avis un de ses grands atouts, ça évite les discussions interminables, et lui fait garder une mentalité - code first, whine after - sans le coté hautain et élitique d'OpenBSD.

          Bref, tout ça pour dire que cette dernière ligne était là pour mettre un coup de pied dans la ruche, et inciter à la discussion, mais je vois que ça n'attire que des charognards qui ignorent tout contenu additionnel.

          Il reste que, quand je me sers du travail des autres, j'ai au moins la décence de les citer, c'est tout ce à quoi la licence BSD m'astreint.

          Cordialement ppr,
          twisla

          • [^] # Re: Ohai

            Posté par (page perso) . Évalué à 2.

            code first, whine after - sans le coté hautain et élitique d'OpenBSD.

            Alors c'est éthylique plutôt, non ?

            Perso je ne vois pas trop ce que DragonFly a apporté comme innovation, contrairement à Open ou Net.

            Ce qui n'enlève rien au mérite du projet.

            • [^] # Re: Ohai

              Posté par . Évalué à 3.

              Bonjour Patrick,

              Ne peux t-on pas considérer HAMMER : http://www.dragonflybsd.org/hammer/ comme tel ?

              Cordialement,

              • [^] # Re: Ohai

                Posté par (page perso) . Évalué à 4.

                Ne peux t-on pas considérer HAMMER : http://www.dragonflybsd.org/hammer/ comme tel ?

                Vu que personne ne l'a intégré ailleurs je dirais que non. C'est peut-être innovant mais pas forcément convaincant ?

                En comparaison, Open et Net ont fourni quantités de trucs qui ont été importés dans les autres BSD. C'est un constat, pas une critique de DragonFly (et j'aime bien lire M.Dillon, il est super intéressant)

                • [^] # Re: Ohai

                  Posté par . Évalué à 1.

                  Bonjour,

                  Là, si on parle de convaincant, je le conçois :)

            • [^] # Re: Ohai

              Posté par . Évalué à 3.

              Justement, il est en train d'expliquer que DragonFly n'apporte pas une legion de trolleurs chapotes par un gourou qui hurle plus fort que tout le monde, contrairement a openBSD.

              (j'ai pas pu attendre vendredi, desole)

              • [^] # Re: Ohai

                Posté par . Évalué à 2.

                Bonjour,

                Il ne hurle pas, il argumente :)
                Quand aux trolleurs, ce sont bien souvent des électrons libres.

                • [^] # Re: Ohai

                  Posté par . Évalué à 2.

                  Qui gravitent autour du noyau De Raadt.

                  • [^] # Re: Ohai

                    Posté par . Évalué à 3.

                    Bonjour,

                    Cette simple assertion tend à laisser penser que vous gravitez aussi :)

        • [^] # Re: Ohai

          Posté par (page perso) . Évalué à 1.

          Surtout que, au final, la news de GCU, malgré qu'elle soit plus complète, n'est "qu'un" copié/collé de cette page (http://www.dragonflybsd.org/release28/) avec les premiers paragraphes traduit dans la langue de Mr Poquelin...

          • [^] # Re: Ohai

            Posté par (page perso) . Évalué à 2.

            Il n'empêche qu'elle émane de quelqu'un qui suit les mailing lists de dragonfly au jour le jour, a plusieurs machines en production, tire avantage de HAMMER sur ces machines, et _surtout_, sait de quoi il parle.

            Mais je te remercie grandement d'avoir fait l'effort de poster une news sur linuxfr et du coup, participer à sa diffusion, tout ce que j'espère, c'est que cela poussera certains à l'essayer.

            • [^] # Re: Ohai

              Posté par (page perso) . Évalué à 5.

              Ce qui me surprends surtout, c'est que la news sur GCU ressemble à une news de patrick_g sur une sortie du noyau et que la news sur linuxfr s'apparente à news GCU...

              Où va le monde ! On a plus de repère ! Vous avez pensé aux enfants !

  • # libellule

    Posté par (page perso) . Évalué à 10.

    c'est pas un dragon mais une libellule

  • # fork

    Posté par . Évalué à 2.

    c'est une fourchette, pas une cuillère (sinon ca serait spoon)

  • # Ya que moi que ça choque ????

    Posté par . Évalué à 0.

    il s'agit d'une cuillère (euh non excusez moi, d'un fork... L'émotion sans doute !)

    Je crois qu'on dit plutôt le "spoon" d'un projet...

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

  • # signature MD5 pour les fichiers à télécharger

    Posté par . Évalué à 2.

    En lisant la dépêche que tu cites sur www.gcu-squad.org me vient la question : pourquoi fournir des signatures MD5 alors qu'il est connu qu'il est possible de provoquer des collisions de signatures avec cet algorithme ?


    Lorsque je considère ce que propose Debian, je vois du MD5 (pourquoi est-ce encore utilisé ?) mais aussi du SHA1, SHA256 et SHA512 (par exemple, miroir ici : ftp://ftp.proxad.net/mirrors/cdimage.debian.org/debian-cd/5.(...) ).

    On y trouve aussi un fichier de signature PGP (par "GnuPG v1.4.10 (GNU/Linux)" c'est précis) pour chaque fichier de signature MD5|SHA1|... de manière à authentifier le contenu des fichiers concernés (je me questionne d'ailleurs sur la pertinence de ces outils pour garantir la parfaite conformité des données... étant donné la possibilité de modification de trame à la volée entre le serveur Web/FTP... et l'utilisateur (les fichiers de signature comme le reste peuvent être modifiés entre les deux)... Mais il est tard, je me réserve une réflexion plus poussée pour une autre fois).

    Je serais ravi d'avoir des réponses pertinentes à mes question :-)

    • [^] # Re: signature MD5 pour les fichiers à télécharger

      Posté par . Évalué à 1.

      Erreur de "routage", c'est à "twisla" que j'aurais du répondre. Je recolle le lien vers la dépêche en question : http://www.gcu-squad.org/2010/11/flap-flap-flap-fait-la-libe(...)

      (et je corrige en "questions" mon usage erroné du singulier)

    • [^] # Re: signature MD5 pour les fichiers à télécharger

      Posté par . Évalué à 7.

      Certes depuis quelques années des moyens de générer des collisions de hash MD5 ont été publiés, cependant cela ne veut pas dire que toutes les utilisations de MD5 sont vulnérables.

      En fait on sait "très" facilement générer deux clés X et Y pour lesquelles MD5(X) == MD5(Y).

      On sait aussi un peu moins facilement ( comprendre avec une très grosse complexité algorithmique ) générer une clé Y pour laquelle MD5(Y) == X.

      En résumé, on peut générer une image bidon dont le MD5 correspondrait à celui de l'image de DragonFlyBSD, cependant on ne contrôle pas du tout le contenu de cette image, donc de là à insérer du code malicieux dans l'image, il y a beaucoup de boulot.

      Ça peut certes se faire en brute force avec du code de bourrage mais c'est très long et il est fort probable que l'image fasse plusieurs Gio au final.

      Donc en gros MD5 est cassé pour certaines utilisations notamment le hash de mot de passes, mais pour des hash d'images iso il fait encore bien l'affaire même si le plus simple serait de passer à SHA-X.

      Disclamer: Peut être que d'autres vulnérabilité ont été publiées depuis la dernière fois que je me suis renseigné.

      • [^] # Re: signature MD5 pour les fichiers à télécharger

        Posté par . Évalué à -1.

        je t'inviterais à regarder un petit truc se basant sur le md5 :
        http://www.win.tue.nl/hashclash/Nostradamus/

        Donc non, on peut très bien générer des documents dont on contrôle le contenu (affiché) avec les mêmes sommes md5.

        • [^] # Re: signature MD5 pour les fichiers à télécharger

          Posté par (page perso) . Évalué à 2.

          Ce n'est pas la même taille de fichier, je ne suis pas sûr que ce soit aussi simple pour une image iso.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: signature MD5 pour les fichiers à télécharger

            Posté par . Évalué à 2.

            Je réagis en soumettant cette réflexion.

            Tant qu'à faire le travail de mise en oeuvre de la sécurité, autant le faire solidement, sinon c'est carrément ridicule parce qu'improductif ou même risqué (croyance illusoire de sécurité).

            Lorsqu'on télécharge un fichier .ISO d'un programme (comme un système d'exploitation), on dispose en général d'une signature de contrôle d'intégrité, sur une page Web du site original notamment. Charge à l'utilisateur de vérifier que cette signature est la même que celle qu'il reproduit chez lui, par application du même calcul (de la signature) à partir du fichier .ISO reçu.

            On observe que le protocole de contrôle d'intégrité n'implique pas de vérifier nécessairement la taille du fichier reçu. Or il est avéré que l'algorithme MD5 est risqué du fait d'une "collision de signature" : il est possible de fabriquer un contenu qui aura la même signature qu'un contenu de référence (on récupère un .ISO corrompu mais le contrôle est bon).

            Au passage, ça démontre l'insouciance des équipes qui pondent des programmes en proposant la signature MD5 uniquement, sur leur site Web.

            Pour aller plus loin, imaginons que sur la page web du site, il y ait une signature SHA-1, mais qu'elle soit changée le temps que l'information arrive chez l'utilisateur. À un point quelconque du chemin (un routeur... Un fournisseur d'accès à Internet par exemple), elle pourrait être changée pour être conforme au .ISO qui est reçu... L'utilisateur ne verrait que du feu lors de la vérification de la signature SHA-1... De l'intérêt de réfléchir.

            Pour éviter le problème ci-dessus, je considère que la page HTML sur laquelle se trouve la signature SHA-1, ou le FTP sur lequel on prend le fichier qui contient cette signature, doivent être accédés en mode "sécurisé" (https, si ça suffit, je ne suis pas sûr... Avec un certificat auto-signé, sans tier de confiance impliqué, comme pour Linuxfr...). Il s'agit d'obtenir l'assurance qu'on s'adresse bien au bon site et que les données ne sont pas corrompues.

            En fait il faut une authentification de la source qui propose la "signature de contrôle d'intégrité" (le fichier SHA1|256|512) et un contrôle d'intégrité sur cette signature.

            Je crois comprendre que c'est ce que propose Debian avec ses fichiers de signature PGP. Par exemple, on trouve le fichier de signature SHA256 "SHA256SUMS" et le fichier de signature PGP associé "SHA256SUMS.sign". Ces fichiers .sign doivent permettre de réaliser les deux fonctions a) d'authentification et b) de contrôle d'intégrité des signatures MD5|SHAx. Je n'ai pas encore vérifié ces supputations, je n'ai pas encore eu l'occasion de télécharger et de mettre en oeuvre les .ISO de Debian.

            Si quelqu'un a investigué sérieusement le protocole proposé par Debian, merci de réagir.

            • [^] # Re: signature MD5 pour les fichiers à télécharger

              Posté par . Évalué à 2.

              En réfléchissant quelques instants de plus, je note que si les .sign précités réalisent bien les deux fonctions que je mentionne, je ne vois pas ce qui empêche de simplifier le processus en proposant uniquement des .sign qui authentifieraient le .ISO tout en permettant d'en contrôler l'intégrité.

              Est-ce une question de simplicité des algo SHAx qui encourage leur usage, du fait d'un temps de calcul minimisé par rapport aux signatures PGP produites par GPG ?

              Dernière question pour qui a mit en oeuvre GPG pour exploiter les données des .sign de Debian : comment obtient-on la certitude que l'on récupère bien des .ISO mis à disposition par le projet Debian ? Le .sign est produit par une clé privée, dédable par la clé publique correspondante, comment l'utilisateur final peut s'assurer de l'identité du (des) détenteurs de la clé privée ?

              Idéalement, je considère qu'il faudrait une signature GPG réalisée par chacun des membres d'une portion (élue) de la communauté concernée (Debian dans l'exemple). Ainsi, en cas de fuite d'une des clés privées, impossible de reconstituer l'ensemble des signatures valides, à moins d'avoir obtenu l'ensemble des clés privées utilisées !
              Simple et très efficace !

              Si ça continue comme ça, je vais faire un journal :-)

          • [^] # Re: signature MD5 pour les fichiers à télécharger

            Posté par . Évalué à 2.

            et qu'est ce qui empêche de faire du padding ?

  • # ...

    Posté par . Évalué à 1.

    1) C'est pas le bon logo en tete de dépêche, c'est dommage
    2) le nom du projet est DragonFly pas DragonFly BSD

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.