Sortie d'OpenBSD 4.0

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
2
nov.
2006
OpenBSD
La sortie de la nouvelle version du système d'exploitation libre et sécurisée OpenBSD a été annoncée ce mercredi premier novembre par Theo de Raadt, le leader du projet. Comme d'habitude les progrès sont incrémentaux plutôt que radicaux. C'est une politique mûrement réfléchie afin de ne pas risquer de déstabiliser le code source en introduisant des bugs.

Parmi les points notables de cette version 4.0 on peut relever la prise en charge de l'architecture UltraSparc III ou de plusieurs gadgets basés sur le processeur ARM. Le travail d''amélioration des pilotes pour les cartes wifi ou pour les cartes Gigabit ethernet continue ainsi que le combat du projet OpenBSD pour obtenir de la documentation de la part des firmes qui construisent ces matériels.

Les principaux outils d'OpenBSD (comme pf le firewall ou CARP qui gère la redondance) sont améliorés et GNU RCS (Revision Control System) est remplacé par OpenRCS. Un gros travail a également été effectué sur le support du contrôle de la vitesse des processeurs en fonction de la charge (SpeedStep ou PowerNow).

Une fonction intéressante est celle apportée par l'outil prebind (qui permet de réduire le temps de chargement de certains programmes). Il est commun dans le monde Linux d'utiliser le prelinking afin de profiter de cette amélioration mais les développeurs d'OpenBSD voulaient que cela ne se paye pas au prix de la sécurité. En effet ce prelinking est incompatible avec le chargement aléatoire des librairies (address space randomization) et cette fonction est cruciale dans un système aussi paranoïaque que l'est OpenBSD. L'outil prebind permet maintenant de maintenir le chargement aléatoire tout en profitant de la rapidité du prelinking.

Le site Softwareinreview propose dès maintenant un aperçu d'OpenBSD 4.0 ainsi qu'un petit guide d'utilisation de cette nouvelle version.
Sur le site O'Reilly on peut lire une interview très complète (et très technique) des principaux développeurs OpenBSD au sujet de cette version 4.0 de leur projet.

Aller plus loin

  • # Deux très bons articles

    Posté par  . Évalué à 6.

    J'ajouterai à cette dépêche deux très bons articles, un recensant les nouveautés de cette version, et un donnant un aperçu global de l'utilisation du système par rapport à d'autres unices :
    http://www.softwareinreview.com/cms/content/view/55/
    http://www.softwareinreview.com/cms/content/view/56/

    De plus, pour ceux qui veulent l'installer, un miroir officiel français est à jour ici : ftp://ftp.irisa.fr/pub/OpenBSD/4.0

    Pour ceux qui hésitent à tester cet OS, n'ayez pas peur, on retrouve vite ses réflexes après une courte période d'adaptation, la documentation est très bien faite, et pour une utilisation quotidienne sur un ordinateur de bureau multimédia y'a aucun problème.

    Le seul bémol serait un plus petit nombre de logiciels disponibles (~3700 ports, a comparer aux ~17000 ports FreeBSD ou ~19000 paquets debian, chiffres à la louche), mais les principaux sont présents : Environnements de Bureau (Kde/Gnome/Xfce/...), Suites bureautiques (OpenOffice 2/Gnome-office/Koffice), navigateurs web (Firefox community edition :)/Konqueror/Epiphany..)

    L'essayer, c'est l'adopter.
    • [^] # Re: Deux très bons articles

      Posté par  . Évalué à 2.

      Oops, évidemment, j'avais pas vu les liens déja présents tout en bas de l'article....
    • [^] # Re: Deux très bons articles

      Posté par  (site web personnel) . Évalué à -1.

      >> la documentation est très bien faite

      Certes mais elle est en anglais. C'est pas pour troller mais dans ma distro Linux j'ai les man pages en français et ça aide bien.
      Je sais qu'OpenBSD atttache une grande importance à la documentation et que les devs sont fiers de leurs pages de man mais j'aimerais qu'ils s'intéressent également aux traductions.
      • [^] # Re: Deux très bons articles

        Posté par  . Évalué à 5.

        Vu l'équipe réduite, ils ont pas forcément la capacité de tout traduire non plus.

        Par contre, je doute qu'ils refusent les contributions.
        • [^] # Re: Deux très bons articles

          Posté par  (site web personnel) . Évalué à -2.

          Sur la FAQ OpenBSD on peut lire ceci :

          OpenBSD est fourni avec une abondante documentation sous la forme de pages de manuel, ainsi que d'autres documents relatifs à des applications spécifiques. Un effort considérable est fourni pour s'assurer que les pages de manuel sont à jour et correctes. Dans tous les cas, celles-ci sont à considérer comme la source faisant autorité concernant les informations sur OpenBSD.

          Donc cette abondante documentation qui fait autorité n'est pas disponible dans ma langue.
          Comment alors puis-je installer et utiliser OpenBSD si j'en ai envie ?

          Les devs OpenBSd ont choisis de se concentrer sur les man pages pour la doc. Ils ont une politique stricte qui impose de documenter tous les changements qu'ils effectuent et le résultat c'est que leurs man pages sont complètes et à jour (par rapport à Linux c'est vraiment mieux). Le gros bemol c'est que cette fantastique doc est in english only !

          Je sais bien que les devs sont en petit nombre, qu'ils ne peuvent pas tout faire...etc etc
          Néanmoins le constat est là : la doc man est uniquement en anglais et cela représente une barrière à l'entrée très importante pour la majorité des gens (certains trolleurs diraient que cette barrière à l'entrée n'est pas pour déplaire aux devs OpenBSD mais je ne suis pas de cette espèce poilue donc je ne dirais rien...).
          J'ai suffisamment vu des interviews de devs OpenBSD qui se félicitent de leur excellente doc et qui signalent de façon répétitive que c'est un énorme plus par rapport à Linux pour prendre un peu la mouche à ce sujet. Certes votre doc est excellente mais le problème c'est que 90% de la planète ne peux même pas la lire !

          Pour nuancer mon propos il faut signaler la FAQ en français qui est assez complète : http://openbsd.org/faq/fr/index.html

          Malheureusement elle est très loin d'être aussi complète et à jour que les pages man.
          • [^] # Re: Deux très bons articles

            Posté par  (site web personnel) . Évalué à 2.

            Comme tu le dis très bien, les pages de manuel font autorité, le problème c'est que sur un projet comme linux avec une visibilité et un panel de contributeurs beaucoup plus important que OpenBSD, les pages de manuels moins nombreuses ne sont pas du tout à jour au niveau traduction : http://fr.tldp.org/manfr.php dernière mise à jour 2003...

            Comment veux tu qu'un projet comme OpenBSD pour lequel les manuels font autorité puisse fournir des docs à moitié traduite (car c'est ce qui se passera au final.) Ils ont décidé (je pense) de tout faire dans une seule langue de ne pas fournir de traduction pour éviter ce genre problème. (Les pages de manuels sont très souvent modifiées).

            Maintenant rien n'empêche de mettre en place un projet de traduction des man (certainement jamais intégré dans le socle, mais peut être disponible via les ports.) Ce projet serait grandement apprécié je pense, même si non-officiel.
          • [^] # Re: Deux très bons articles

            Posté par  . Évalué à -5.

            Tu fais comme tout le monde en informatique, et tu prend des cours d'anglais.

            J'en ai ras le bol de voir les français pleurer parce que tout est en anglais en informatique, mais ne pas être foutus de sortir un projet francophone décent et utile. Et oui, je suis français.

            D'ailleurs vous savez comment on appelle quelqu'un qui parle trois langues ? Un trilingue.
            Et quelqu'un qui parle deux langues ? Un bilingue.
            Et enfin, quelqu'un qui ne parle qu'une seule langue ?

            Un français.


            Tu ne veux pas faire l'effort d'apprendre l'anglais ? Revend ton pc et cherche un poste à l'académie française...

            /me, qui en a vraiment ras le bol de ce nationalisme de m****.
            • [^] # Re: Deux très bons articles

              Posté par  . Évalué à 8.

              /me, qui en a vraiment ras le bol de ce nationalisme de m****.

              Bonjour,

              Mais pourquoi s'énerver ainsi?

              Juste pour rendre un peu le monde meilleur, je te rappelle que tu dialogues avec un être humain. Et le dialogue en haussant la voix et en devenant grossier abouti rarement à faire passer les idées. Ca à souvent juste comme conséquence de mettre ses interlocuteurs sur la défensive.

              Alors juste pour que tu participes à l'amélioration de la vision que peuvent avoir les autres sur le français, vu que cela semble te toucher, un peu de courtoisie serait la bienvenue.
              • [^] # Re: Deux très bons articles

                Posté par  . Évalué à 3.

                La question n'est pas là. Au XXIe siècle, tu apprends à communiquer en anglais ou tu meures. Tu te sors les doigts du c... et au lieu de pleurnicher tu vas prendre des cours d'anglais, comme le font les chinois, les japonais ou les africains. Surtout que lire des pages de man, faut pas déconner, il n'y a pas besoin d'être Shakespeare.

                Il faut arrêter de cacher sa paresse intellectuelle derrière des arguments fallacieux : apprendre une autre langue ne peut décemment pas être considéré comme un apauvrissement culturel.

                Bon, et en plus, même si les pages de man étaient traduites, les commandes UNIX restent en anglais, les fichiers de conf restent en anglais, les langages de programmation restent en anglais, les jeux de mots sur les programmes restent en anglais, les logs restent en anglais... Connaitre un minimum d'anglais me semble indispensable pour l'utilisation correcte d'un ordinateur.

                Donc oui, OK, tu ne parles pas anglais, c'est triste pour toi, mais au lieu de te battre pour que les man soit traduits, tu pourrais plutôt te battre pour que les gamins apprennent l'anglais correctement à l'école.
                • [^] # Re: Deux très bons articles

                  Posté par  . Évalué à 3.

                  Surtout que lire des pages de man, faut pas déconner, il n'y a pas besoin d'être Shakespeare.

                  Et bien, même si je me débrouille pas mal en anglais, en italien, et aussi en japonais, je dois t'avouer que certaines pages de man me laissent perplexe et que j'ai du mal à vraiment tout comprendre. j'ai même eu beau les montrer à un anglais non informaticien et il avait lui même du mal à comprendre la tournure des phrases.

                  Alors certes le français serait un mieux, mais si pas de bras (anglais) pas de chocolat (openbsd)...

                  Il est vrai qu'il est difficile de râler quand tout est gratuit ;-) non ?
                • [^] # Re: Deux très bons articles

                  Posté par  . Évalué à 5.

                  Faudrait essyer de ne pas tout confondre quand meme .
                  C'est pas parce que le nom du commande est en anglais, que dans la plupart des langages de programmation les mots resevés sont en anglais , que l'on peut dire que c'est de l'anglais ( reciproquement pour les fichiers de conf et les logs ) . Pretendriez vous que l'anglais et le programmation sont la meme chose ? Qu'un anglais comprendrait un sripte bash sans problemes ? Et si, il faut deja avoir une certaine facilité avec l'anglais pour comprendre une page de manuel de 1000 lignes .
                  Je dois dire que je n'apprecie vraiment pas vos tons .
                  Il y a des personnes qui ont plus de facilité a une langue que d'autres . Ceci ne veut pas dire qu'elles ne peuvent pas utiliser un os comme openBSD .
                  Alors facile de dire : Il faut travailler l'anglais .
                  Mais pour ceux qui n'en ont jamais fait et qui ont plus de 30, la tâche est plus que difficile .
                  Alors faudrait se calmer, parce que vos reponses sont limites insolentes .
                  • [^] # Re: Deux très bons articles

                    Posté par  . Évalué à 1.

                    Ouais c'est vrai ça bande de sales jeunes !! Moi je voudrais les pages man en dunkerquois !;) non sans dec faut arrêter de déconner, faire de l'informatique quand on parle pas anglais, du moins le lire c'est un peu limit nervous break down !
                    • [^] # Re: Deux très bons articles

                      Posté par  . Évalué à 3.

                      C'est facile de dire ça . Je te ferrai remarquer que je ne suis pas vieux d'une part et que je me debrouille en anglais .
                      D'autres part est ce que j'ai critiqué openBSD ? Bien sur que non, non seulement par ce qu'il est gratuit et ensuite parce que c'est un bon OS . Je ne peux juste pas laisser passer vos remarques desobligeantes et non justifiées c'est tout .
          • [^] # Re: Deux très bons articles

            Posté par  . Évalué à 9.

            Comment alors puis-je installer et utiliser OpenBSD si j'en ai envie ?

            Bonjour,

            Tu as donc en gros 2 choix:
            - Tu en profites pour améliorer ton anglais.
            - Tu choisis un autre OS.

            Ce n'est pas pour me moquer. Je suis sérieux.

            Je comprend bien que la barrière de la langue t'empêche de profiter d'OpenBSD, mais je pense qu'un jour il est temps de se demander ce que tu peux faire pour y remédier plutôt que d'attendre que des gens te fassent des man en français.

            Par contre, ta critique sur le barrage de la langue est tout de même intéressante et constructive.

            Mais concernant la question que tu te poses, il y a tout de même une solution que tu peux mettre en oeuvre par toi même, sans attendre.

            Bonne journée
            • [^] # Re: Deux très bons articles

              Posté par  (site web personnel) . Évalué à 3.

              >> Je comprend bien que la barrière de la langue t'empêche de profiter d'OpenBSD, mais je pense qu'un jour il est temps de se demander ce que tu peux faire pour y remédier plutôt que d'attendre que des gens te fassent des man en français.

              Je signale juste que j'ai soulevé ce problème de manière purement réthorique. Je peux parfaitement lire l'anglais et après tout j'ai bien pu lire l'annonce de Theo et les divers articles et interviews necessaires pour rédiger cette news sur la sortie de la version 4.0.
              Comme je l'avais fait pour la version 3.9 : http://linuxfr.org/2006/05/01/20747.html
              Ou pour la version 3.7 : http://linuxfr.org/2005/05/18/18956.html

              Tout ça pour dire que j'aime cet OS et que je me félicite de son existence mais que je tenais à souligner ce point négatif.
          • [^] # Re: Deux très bons articles

            Posté par  . Évalué à 2.

            Certes votre doc est excellente mais le problème c'est que 90% de la planète ne peux même pas la lire !
            Y'a bien 90% de la planète qui n'a pas accès aux ordinateurs. Je suppose que ceux qui y ont accès ont en moyenne une meilleure maitrise de la langue anglaise que la moyenne planétaire, et je devine que le taux d'anglicisation est encore plus élevé parmi ceux qui comptent vraiment jeter un coup d'oeil dans la doc. Je ne remets pas en cause le fait qu'une doc localisée accélèrerait l'adoption d'OpenBSD mais votre formulation me semble donner une vision disproportionnée du "handicap" de la langue.
          • [^] # Re: Deux très bons articles

            Posté par  (site web personnel) . Évalué à 2.


            Certes votre doc est excellente mais le problème c'est que 90% de la planète ne peux même pas la lire !


            Je suis français et j'aime bien trouvé des docs en français pour bien comprendre ce que m'apporte tel ou tel logiciel.
            Mais bon, déjà avoir accès à une doc à jour et complète, c'est que du bonheur à mes yeux.
            Et puis si 90% de la planète n'arrive pas à lire de l'anglais combien cela serait pour une doc en français ?!? 99,2% peut-être ?!?
            Si on suit ce type de raisonnement, il faudrait écrire les docs en Mandarin pour avoir le plus de personnes capables de la lire à l'échelle de la planète... Mais dans ce panel de personnes, combien en ont réellement envie ?

            Bref, je trouve choquant ce genre de propos et totalement hors sujet.

            PS: Par contre personne n'interdit de faire des traductions des documentations OpenBSD
      • [^] # Re: Deux très bons articles

        Posté par  (site web personnel) . Évalué à 3.

        http://openbsd.org/faq/fr/index.html

        le faq en français devrait déjà beaucoup t'aider et sinon il existe de noubreuse documentation en français sur internet.
      • [^] # Re: Deux très bons articles

        Posté par  . Évalué à 4.

        La politique (actuelle) du parti est qu'il vaut mieux ne pas avoir de pages de manuel traduites, plutôt que des pages traduites mais obsolètes.

        Si beaucoup de pages (comme la documentation des fonctions de la libc) sont relativement statiques, en revanche pour les parties du système évoluant plus vite, le risque est grand que les traducteurs ne puissent pas fournir de traduction suffisamment rapidement, ou que les gens n'aient plus du tout de temps à consacrer à cette activité (on le voit très bien avec les traductions du site web, où certaines traductions disparaissent pendant plusieurs années parce que personne n'est là pour fournir l'effort de tenir la traduction à jour).

        Ceci dit, comme proposé plus bas dans cette enfilade, on ne verra pas d'un (trop) mauvais oeil un projet de traduction indépendant.
  • # haaaaaa

    Posté par  (site web personnel) . Évalué à 2.

    elle à finie par passer cette news :) moi qui guettais le 31 à 23h59 ...
    quoi j avais qu' à la faire ? okok

    ce qui surprends et ravi toujours avec OpenBSD, c' est l' installtion : c' est du pur bonheur : en 20 minutes montre en main (avec partitionnement manuel) sur un serveur poweredge (plus tout jeune), le système est opérationnel avec une fstab comme on les aime :)

    me tarde de l' essayer sur une récup de IBM PowerPC en plus du poweredge.
    tellement que j' ai craqué, j' ai DL la version sabo**** de l' iso bootable en attendant de recevoir le CD par Ikarios (qui j' espère ne tardera pas trop)
    http://www.ikarios.com/p488-OpenBSD.html

    ps : Sir Bergamini maintenait (aussi) un petit script "make_me_a_bootable_openbsd" mais je ne le trouve plus .... quelqu' un aurait le lien SVP ? Merci
  • # Perfs ?

    Posté par  . Évalué à 1.

    A mon corps défendant, je sais que je risque de lancer un troll velu, mais je ne peux pas m'empêcher de demander :
    D'après les tests de http://bulk.fefe.de/scalability/ , il semblait que OpenBSD avaid de sérieux problèmes de performances / scalabilité (ça se dit ?), notamment face aux noyaux Linux2.6/FreeBSD/NetBSD.

    Mais depuis, de l'eau a dû couler sous les ponts => qqun sait-il ce qu'il en est maintenant ?
    • [^] # Re: Perfs ?

      Posté par  . Évalué à 2.

      Mais OpenBSD ne vise pas a faire des perfs de fou dingue. Ils visent la securité.

      Ensuite, suite à ce bench, NetBSD et OpenBSD ont bosser, et amelioré les point qui pêchait.
      Suite à ça, un bench à été refait, je te laisse le soin de le trouver...! :)
      • [^] # Re: Perfs ?

        Posté par  . Évalué à 1.

        Ils visent la sécurité, OK, justement j'ai bien envie de metttre OpenBSD en prod en tant que firewall, tellement je trouve pf magnifique. Seulement dans ce contexte, tu t'attends à une grosse capacité de montée en charge. La sécurité c'est aussi la résistance aux DoS non ?
        • [^] # Re: Perfs ?

          Posté par  . Évalué à 3.

          C'est quoi le debit de ton lien...?

          Parce qu'a moins de mettre un PII, ton lien sera à genou avant ton processeur...! :)
  • # Prelink

    Posté par  . Évalué à -4.

    > En effet ce prelinking est incompatible avec le chargement aléatoire des librairies (address space randomization)

    Pipo. Prelink de Linux est compatible avec des adresses aléaloires.

    M'enfin, une news openBSD sans un troll sur Linux, ce n'est pas une news openBSD.
    • [^] # Re: Prelink

      Posté par  . Évalué à 3.

      M'enfin, une news openBSD sans un troll sur Linux, ce n'est pas une news openBSD.

      Comme un commentaire de ta part sans un troll ou de la mauvaise foi, c'est pas un commentaire de ta part... :)
    • [^] # Re: Prelink

      Posté par  (site web personnel) . Évalué à 3.

      >> Pipo. Prelink de Linux est compatible avec des adresses aléaloires.

      Dans l'interview O'Reilly que j'ai donné en lien on peut lire ceci :
      One of the significant security features in OpenBSD is address randomisation (aka ASLR). Prelinking as implemented in Linux removes the randomisation feature so it would not be compatible with OpenBSD's security goals.

      Donc soit c'est toi qui a raison soit c'est Dale Rahn (soit j'ai mal compris mais ça me semble une hypothèse inenvisageable ;-).
      • [^] # Re: Prelink

        Posté par  . Évalué à 3.

        Je dois reconnaitre que je n'y connais pas grand chose dans ces trucs, voire qu'ils m'ennuient.

        Plus haut, j'ai parlé de "compatibilité" et non dit que Linux le fournissait. Il y a Red Hat/Fedora qui fournit des fonctionnalités de "random address". Peut-être d'autre, je l'ignore.

        Si j'ai bien compris, les adresses aléatoires sont utilisées au chargement pour l'édition de lien et fixer le début de la pile. Une installation typique Fedora fait ça. De même par défaut prelink est installé et activé (prelink des applis toutes les nuits).
        L'adresse aléatoire de la pile n'implique pas prelink.
        Par contre prelink n'est pas utilisé si le chargement des librairies est mis à une adresse alétoire (c'est le cas par défaut pour pratiquement toute les applis) et/ou si c'est du code indépendant (qui peut-être logé n'importe où et pas seulement pour les librairies ; c'est aussi le cas par défaut depuis FC3 je crois).

        Bref, prelink est installé mais dans la majorité des cas non utilisé car "random addresse" est utilisé (ça ne concerne pas la pile).

        Quelques info sur ce qui est fait dans RHEL/Fedora : http://people.redhat.com/drepper/nonselsec.pdf

        > Donc soit c'est toi qui a raison soit c'est Dale Rahn

        J'ai tord.
        • [^] # Re: Prelink

          Posté par  . Évalué à 6.

          Plus haut, j'ai parlé de "compatibilité" et non dit que Linux le fournissait. Il y a Red Hat/Fedora qui fournit des fonctionnalités de "random address". Peut-être d'autre, je l'ignore.


          En fait, ça dépend de ce que tu appelles randomization.
          Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:

          exemple:


          #include <stdio.h>
          #include <stdlib.h>

          int main(void)
          {
          int n;
          int *c = malloc(sizeof(int));

          printf("Pile: %p\n", (void *) &n);
          printf("Tas: %p\n", (void *) c);

          return 0;
          }


          Sur mon noyau 2.6.17, j'obtiens ça:

          $ for i in `seq 1 10`; do ./test; done
          Pile: 0xbf85db6c
          Tas: 0x804a008
          Pile: 0xbf85735c
          Tas: 0x804a008
          Pile: 0xbfb3487c
          Tas: 0x804a008
          Pile: 0xbf87db7c
          Tas: 0x804a008
          Pile: 0xbf90640c
          Tas: 0x804a008
          Pile: 0xbfb9369c
          Tas: 0x804a008
          Pile: 0xbfea89ac
          Tas: 0x804a008
          Pile: 0xbf906c0c
          Tas: 0x804a008
          Pile: 0xbfcfd7fc
          Tas: 0x804a008
          Pile: 0xbfb0e60c
          Tas: 0x804a008


          Donc, il y a bien "randomizaton" au niveau de la pile (en fait, aussi au niveau des appels à mmap()), mais pas au niveau du tas.
          Mais faut pas croire que c'est la panacée: en effet, enfin la dernière fois que j'ai vérifié, la plage de randomization n'est pas énorme (64 kb pour la pile je crois). Quand tu enlèves les adresses quivontpas (alignement), bah en fait il te reste un ensemble assez restreint de valeurs, du coup rien ne t'empêche de faire une boucle au début de ton exploit.

          Pour en revenir à la randomization et prelink:

          http://lwn.net/Articles/121845/

          Kernel facilities supplying address space layout randomization for libraries cannot be used in conjunction with prelink; to do so would require relocating the libraries, defeating the purpose of prelinking.


          Quand tu y penses, c'est carrément logique.
          Néanmoins, voici ce qu'on peut lire:

          In an attempt to restore some of the benefits of address space randomization, prelink is capable of randomly selecting the addresses used for prelinking. This makes it more difficult to perform certain attacks on a system, because the addresses used are unique to that system. This approach is, however, less effective than per-process randomization because the addresses stay constant until prelink is run again.


          Voilà voilà.
          Enfin, je crois qu'on se retrouve toujours face au dilemme rapidité/sécurité. Entre les deux, il te faut choisir :-)
          • [^] # Re: Prelink

            Posté par  . Évalué à 3.

            Je suis pas réveillé, j'ai oublié un appel à free()...


            #include <stdio.h>
            #include <stdlib.h>

            int main(void)
            {
            int n;
            int *c = malloc(sizeof(int));

            printf("Pile: %p\n", (void *) &n);
            printf("Tas: %p\n", (void *) c);

            free(c);

            return 0;
            }


            P.S: on écrit "j'ai tort", et non pas "j'ai tord".
          • [^] # Re: Prelink

            Posté par  . Évalué à 1.

            Je sais.
            Et ton exemple (très parlant) est pour la pile/tas, non pour les adresses des fonctions.

            > Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:

            Regardes du côté de Fedora/Red Hat, il y a une randomization complète (avec exec-shield) mais ça ne marche pas pour prelink. Au chargement les adresses données par prelink sont ignorées (prelink est donc ignoré). On peut "réactivé" prelink mais les bibliothèques auront une adresse fixent (celles définis par prelink au moment de l'exécution de prelink).
            • [^] # Re: Prelink

              Posté par  . Évalué à 2.

              Et ton exemple (très parlant) est pour la pile/tas, non pour les adresses des fonctions.


              Oui. Mais comme je l'ai dit, ça s'applique aussi à mmap(), donc aux librairies dynamiques.

              Pour exec-shield, ça a l'air pas mal. Je ne comprends pas pourquoi Debian ne propose pas un noyau déjà patché (même si c'est désactivé par défaut), ce serait plus pratique que d'avoir à télécharger le patch, l'appliquer etc.
              Tiens, ce serait une bonne idée une version de noyau "serveur", avec un noyau durci.
              • [^] # Re: Prelink

                Posté par  . Évalué à 2.

                Ah, je retire ce que j'ai dit:


                #include <stdio.h>
                #include <stdlib.h>

                int main(void)
                {
                int n;
                int *c = malloc(sizeof(int));

                printf("Pile: %p\n", (void *) &n);
                printf("Tas: %p\n", (void *) c);
                printf("Librairies: %p\n", (void *) fopen);

                free(c);

                return 0;
                }


                Me renvoie:
                $ !for
                for i in `seq 1 10`; do ./test; done
                Pile: 0xbfaff69c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbffdf2ec
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbff3323c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbffedafc
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbfa6656c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbfe8398c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbfd2e03c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbff9b29c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbf99bc9c
                Tas: 0x804a008
                Librairies: 0x8048344
                Pile: 0xbf88cb8c
                Tas: 0x804a008
                Librairies: 0x8048344


                Bon, je sais que ce n'est pas ANSI de convertir un "function pointer" en "object pointer" (comment l'imprimer proprement?), mais n'empêche que ce n'est pas ce que j'attendais. Va falloir que je regarde ça de plus près, ça m'intrigue.
  • # question bete

    Posté par  . Évalué à 1.

    comment prononce t'on Theo de raadt ? (c'est une vrai question)

    j'aurais tendance a dire - téo de rate - mais sans grande conviction
    • [^] # Re: question bete

      Posté par  . Évalué à 1.

      Selon wikipedia ca serait "Théo de rote"
      http://fr.wikipedia.org/wiki/Theo_de_Raadt
  • # GNU RCS -> OpenRCS: pourquoi ?

    Posté par  . Évalué à 0.

    Pourquoi ont-ils de nouveau entrepris de refaire une version "Open" d'un outil GNU ?

    C'est une marque de fabrique ? Qu'est-ce qui les dérange dans la version GNU ?

    Ou bien c'est une question de principe: reprendre tout GNU et en faire un Open trucmuche ?
    • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

      Posté par  (site web personnel) . Évalué à 7.

      facile : les outils gnu sont pas sous licence BSD ...

      Selon théo : la licence GPL n'est pas libre a coté de la licence BSD qui est extrèmement permissive (proche du domaine publique). Bref dans un soucis d'avoir une distribution 100% BSD, les outils GNU sont refait petit a petit ce qui n est pas une mauvaise chose selon moi ...
      • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

        Posté par  . Évalué à -2.

        Mais en dehors de la simple question de licence, qu'y a-t-il vraiment de *mieux* pour le cas OpenRCS ?

        Est-ce vraiment "legal" dailleurs ? A-t-on jamais tenté de demander à la FSF ce qu'elle pensait de ces ré-écritures "sauvages" ?

        /me va se faire une joie de demander l'avis du guru.
        • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

          Posté par  . Évalué à 4.

          tiré de l'article O'reilly :
          GNU RCS has been replaced with OpenRCS. Who worked on it? What advantages does it provide over GNU RCS?

          Ray Lai: Joris Vink, Niall O'Higgins, Xavier Santolaria, and I worked on OpenRCS. It is compatible with GNU RCS, minus some missing functionality such as branch checkins. We hope to complete the missing functionality soon.
          The main advantage OpenRCS provides is security. Throughout its development we have kept security in mind, identifying insecure patterns and eliminating them. As a side effect, our code is clearer and simpler.
          Aside from that, our goal has mainly been compatibility with GNU RCS. Once this has been achieved, we may enhance OpenRCS with features, though we are more likely to work on enhancing OpenCVS.

          Et extrait de la manpage ( http://www.openbsd.org/cgi-bin/man.cgi?query=rcs&sektion(...) ) :
          The OpenRCS project is a BSD-licensed rewrite of the original Revision Control System.

          C'est autant pour améliorer RCS coté sécurité que pour se débarasser d'un autre outil GNU présent dans le système de base... Après ca, il faudra s'attaquer a OpenCVS, et après on se prend à rêver à OpenGCC et OpenHTTPD :) :)
          • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

            Posté par  . Évalué à 2.

            C'est autant pour améliorer RCS coté sécurité que pour se débarasser d'un autre outil GNU présent dans le système de base... Après ca, il faudra s'attaquer a OpenCVS

            C'est quoi l'intérêt de réécrire ces dinosaures obsolètes ?
            Aujourd'hui tout le monde passe graduellement à Subversion ou à un des systèmes de développement distribué (Mercurial, etc.), qui n'ont aucune dépendance à ma connaissance sur RCS/CVS.

            Faire du bon logiciel, c'est aussi savoir ne pas s'acharner sur des causes perdues ou dépassées.
            • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

              Posté par  (site web personnel) . Évalué à 2.

              Beaucoup de gens aime encore CVS et l'utilisent, c'est le cas de la plupart des projets BSD. Le problèmes de GNU CVS, c'est que plus personne ne travail ou presque dessus. Le but de OpenCVS est de fournir une alternative compatible CVS, orienté sécurité, qui sera maintenu, et auquel viendra s'adjoindre des nouvelles fonctionnalité quand le premier but sera atteint.
              La première brique est là : le remplacement de GNU RCS par OpenRCS.
              • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

                Posté par  . Évalué à 2.

                > Beaucoup de gens aime encore CVS et l'utilisent,

                L'utilise ok, mais de là a l'aimer a mon avis, ils sont pas si nombreux que ça!

                Le gros avantage de CVS c'est sa simplicité et en cas de problème, tu peux sortir vi et corriger le problème a la main dans les archives directement, le gros problème de CVS c'est que les problèmes arrivent un peu trop souvent, avec le commit non atomique notamment et qu'il est très limité.
            • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

              Posté par  . Évalué à 3.

              Il faut voir un peu plus loin avant de lancer des generalites comme "Faire du bon logiciel, c'est aussi savoir ne pas s'acharner sur des causes perdues ou dépassées."

              La problematique d'OpenBSD (le premier systeme d'exploitation a utiliser un repertoire CVS completement public pour la gestion des sources) est simple: son developpement repose sur un outil qui a ses limites tant en matiere de securite que de fonctionnalites (les fameux commit atomiques, possibilite de deplacer des repertoires).

              Comme d'habitude la reponse d'OpenBSD est pragmatique:

              1. implementer un jeu d'outils compatibles: en l'occurence reecriture de rcs et cvs
              2. apporter des nouvelles fonctionnalites

              sur le moyen terme (2 ou 3 releases) on devrait voir apparaitre des nouvelles fonctionnalites dans OpenCVS.

              Et au passage il faudrait lire les releases notes, parce qu'outre OpenRCS, de nombreux projets ont avance en parallele, bgpd et ospfd sont de plus en plus murs, ripd vient d'etre importes. hostapd, ipsecctl et sasyncd ont tous bien evolues...
              • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

                Posté par  . Évalué à 2.

                [...] un outil qui a ses limites tant en matiere de securite que de fonctionnalites (les fameux commit atomiques, possibilite de deplacer des repertoires).
                Comme d'habitude la reponse d'OpenBSD est pragmatique:

                La réponse pragmatique est d'abandonner CVS et de passer à Subversion, qui est le standard remplaçant et corrige les problèmes sus-cités (entre autres). Sans compter que Subversion est capable de réutiliser des protocoles existants (HTTP/HTTPS) au lieu d'une bidouille ad-hoc comme pserver.

                Au contraire, vouloir réimplémenter ce genre d'améliorations en gardant l'infrastructure archaïque de CVS (tu as vu à quoi ressemble le format de stockage ?), c'est clairement aller dans une impasse. Et réécrire un machin obsolète graduellement abandonné par les utilisateurs, c'est pas vraiment "pragmatique". Ils réécrivent Tcl-Tk aussi ?
        • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

          Posté par  (site web personnel) . Évalué à 1.

          Que ces alternatives aux outils GNU soit mieux ou moins bien n'est pas le plus important. Ce qui importe c'est d'avoir le choix dans la liberté. Peut être qu'un jour à côté des GNU/BSD on aura des BSD/Linux et même pourquoi pas un BSD/Hurd ....
          Chaque alternative offrira toujours un avantage (à moins qu'elle soit programmé avec les pieds).

          Et pour la question : est ce illégal ?

          RMS n'a pas inventer Unix avec GNU et la FSF donc tu as le droit de programmer des outils pour un système d'exploitation sous la licence que tu veux et qui font ce que tu veux. Crois tu vraiment que bash ou gcc soit illégal parce qu'ils font la même chose que des outils concurant ?

          Si toute alternative devient illégal à ton sens alors je pense que tu devrai reconsidérer ta vision du monde ...
        • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

          Posté par  . Évalué à 1.

          Est-ce vraiment "legal" dailleurs ? A-t-on jamais tenté de demander à la FSF ce qu'elle pensait de ces ré-écritures "sauvages" ?

          Au moins en France, oui, c'est légal. On entre là dans un pendant du débat sur les brevets logiciels. Pour faire simple (voire simpliste), un logiciel se décompose en:
          - une idée (cahier des charges)
          - une implémentation (le code source)

          Le code source relève du droit d'auteur. On ne peut pas le copier ni le modifier sauf mention explicite de l'auteur (ce qui se fait en général via les termes de licence... GPL, BSD, Apache...)

          L'idée appartient à tout le monde. Tout le monde a le droit de créer un logiciel reprenant des fonctions similaires à un autre logiciel. Par exemple, OpenOffice.org reprend des fonctonnalités qui existaient auparavant dans MS Office. Ou PostrgreSQL reprend des fonctionnalités qui existaient en Oracle.
      • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

        Posté par  . Évalué à 3.

        > la licence GPL n'est pas libre a coté de la licence BSD

        La liberté ça se défend. C'est le sens des exigences de la GPL.
    • [^] # Re: GNU RCS -> OpenRCS: pourquoi ?

      Posté par  . Évalué à 3.

      J'ai la flemme de rechercher les liens sur les mails de l'époque (mais tu trouvera un apperçu sur http://opencvs.org/ ), mais en gros : parce qu'ils ont besoin de cvs (et rcs) pour leurs dépôts, et qu'ils se sont aperçus que le code était très moche et pas forcément facile à maintenir et sécuriser.

      Ce qui se devine facilement :

      s2t0c$ find /usr/src/gnu/usr.bin/cvs/ -type f -name '*.c' | xargs wc -l | tail -1
      102145 total
      ( plus 11 000 lignes de headers, 24 000 lignes de shell script etc.).

      À cette époque (et même depuis lors), GNU CVS a mangé quelques râteaux, en matière de sécu.
  • # Et aussi, sortie de OpenBGPD 4.0

    Posté par  . Évalué à 5.

    Comme OpenSSH, le serveur de routage BGP OpenBGPD est maintenu par OpenBSD et releasé ponctuellement sous la forme "portable" (emballé pour être plus pratique à compiler sur d'autres systèmes). : http://www.openbgpd.org/

    Et bien ce bougre d'OpenBGPD est sorti le même jour, avec tout un tas de nouvelles fonctionnalités qui sont indiquées ici :
    http://undeadly.org/cgi?action=article&sid=2006110115435(...) .

    Certains développeurs d'OpenBSD travaillent en effet activement au développement de toute une batterie de serveurs de routage : on a déjà, au menu, un serveur BGP (celui dont je parle), un serveur OSPF (OpenOSPFD), un serveur dvmrp/IGMP (dvmrpd), et tout récemment un serveur RIP (ripd, qui devrai remplacer avantageusement le vieux routed).

    Quant à l'annonce de la release d'OpenBSD, dommage qu'elle passe sous silence les énormes progrès d'ipsecctl(8), un outil à la configuration super simple et ergonomique qui paramètre la pile IPsec du noyau et le serveur de clef ISAKMPD (lequel a une conf à la syntaxe plus tortueuse, mais qu'on a plus besoin d'écrire soi-même, grâce à ipsecctl).
  • # Version cohérente...

    Posté par  (Mastodon) . Évalué à 1.

    Ha ! Enfin des gens qui ont compris qu'après 3.9, c'est 4.0 et pas 3.10 :) Voilà une numérotation cohérente.

    J'ai toujours été étonné par les x.10 après les x.9, c'est illogique au possible et quand on navigue dans un répertoire, ça casse l'ordre naturel des versions. Ou alors, il faudrait faire x.09, ça serait cohérent. Donc merci à OpenBSD de montrer la voie (comme toujours) !
    • [^] # Re: Version cohérente...

      Posté par  . Évalué à 3.

      Non, après 3.9 vient 3.A, en toute logique. Ce qui permet d'ailleurs de préserver l'ordre lexicographique (x.9 < x.A, contrairement à x.9 > x.10).

      Une autre solution consiste à préfixer par une lettre, pour pouvoir continuer à utiliser .10 et garder l'ordre lexicographique, c'est ce qu'a fait HP-UX avec les version 8.*, puis A.9.*, puis B.10.*.

Suivre le flux des commentaires

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