Journal Fork de CVS

Posté par  (site web personnel) .
Étiquettes : aucune
0
16
déc.
2004
Il semble que le projet OpenBSD est un peu fatigué des failles et des alertes de sécurité du projet CVS.
Un fork est donc mis en place qui a pour but de rester aussi proche que possible de la version officielle tout en ayant constamment à l'esprit la sécurité (leitmotiv d'OpenBSD).

extrait du site :
Etre le plus sécurisé possible. Coder méticuleusement, contrôler strictement la validité des données, en particulier sur le chemin d'entrée réseau, et réaliser des opérations sur des mémoires tampons bornées. Se servir de la séparation des privilèges pour amoindrir l'impact d'un possible bogue de sécurité.

Par contre ce qui est vraiment bizarre c'est que la licence de ce nouveau OpenCVS est la BSD !
Il me semble pourtant que CVS est sous GPL non ?
Si c'est le cas alors c'est une réécriture complète du logiciel ?


l'URL du site : http://www.opencvs.org/fr/index.html(...)

  • # Pour la licence :

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

    C'est une ré-écriture (et non un fork)

    • [^] # Re: Pour la licence :

      Posté par  . Évalué à 10.

      Quel interet de reecrire CVS alors que Subversion et Arch sont a des annes-lumieres de cet ancetre ?
      Arch notemment risque beaucoup moins d'avoir des problemes de securite car il n'a pas besoin de serveur specifique, toute l'information se trouve dans une arborescence, on peut reutiliser des solutions prouvees comme FTP/HTTP webdav/SSH sftp/.. comme l'on veut.

      • [^] # Re: Pour la licence :

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

        Parce que Subversion et Arch ne sont pas CVS. Beaucoup (beaucoup) de monde utilise encore CVS, et migrer n'est jamais très aisé.
        Enfin, Subversion et Arch sont des solutions différentes de CVS et beaucoup sont très contents de CVS.

        • [^] # Re: Pour la licence :

          Posté par  . Évalué à 1.

          Bon dans ce cas, je m'en vais reecrire OpenCDE, certes ca va me prendre quelques annees a reimplementer ce truc vieux et moche, certes KDE et Gnome sont utilisables MAINTENANT et sont largement meilleurs, mais il y a deux/trois trucs que je n'aime pas dans Gnome et KDE (le splashscreen par defaut, l'ordre des boutons, ...)

          Ca ne serait pas plus intelligent/plus rapide/moins fatiguant de corriger les deux/trois trucs que je n'aime pas dans Arch/Subversion ? Ah oui, mais j'ai ma liberte de faire n'importe quoi, il ne faut pas l'oublier.

          -1 pour moi pour ton pretentieux,
          mais je ne comprends pas OpenBSD.

          • [^] # Re: Pour la licence :

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

            le truc, c'est qu'ils ne veulent forcer un changement de système, si les developpeurs ont l'habitude d'utiliser cvs. Ce serveur opencvs est codé pour eux et par eux, ils n'ont (et ne ressentent) peut-être pas le besoin des fonctions supplémentaires de Arch ou Subversion. Peut-être que pour eux, le plus important est qu'ils aient codés le truc, qu'ils le maitrisent et donc qu'ils l'auditeront plus facilement. Qu'est-ce que ça peut te faire s'ils le font pour eux-même de toute façon ?

          • [^] # Re: Pour la licence :

            Posté par  . Évalué à 10.

            Aujourd'hui et pour encore quelques années CVS c'est vieux mais c'est supporté.

            Malgré tout le bien qu'on peut penser d'arch/svn/autre actuellement leur support dans les outils de developpement est plus que limité voir totalement inexistant pour arch (et tla c'est un peu beaucoup tres relou a utiliser d'ailleur).

            Actuellement les avantages de CVS c'est :

            Tres simple à mettre en oeuvre (subversion est aussi facile) de la doc partout, sur tout, sous tout système.

            Tellement basique qu'on peut commencer a l'utiliser en 1h alors qu'il faut compter 2 jours rien que pour comprendre comment fonctionne arch en mode decentralisé

            Et surtout integration dans TOUT les outils de developpement. Subversion commence a être supporté, sous Jbuilder 2005 par exemple, le plugin eclipse est pour le moment très limité (JNI, pas de ssh toussa). Pour svn tu as trac qui est bien entre autre pour le cvsweb. Pour arch y'a rien du tout a ma connaissance. Il n'y a pas que l'outil lui même mais tout ce qui tourne autours.

            Bref CVS est pour encore la pour un moment et aussi par ce qu'une migration coute tres cher, ca demande une phase de validation monstrueuse et le temps que tout les developpeurs assimilent le nouveau système. Chez FreeBSD des gens reflechissent à passer a subversion depuis 18 mois et il me semble que c'est toujours pas concluant...

            Donc ce n'est peut etre pas aussi stupide que ca...

            • [^] # Re: Pour la licence :

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

              Arch est peut-être jeune, mais de là à dire qu'il n'y a rien autour... Il suffit de regarder sur le wiki de arch/tla pour s'en rendre compte :
              http://wiki.gnuarch.org/moin.cgi/GUI_20Front_2dends(...)
              http://wiki.gnuarch.org/moin.cgi/Arch_20Revision_20Browsers(...)
              http://wiki.gnuarch.org/moin.cgi/Additional_20Tools(...)

              Sinon, pour les autres remarques :
              "CVS c'est tres simple à mettre en oeuvre", ça, c'est tout à fait subjectif ; et pour ma part, je ne le trouve pas simple du tout. CVS offre tous les outils nécessaires à la gestion de version, mais conceptuellement, il n'est pas évident d'expliquer son fonctionnement. Pour subversion, c'est le déploiement qui n'est pas évident (dépendances conséquentes).

              "ca demande une phase de validation monstrueuse"
              Plus que pour le passage d'un noyau 2.4 à un 2.6 ?

              "ca demande le temps que tout les developpeurs assimilent le nouveau système"
              Y'a au moins une passerelle Arch <=> CVS (voir dans les liens au dessus). Ca devrait contenter les plus pressés.

              • [^] # Re: Pour la licence :

                Posté par  . Évalué à 9.

                > Arch est peut-être jeune, mais de là à dire qu'il n'y a rien autour...

                Tu ne fais que confirmer la chose. Hormis xtla qui semble bien reste 4 outils qui se battent en duel. C'est exactement ce que je disais.

                > ça, c'est tout à fait subjectif ; et pour ma part, je ne le trouve pas simple du tout. 


                
echo "gpg --clearsign --default-key XXXXXX" > "~/.arch-params/signing/=default" 
                
tla my-id "Poulpe Maintainer <poulpe@xxxx.ath.cx>"                            
                
tla make-archive -l -s poulpe@xxxx.ath.cx--2004 /home/poulpe/2004             
                
tla my-default-archive poulpe@xxxxx.ath.cx--2004                                
                
tla archive-setup poulpe--integration--0.8 
                
wget http://ovh.dl.sourceforge.net/sourceforge/poulpe/poulpe-0.7.tar.gz(...)         
                
tar xvfz poulpe-0.7.tar.gz 
                
cd poulpe-0.7 
                
tla init-tree poulpe@loutre.ath.cx--2004/poulpe--integration--0.8              
                
tla add *(^/) man/* src/* man src  
                
tla make-log                                                                      
                
vim ./++log.poulpe--integration--0.8--poulpe@xxxxx.ath.cx--2004
                
tla import


                voila t'as créé la branche officielle maintenant il te faut ta branche que tu vas tagger sur la branche officielle; comprendre comment remonter les changesets et je dois en oublier.

                J'ai deja vu plus simple.

                Arch est extrement puissant mais faut être honnete il est très difficile à maitriser et demande un investissement de temps considérable. J'ai croisé plus d'une personne qui s'était cassé les dents à mettre le système réellement en "production" autre que pour son petit repo quoi. Et personellement j'ai passé 3 journées à avoir un truc qui marche et que je maitrise.

                > Plus que pour le passage d'un noyau 2.4 à un 2.6 ?

                Tu es une boite (ou un gros projet) tu as 100 developpeurs, 10 ans d'historique. Tu décides de changer, tu penses pas que la migration est énorme et que la moindre erreur va faire très mal ? Et que de toute facon ca va forcement avoir un cout au mieux les utilisateurs ne seront pas habitué au système.

                > Y'a au moins une passerelle Arch <=> CVS

                Tu parles de cvsv ?
                "BE YE WARNED! There are severe bugs in CSCVS right now. They affect ..."

                Autrement y'a tla-cvs-sync qui pourri ta base arch avec les commits cvs sans changeset

                Il existe mieux ? Ca ne me semble pas être une veritable solution puisque à la base CVS et arch ne comprennent pas les mêmes notions...

            • [^] # Re: Pour la licence :

              Posté par  . Évalué à 2.

              Bon, la question à trois francs: Une migration de CVS vers le OpenCVS serait-elle indolore (càd. que ce soit l'un ou l'autre, l'utilisateur ne voit aucune différence)?

          • [^] # Re: Pour la licence :

            Posté par  . Évalué à 5.

            Un exemple de ce qui est dit plus haut (je sais pas si c'est pareil sur OpenBSD ou pas), Gentoo tourne sous CVS, et on est loin de vouloir le changer. Tous les outils de Portage ont intégré CVS, s'il fallait faire un changement CVS -> arch/subversion il faudrait :
            * changer le serveur CVS pour un serveur arch/subversion. Bon, admettons, c'est pas forcément le plus dur
            * changer tous les scripts de dépôt de CVS, de vérification etc. pour qu'ils supportent au moins un temps les deux serveurs (on change pas de manière brutale comme ça...) puis tout passer à arch/subversion. Ce qui implique un certain travail.
            * tous les développeurs doivent passer à arch/subversion. Et se re-former à un nouveau système. C'est pas forcément le point le plus facile. Certains se sont fait des petits outils pour se simplifier la vie, utilisant CVS, ils devront tout refaire. Perte de motivation, etc. seraient à prévoir.
            * il faut changer toutes les documentations parlant de CVS.
            En outre, le serveur CVS marche très bien, je n'ai pas vu de mécontentement majeur. Pourquoi changer quelque chose qui marche par quelque chose qui "marcherait mieux" mais "impliquerait un surcroit de travail, sans être sûr d'obtenir effectivement une amélioration justifiant le changement" ?

            C'est une des politiques de Postfix par exemple : garder une compatibilité la plus grande possible avec sendmail, pour pouvoir a priori passer en douceur de sendmail à postfix. Passer de cvs à arch/subversion n'est pas forcément aussi doux.

          • [^] # Re: Pour la licence :

            Posté par  . Évalué à 1.

            sauf que CDE, tout le monde s'en fout :)

      • [^] # Re: Pour la licence :

        Posté par  . Évalué à 4.

        Outre la licence, la motivation de ce fork est aussi que le dev de CVS ralentit de jour en jour. Les fixes prennent plus de temps a etre integres. OpenBSD prend donc ses distances avec CVS et ne sera plus dependant d'une autre team, au prix de dizaines d'heure de code. On est jamais mieux servi que par soit meme.

      • [^] # Re: Pour la licence :

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

        moins d'avoir des problemes de securite

        Oui....

        solutions prouvees comme FTP/HTTP webdav/SSH sftp/..

        Avec un tel bordel, boujour les soucis de sécurité.

        • [^] # Re: Pour la licence :

          Posté par  . Évalué à 2.

          Tel bordel ? Tu fais semblant de ne pas comprendre ?

          ARCH n'a pas besoin d'un service proprietaire particulier pour acceder au repository. Tu peux utiliser n'importe quel protocole qui permet de copier des fichiers a ta convenance, tu n'as besoin de rien en particulier. Par exemple il suffit d'avoir un acces SFTP pour les developpeurs (en ecriture) et un acces HTTP (en lecture) pour tes utilisateurs.

          Je passe sur le fait que tu peux te faire un mirroir local pour continuer a beneficier des services de ARCH sur un portable deconnecte du reseau.

  • # openntp

    Posté par  . Évalué à 6.

    pour reprendre un lien de slashdot, j'espere que leur implementation sera plus aboutie que celle de openntp : http://bradknowles.typepad.com/considered_harmful/2004/09/openntpd.(...)

    • [^] # Re: openntp

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

      Tout dépend de ce que l'on veut. Ils ont répondu à ces critiques dans la FaQ de openntp :

      6.12.1 - "But OpenNTPD isn't as accurate as the ntp.org daemon!"
      That may be true. That wasn't OpenNTPD's design goal, it was intended to be free, simple, reliable and secure. If you really need microsecond precision more than the benefits of OpenNTPD, feel free to use ntp.org's ntpd, as it will remain available through ports and packages. There is no plan or desire to have OpenNTPD bloated with every imaginable feature.
      6.12.2 - "Someone has claimed that OpenNTPD is 'harmful'!"
      That would probably be Brad Knowles. If accurate time keeping is important, a number of users have reported better results from OpenNTPD than from ntp.org's ntpd. If security is important, OpenNTPD's code is much more readable (and thus, auditable) and was written using native OpenBSD function calls like strlcpy, rather than more portable functions like strcpy, and written to be secure from the beginning, not "made secure later". If having as many people using time synchronization is valuable, OpenNTPD makes it much easier for larger numbers of people to use it. If this is "harmful", we are all for it.

      There are almost certainly applications where the ntp.org ntpd is more appropriate, however it is felt that for the other 95% of the users, OpenNTPD is more than sufficient.

      Bref 2 outils différents pour 2 besoins différents. J'ai lus les critiques de Brad Knowles, et je vois peu de problèmes critiques. Son principal délire, c'est qu'il faudrait avoir l'heure à la nano seconde près dans les logs au cas ou on devrait donner des preuves d'une intrusion devant un tribunal.

      • [^] # Re: openntp

        Posté par  . Évalué à 4.

        donc comme il le dit c'est pas le protocole ntp qu'ils ont implemente, mais plutot du sntp...

        • [^] # Re: openntp

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

          ouais.

          Bref, le problème n'est pas vraiment important, c'est surtout que ça n'a pas été très explicite dès le départ. ça ne veut pas dire que openntpd est mauvais.

          • [^] # Re: openntp

            Posté par  . Évalué à 1.

            > le problème n'est pas vraiment important

            Un peu.
            Actuellement un cracker peut changer la date d'une machine à distance. Et comme cette machine est un serveur de temps => catastrophe chez tous les clients.

            • [^] # Re: openntp

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

              c'est pas *toujours* une catastrophe. Que je sache, une horloge qui se dérègle sur une machine desktop, ça n'a rien de dramatique. la FAQ de openntpd est claire : si on veut les features de ntpv4, on utilise un ntpd conforme à ntpd v3 et v4 disponible depuis les ports. Pour quelqu'un qui veut juste que ses pc soient à l'heure à la maison, openntpd va très bien.

              • [^] # Re: openntp

                Posté par  . Évalué à 1.

                > c'est pas *toujours* une catastrophe

                Pas toujours mais c'est presque une catastrophe assuré.
                Les caches déconnent, les bases de données qui stockent l'heure déconne, les fichiers créés avec les dates déconnes, etc.
                C'est un bien gros risque pour un tout petit gain en sécurité apporté par OpenNTPd.

                > Pour quelqu'un qui veut juste que ses pc soient à l'heure à la maison, openntpd va très bien.

                OpenBSD à la maison...

                • [^] # Re: openntp

                  Posté par  . Évalué à 3.

                  Linux a la maison ....

                  • [^] # Re: openntp

                    Posté par  . Évalué à -3.

                    Ici ça le fait.
                    J'ai la tv, je l'enregistre.
                    Je visualise des vidéos (dvd). J'ai le driver mga_vid et ça consomme rien en cpu (surtout il ne passe pas par X11 pour l'affichage et donc aucun accro même s'il y a d'autre affichage; je peux scroller les pages web sans soucis par exemple).

                    Le point noir, c'est les jeux. Mais je ne joues pas.
                    Il y a aussi drm/dri sous Linux pour les "gamers".

                    Donc Linux à la maison, c'est plus que possible et c'est correct. Sauf pour les jeux.

                • [^] # Re: openntp

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


                  > Pour quelqu'un qui veut juste que ses pc soient à l'heure à la maison, openntpd va très bien.

                  OpenBSD à la maison...

                  ben oui. ma connection est partagée par une machine openbsd "à la maison" qui me permet de faire un vpn avec une machine connectée en wireless et qui héberge un serveur web. C'est une utilisation typique d'openbsd (parmi d'autres).

                  Au cas ou t'aurais pas suivi, on parle d'un serveur ntp, après tu y synchronise les machines que tu veux, win, mac , linux...

                  • [^] # Re: openntp

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

                    j'ai mal formulé c'est la machine openbsd qui a un serveur web, pas la machine wireless.

  • # Les rebelles d'OpenBSD

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

    Il me semble que le team OpenBSD est assez coutumier du fait (ils veulent leurs outils).
    Par exemple il me semble que la version Apache présente est une version 1.3 tunée et modifiée à leur sauce (Theo, le boss d'OpenBSD, n'aime pas du tout la version 2.0 d'Apache).

    D'un autre coté quand on voit que leur serveur de mail officiel est toujours Sendmail.....

    • [^] # Re: Les rebelles d'OpenBSD

      Posté par  . Évalué à 7.

      Ce n'est pas la version 2 qu'ils aiment pas, c'est la licence de la version 2.

      • [^] # Re: Les rebelles d'OpenBSD

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

        il me semble que c'est les deux.
        j'ai trouvé ça après une courte recherche : we will not import unfree software like newer apache releases, and for sure no unfree design fault like apache2.

    • [^] # Re: Les rebelles d'OpenBSD

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

      D'un autre coté quand on voit que leur serveur de mail officiel est toujours Sendmail.....

      Je pense qu'il reste le serveur officiel pour les admins qui en ont l'habitude. Par ailleurs, ils auditent le code de la branche officielle et la configuration par défaut ne permet que d'envoyer des mails depuis localhost. Je pense qu'ils partent du principe qu'un administrateur mail choisira de toute façon son serveur préféré et le configurera lui-même. Dans ce cas la, le serveur mail "officiel" ne pose pas de problème.

      • [^] # Re: Les rebelles d'OpenBSD

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

        Je pense qu'ils partent du principe qu'un administrateur mail choisira de toute façon son serveur préféré

        Ben oui mais alors on perd le principal argument d'OpenBSD qui est la cohérence et la sécurité.
        Si on évite de se servir des outils fournis officielement et qu'on ajoute à tout va des trucs de bric et de broc alors à quoi sert d'utiliser un OS super secure ?
        Leur argument imparable c'est que de base leur système est sécurisé....alors pourquoi ne pas choisir un soft concu de base avec la sécurité en tête comme exim ou postfix ?


        Je pense que le choix de sendmail fait tâche dans le paysage.

        • [^] # Re: Les rebelles d'OpenBSD

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

          ben pour quoi crois-tu qu'ils ont créé un système de ports et de packages si on n'a plus le droit de s'écarter de la base ;)

          Sinon pour sendmail y'a d'autres critères qui ont été pris en compte, comme la licence de Postfix que Theo De Raadt juge pas assez libre, plus ou moins pour la même raison qu'il ne veut plus de la licence de apache (clauses sur les brevets, etc) :
          mail de Theo de Raadt
          http://www.monkey.org/openbsd/archive/misc/0306/msg00711.html(...)

          Interprétation de la FSF :
          IBM Public License, Version 1.0
          This is a free software license but it is incompatible with the GPL.

          The IBM Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL.

          For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

          lien vers la licence :
          http://oss.software.ibm.com/developerworks/opensource/license10.htm(...)

          Pour exim, je ne sais pas ce qui les dérange, sûrement à cause de la licence GPL (ils virent tout ce qui est GPL quand c'est possible). D'autre part j'ai entendu (mais c'est peut-être très velu, je n'utilise pas exim moi-même) des personnes dire en général d'exim (en dehors du contexte openbsd) qu'il n'est pas terrible pour un serveur qui sert un gros volume.

        • [^] # Re: Les rebelles d'OpenBSD

          Posté par  . Évalué à 3.

          De ce que j'en ai compris, chez OpenBSD, ils ne considèrent pas Sendmail comme pas sécurisé, tout bêtement : il faut juste savoir le configurer correctement.

          (je ne fais pas de jugement de valeur quant à cette affirmation)

    • [^] # Re: Les rebelles d'OpenBSD

      Posté par  . Évalué à 2.

      ils veulent des outils fiables et en qui ils peuvent avoir confiance, pour se consacrer à leur tache première.

      si le fournisseur en face se met à polioter et faire n'importe quoi, normal qu'ils réagissent.

  • # en attendant...

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

    OpenCVS disponible bientôt.

    J'ai bien l'impression que le site n'a pas trop bougé depuis un ou deux mois. Pour le moment, il n'y a pas le moindre bout de code facilement disponible. Dans les semaines qui viennent, je vais avoir à mettre en place un CVS (ou outil équivalent) au bouch^W^Wlot, Et je ne vais sûrement pas partir dans ce truc là... Dommage, mais j'ai des thons en stock.

    • [^] # Re: en attendant...

      Posté par  . Évalué à 6.

      au bouch^W^Wlot
      Chez moi (tout du moins via les outils que j'utilise) ^W efface le dernier mot et non la dernière lettre ( je suppose que tu voulais dire boulot).
      Juste pour info et culture personnelle, peux tu me dire sous quel shell/éditeur/je ne sais quoi, cette commande efface la dernière lettre. (A moins qu'il ne s'agisse de geek attitude un peu foirée bien-sûr).

    • [^] # Une référence ?

      Posté par  . Évalué à 2.

      le site n'a pas trop bougé depuis un ou deux mois
      D'après le reste de ton post, tu parles du site mais également de l'avancée du projet OpenCVS.
      Il se peut que je dise une grosse bétise mais OpenCVS semble être assez actif, tout du moins d'après ce que je comprends de cette page http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/?sortby=date(...)
      Tes impressions sont-elles consultables?

    • [^] # Re: en attendant...

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

      Several readers have written in to mention that OpenCVS has recently hit the OpenBSD tree. Current plans are to keep what's good about cvs, fix the rest, and then start adding goodies. The first major goal is to be a drop-in replacement for GNU cvs. Please read the README for caveats, and any gotchas.

      http://undeadly.org/cgi?action=article&sid=20041216161833(...)

      • [^] # Re: en attendant...

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

        Current plans are to keep what's good about cvs

        comment ils peuvent keeper un truc alors que du fait du problème de licence ils doivent tout réécrire ?
        ce qu'ils veulent dire c'est : on va tout refaire à l'identique puis ensuite on va ajouter des trucs cools...

        • [^] # Re: en attendant...

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


          comment ils peuvent keeper un truc alors que du fait du problème de licence ils doivent tout réécrire ?

          ils parlent des fonctionnalités, pas du code.

Suivre le flux des commentaires

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