Dans une présentation informative et de bon goût, Bob Beck fait le point sur les raisons qui ont poussé les développeurs OpenBSD à débuter le nettoyage complet du code d'OpenSSL sous le nom de LibreSSL:
http://www.openbsd.org/papers/bsdcan14-libressl/
On y apprend, entre autres:
- Que la goute qui a fait déborder le vase n'était pas Heartbleed mais le remplacement pourri de malloc().
- Que la fondation OpenSSL est une organisation à but lucratif qui génère des gains de l'ordre du million de dollars par an en tant que consultants FIPS (le standard federal US pour les communications).
- Que les développeurs OpenBSD ont été les premiers à militariser la police Comic Sans.
- Que les développeurs OpenSSL ont l'air plus intéressés par l'ajout de nouvelles fonctionnalités que par les corrections de bugs, avec des rapports de bus qui traînent sur leur tracker depuis des années.
Dans l'ensemble, la présentation est très intéressante et permet de comprendre comment on a pu en arriver là (une bibliothèque de sécurité massivement utilisée mais dont le code est horrible et personne qui n'ose y toucher malgré le fait qu'elle soit open source). Une situation qui prend un peu à revers la théorie selon laquelle l'open source apporte plus de contributeurs et un code de meilleure qualité.
# Sentiment personnel
Posté par cosmocat . Évalué à 10.
Mon sentiment, c'est que cela s'applique quand le contributeur a un besoin spécifique. C'est pourquoi ce principe marche plutôt bien quand le contributeur a besoin d'une fonctionnalité qui n'est pas présente.
Pour certains logiciels, la performance est un besoin important donc pour certains logiciels (peu nombreux), il y a des contributions en terme d'amélioration des performances.
En ce qui concerne la sécurité, cela a toujours été le parent pauvre du logiciel. Quand on voit que même les sociétés dont les données et le business est basé sur la sécurité font peu d'effort, on comprends vite que les contributions doivent être faibles.
Mais c'est en effet ironique que cet effet s'applique sur un logiciel dont la sécurité est en fait son propre but…
# Mouais ... (titre un peu pourri parce qu'il en faut un ...)
Posté par totof2000 . Évalué à 10.
Ca ne prend pas cette théorie forcément à revers. Celà dit je n'ai jamais entendu dire que " l'open source apporte plus de contributeurs". Sinon, par rapport à la qualité dans le cas ou le code n'est pas disponible, les développeurs OpenBSD n'auraient pas pu nettoyer le code, ils auraient été contraints de reprendre de zéro. Maintenant il est clair que ce n'est pas parce que le code est disponible que tout le monde va s'y pencher automatiquement (il y a tellement de code disponible dans le monde …) mais il est effectivement surprenant que personne ne se soit intéressé à OpenSSL alors qu'il s'agit d'un code sensible.
Le fait que personne n'ait osé toucher à OpenSSL est peut-être du au fait que personne n'a voulu assumer la casquette de "celui qui a planté OpenSSL en le patchant mal".
[^] # Re: Mouais ... (titre un peu pourri parce qu'il en faut un ...)
Posté par Albert_ . Évalué à 5.
Celà dit je n'ai jamais entendu dire que " l'open source apporte plus de contributeurs".
Si tu rajoutes le mot "volontaire" c'est sur et certain que l'open source apporte plus de contributeurs vu que le closed source c'est impossible de contribuer de cette facon la. Apres si l'on parle de personne paye et qui ont ete mis sur un projet c'est forcement different.
# l'open source
Posté par cram51 . Évalué à 10.
Pas tant que ca puisque une deuxième équipe vient de décider de faire le ménage du code justement. En gros, de nouveaux contributeurs nous promettent un code de meilleur qualité.
Avec une licence non-libre et/ou un code fermé, la situation serrait resté tel quel.
[^] # Re: l'open source
Posté par ckiller . Évalué à -5.
Ok, mais qui ira vérifier le travail de la seconde équipe ?
En tant qu'utilisateur lambda, tu es obligé de faire confiance à des inconnus. Pour un truc aussi critique d'une lib comme *SSL, les gars te disent: "on va faire mieux", mais les garanties sont bien faibles.
Si cela se trouve, le fork a été initié par la mafia russe qui va y introduire des failles :-D
Donc, ce fork va-t-il apporté plus de sécurité ? Il n'y a rien de certain.
[^] # Re: l'open source
Posté par totof2000 . Évalué à 1.
C'est comme tout, il s'agit d'une question de confiance basée sur la réputation. Celà n'a rien à voir avec open ou closed source.
[^] # Re: l'open source
Posté par Miod in the middle . Évalué à 6.
Merde, grillé… (mais tu t'es trompé en ce qui concerne le pays)
[^] # Re: l'open source
Posté par AgentSteel (site web personnel) . Évalué à 7.
encore un coup de la mafia auvergnate :)
[^] # Re: l'open source
Posté par patate . Évalué à 5.
Bon, puisque c'est surtout la dernière phrase qui fait réagir, quelques explications: je pensais en particulier à l'aphorisme selon lequel si on a assez d'yeux, tous les bugs deviennent évidents. Pour moi le corollaire non formulé est que l'open source est censé amener assez d'yeux.
Et surtout, le fait qu'un logiciel aussi critique que OpenSSL ait pu traîner avec cette qualité de code aussi longtemps sans être repris me semble vraiment surprenant.
Cela dit, la présentation est vraiment très intéressante et vaut vraiment le coup d'oeil.
# mythe et mite pour ermite.
Posté par ckiller . Évalué à 10.
Perso, j'y ai jamais cru à ce mythe. Il y a des bons et des mauvais codeurs, dans les 2 mondes.
Mais le cas de LibreSSL est un bon exemple de la supériorité du Logiciel Libre sur le modèle privateur. Le fait de laisser la possibilité de reprendre son destin entre ses mains.
[^] # Re: mythe et mite pour ermite.
Posté par Nitchevo (site web personnel) . Évalué à 5.
Je n'ai pas repris mon destin, j'en suis en outre bien incapable, c'est juste qu'une équipe va tenter de reprendre mon destin entre ses mains, que, de réputation, je suppose propre.
Bref la technique implique que je fasse confiance à des tiers et comme le disait RMS, dans un autre contexte, un tiers de confiance est quelqu'un qui est susceptible de trahir notre confiance.
L'ambiance d'internet, depuis les révélations de Snowden s'est particulièrement dégradée et la joyeuse insouciance semble appartenir à une autre époque: nous ne pouvons plus conserver une confiance absolue dans les techniques de chiffrement et nous devons nous poser la question de savoir si nous pouvons conserver une confiance suffisante. Cette question n'a pas de réponse simple: elle dépend de notre utilisation à un moment donné.
Un fork de openssl est, compte-tenu du contexte une bonne chose, mais ce logiciel va-t'il être implanté sur les serveurs? Dans les navigateurs? Quand?
[^] # Re: mythe et mite pour ermite.
Posté par barmic . Évalué à 5.
Il est fort probable qu'ils ne cassent pas la compatibilité avec OpenSSL ou s'ils le font qu'ils le fassent le moins possible, ils ont eux aussi du code qui utilisent OpenSSL et qu'ils doivent maintenir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mythe et mite pour ermite.
Posté par barmic . Évalué à 8.
En fait il faut distribuer la confiance pour supprimer le single point of faillure. Ça peut se faire au sein d'une équipe avec des revus de code (comme c'est fait avec linux (pas forcément pour la sécurité)) ou à d'autres niveau (la linux fondation à veut faire de la relecture d'OpenSSL je crois avec Google, MS et d'autres qui financent) ça peut aussi être les distributions qui augmentent leur processus de vérifications (comme le projet débile pour lancer de l'analyse statique de code sur les paquets Debian ou litian qui augmente ses vérifications).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mythe et mite pour ermite.
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
J’aurai bien mis des guillemets ou un lien en ligne pour suggérer que c’est un nom et nom un adjectif ici, car même moi qui connaissait le projet j’ai du m’y reprendre à deux fois pour comprendre que tu parlais du projet « debile ». ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: mythe et mite pour ermite.
Posté par oinkoink_daotter . Évalué à 4.
Sachant que les navigateur web n'utilisent pas openssl (enfin, ni chrome ni firefox, qui utilisent NSS)
# Comic Sans
Posté par stopspam . Évalué à 4.
J'avoue ne pas comprendre : C'est dans le sens où ils ont été les premiers à ce moquer de cette police ? Pourtant utilisée sur les slides de présentation..
[^] # Re: Comic Sans
Posté par Uda . Évalué à 9.
Je crois que cela fait référence au site web volontairement horrible pour financer le travail. (cf : http://www.libressl.org/ )
[^] # Re: Comic Sans
Posté par stopspam . Évalué à 3.
Slide 25 sur la présentation ;)
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00025.html
[^] # Re: Comic Sans
Posté par Psychofox (Mastodon) . Évalué à 10.
C'est marrant parce que ça ne marche pas vraiment en fait. Les antis comic sans dont je fais partie n'ont même pas la police installée sur leur machine.
[^] # Re: Comic Sans
Posté par patate . Évalué à 6.
La présentation affiche toutes les slides en .jpg.
You can run but you can't hide!
[^] # Re: Comic Sans
Posté par Psychofox (Mastodon) . Évalué à 3.
Certe mais on parlait de l'utilisation de la police sur leur site.
[^] # Re: Comic Sans
Posté par JGO . Évalué à 5. Dernière modification le 20 mai 2014 à 17:46.
Depuis CSS3, les navigateurs peuvent télécharger des polices pour les afficher. Voir CSS3 Web fonts ou :en:Web typography. C'est supporté par la plupart des navigateurs, par exemple depuis Firefox 3.5.
[^] # Re: Comic Sans
Posté par Psychofox (Mastodon) . Évalué à 4.
oui je sais et bien heureusement comme c'est interprété sur le client, c'est contournable (même si j'aurais tendance la plupart du temps à fermer l'onglet sans même lire le texte).
# Gestionnaire de source
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Je trouve ça très dommage que LibreSSL utilise encore CVS pour stocker l'historique du code source. Pour rappel, CVS n'a pas de notion de "commit" modifiant plusieurs fichiers. Un changement modifiant deux fichiers donne deux commits. Chaque fichier a son propre historique indépendant du projet global. Je ne sais plus si on peut "taguer" une version dans CVS, ni comment sont géré les branches, mais ça me semble difficile à utiliser (comparé à git/hg).
Du coup, ça va être très galère pour synchroniser LibreSSL avec OpenSSL, ou bien LibreSSL et un fork de LibreSSL.
Je sais pas moi, utilisez Git, Mercurial ou n'importe quoi d'autres de plus récent que CVS !
[^] # Re: Gestionnaire de source
Posté par xcomcmdr . Évalué à 5.
Non mais au delà de CVS, c'est pas assez vieux pour être dans l'esprit Unix, tu comprends…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Gestionnaire de source
Posté par totof2000 . Évalué à -1.
C'est surtout que Git et Mercurial sont GPL et que les xBSD évitentr si possible le code GPL.
[^] # Re: Gestionnaire de source
Posté par totof2000 . Évalué à 0.
Oups, etrreur de ma part, cvs est également GPL.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 6.
Et subversion en apache/mit
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Plus vieux que cvs : sccs ! http://sccs.berlios.de/
J'ai utilisé sccs en 1990 pour gérer les sources sur HP-UX. J'avais écrit une couche supplémentaire liée au makefile pour récupérer toutes les sources d'un logiciel, pour les compiler et pour les renvoyer dans le système de stockage.
[^] # Re: Gestionnaire de source
Posté par rewind (Mastodon) . Évalué à 6.
mais pas OpenCVS
[^] # Re: Gestionnaire de source
Posté par anaseto (site web personnel) . Évalué à 1.
Je ne suis pas sûr qu'OpenCVS soit vraiment utilisé : de ce que j'ai lu ça fait longtemps que les mainteneurs originels ne s'en occupent plus, et ce n'est pas (plus ?) compilé dans le système de base par défaut.
[^] # Re: Gestionnaire de source
Posté par Anonyme . Évalué à 2.
Et puis aussi, ca n'est pas très sécure d'utiliser CVS. Si quelqu'un pirate leur serveur CVS et decide de modifier l'historique d'un fichier pour modifier une ligne, ca sera très difficile à reperer.
Avec git, ca se remarque beaucoup plus facilement.
[^] # Re: Gestionnaire de source
Posté par totof2000 . Évalué à -1.
Oui mais avant, ils devraient analyser le code de GIT pour vérifier qu'il est bien secure. Et surtout, GIT est GPL, et les xBSD n'aiment pas la GPL.
[^] # Re: Gestionnaire de source
Posté par totof2000 . Évalué à 0.
Je dis une ânerie : CVS est également GPL …
[^] # Re: Gestionnaire de source
Posté par totof2000 . Évalué à 2.
RCS ?
[^] # Re: Gestionnaire de source
Posté par zul (site web personnel) . Évalué à 4.
L'art de raler dans toute sa splendeur. Laisse les utiliser les outils qu'ils veulent si ils font le boulot.
On a inventé git-cvs qui marche très bien pour des projets de cette taille. Tu dois en retrouver une dizaine de versions sur github (https://github.com/busterb/libssl-openbsd est probablement la mieux référencé)e.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 8.
Tu veux dire qu'il faut attendre le prochain heartbleed ou la corruption des sources par un attaquant ? Comme ça on aura le droit de dire que CVS ça a 20 ans de retard sans s'entendre dire qu'on est un raleur, mais du coup tu pourra dire que c'est facile à dire après coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 6.
Tu peux signer les patchs indépendant du gestionnaire de version. D'ailleurs c'est le cas.
Franchement les utilisateurs n'ont rien à dire sur les outils qu'utilisent les devs d'un projet auquel ils ne contribuent pas, je soutiens totalement cette position.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 2.
Bien sûr qu'on a le droit d'en dire ce qu'on veut ! Encore heureux !
Après ils ont tout à fait le droit de s'en foutre, mais ce n'est pas pour ça qu'on à pas le droit de commenter ce qu'ils font ou comment ils le font.
Donc oui rien que pour ton commentaire :
CVS ça pu, c'est un outil largement dépassé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Littleboy . Évalué à -2.
Parfaitement!
Surtout que comme la majorite des gens sont bien incapables de modifier le code, il faut bien trouver quelque chose ou on a l'impression d'etre competent, hein. D'ailleurs tout le monde dit que git c'est mieux et que CVS c'est nul, ca doit etre vrai dans tous les cas, il faut absolument le faire savoir aux devs BSDs.
Mais pas sur leur mailing list, non faut pas deconner. Ici sur LinuxFR, pas de risque de se faire blacklister dans la seconde, on peut continuer a troller entre nous.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à -1.
Waow on ne peut plus faire de remarques même un peu brutal ? Faut fermer linuxfr et aller sur Wikipedia.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par lasher . Évalué à 4.
Ben écoute, tu peux faire des remarques brutales, et littleboy peut te répondre brutalement. Ça me semble équitable. :)
Lorsque tu rejoins un projet, tu t'adaptes aux besoins du projet. Dans le cas d'OpenBSD, ils ont décidé de rester sur CVS. C'est un choix discutable. N'empêche, c'est le choix de gens qui ont décidé de se retrousser les manches pour proprifier un code réputé dégueulasse. Donc tu as le choix : utiliser LibreSSL, un CVS « daté », mais actif, avec des gens qui cherchent à faire les choses bien; ou utiliser le git utilisé par le projet OpenSSL, mais qui se traîne des bugs et des archaïsmes désormais connus de tous.
Si j'avais à faire de la maintenance de code, ou à ajouter un algo de crypto à l'un des deux (en supposant que je n'ai besoin que de POSIX, et pas de Windows ou VMS), mon choix serait vite fait.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 2.
Oh ! C'est pas manichéen ça au moins. Aujourd'hui OpenSSL a le soutien de Core Infrastructure Initiative et depuis la fameuse faille est bien plus actif.
Donc on est face de 2 projets qui ont la même base de code au moment où le second a était créé, qui sont tous deux actifs, l'un qui utilise git l'autre cvs et 2 visions un peu différentes : chez LibreSSL, on retire des fonctionnalités pour tenter de réduire la surface d'attaque on se concentre sur une base plus petite qu'on souhaite plus sûr, de l'autre il n'est pas question de supprimer des fonctionnalités et on audite le code pour améliorer sa fiabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par patrick_g (site web personnel) . Évalué à 10.
Mouais…enfin bon quand on regarde la vidéo de la conf de Bob Beck on se dit qu'il va falloir un peu plus que simplement "auditer le code" pour améliorer les choses.
Je suis bien content que les devs OpenBSD se soient lancés dans une méga-chirurgie parce que c'est le seul moyen pour sauver le patient.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
Moi je suis content que tout ça a :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par zebra3 . Évalué à 5.
C'est marrant, quand c'est Mozilla il semble qu'on ait beaucoup moins le droit de râler.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 2.
Je ne crois pas avoir dis à quelqu'un qu'il ne devrait pas critiquer Mozilla, mais plutôt qu'il pourrait plus influer sur le projet en s'impliquant. Ici personnellement je me tamponne de savoir ce qu'ils utilisent, ils pourraient écrire le code avec wordpad et versionner avec cpold, ça ne touche pas ce que je fais, ni ce que je fais de leur logiciel, alors que souvent les critiques envers Mozilla sont plus politiques, on entend souvent dire qu'il faut quitter Firefox, parce qu'il n'est plus libre ou à la traîne. Je sais pas si c'est très clair, mais d'un coté c'est une plainte et on dit qu'il ne faut plus utiliser les logiciel final, alors que là c'est plus une remarque sans faire le moindre commentaire sur la qualité du logiciel fourni finalement.
Ici pour moi, il est plus question de discuter d'un choix technique fais par des gens compétents et qui semble à première vu dépassé (bien sûr on peut en discuter avec eux, mais pourquoi ne pas en parler entre membre de DLFP ? Je présume qu'ici aussi il y a des gens qui utilisent ou qui ont utiliser cvs et qui peuvent faire remonter des anecdotes sympa ou des commentaires pertinents). Autant dire que le C est vieux est un troll et encore beaucoup de projets de divers horizons, même nouveaux se font en C (et il y a tellement de troll là dessus que les raisons de sa longévité sont connus). Pour cvs, c'est plus surprenant, les BSD sont à ma connaissances les derniers à les utiliser, il existe pas ou peu d'hébergement cvs, il y a eu 2 vagues successives qui ont marqués leur époque svn et les dcvs (git puis hg en tête). Bref il semble qu'il n'y a plus grand chose pour défendre cet outil, c'est donc pas tout à fait idiot ou malsain de se demander pourquoi ce projet en particulier (et peut être les autres BSD) continuent à travailler avec ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par rewind (Mastodon) . Évalué à 8.
Si tu veux, je te prête ma paire de rames, parce que tu as l'air de galérer là… ;)
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 2.
Non j'essaie d'être clair. D'un coté on se demande pourquoi est-ce qu'ils utilisent un outil de l'autre on est horripilé parce que tel logiciel n'est plus libre. D'un coté c'est technique et on ne fait pas du chantage à l'utilisation, de l'autre on se pose juste une question technique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Antoine . Évalué à 3.
Les utilisateurs sont des contributeurs potentiels, il ne faut jamais l'oublier.
[^] # Re: Gestionnaire de source
Posté par Sygne (site web personnel) . Évalué à 2.
Avec CVS, pour gérer l'évolution de multiples fichiers, un des usages consiste à:
- commiter chaque fichier,
- modifier le fichier VERSION pour qu'il contienne le numéro de version de chaque fichier,
- commiter le fichier VERSION.
La version du fichier VERSION est ainsi la version du logiciel, et on peut retrouver les versions précédentes à partir de son historique.
En C, c'est bien souvent le fichier version.c qui contient en commentaire la liste des versions de fichiers inclus.
[^] # Re: Gestionnaire de source
Posté par steph1978 . Évalué à 1.
CQFD, c'est mal foutu.
En vrai tu peux utiliser un tag/version pour lier des versions de fichiers entre elles comme formant un tout cohérent.
Reste que SVN est une évolution de CVS qui comble ce type de lacunes et que IMHO le choix de CVS fait un peu oldies. Si j'étais en mesure de contribuer, il me refroidirai.
[^] # Re: Gestionnaire de source
Posté par Anonyme . Évalué à 1.
Meme sans contribuer, juste pour regarder ce qui est fait, ca refroidi.
[^] # Re: Gestionnaire de source
Posté par Sygne (site web personnel) . Évalué à 4.
Je ne soutiens pas le contraire, je faisais juste une note informative.
C'est assez étrange de constater que le besoin de lier entre-elles les versions des divers fichiers d'un même programme n'ait pas été prise en compte lors de la création de ces outils…
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 8.
Pour avoir synchronisé du code depuis openBSD vers un dépôt git à plusieurs reprise, je trouve que ça n'est pas galère du tout. Il suffit d'importer les patchs un à un dans le git et de les commiter comme un seul commit. C'est relativement simple et rapide si on a CVS installé sur sa machine.
[^] # Re: Gestionnaire de source
Posté par Miod in the middle . Évalué à 10.
M'enfin t'as rien compris ! Puisqu'on te dit que cvs c'est mal !
Comme le dit le proverbe : « quand le sage montre le code, le fou regarde l'outil de VCS utilisé. »
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
Ouai m'enfin dire que cvs c'est pas trop mal parce qu'il n'empêche pas d'utiliser git, c'est pas vraiment un argument pour rester avec cvs. C'est simple pour le moment personne n'a dégainé un argument expliquant en quoi cvs c'est bien, juste des arguments pour dire que c'est pas trop mal (on peut l'interfacer avec git, avec une bonne gymnastique on peut avoir un semblant de comit, on peut utiliser un autre outil pour signer les commits (avec un commit par fichier !),…).
Je pense sincèrement qu'un débat sur les outils peut être intéressant. Ce serait intéressant de savoir pourquoi ils le gardent est-ce vraiment parce qu'ils n'ont pas encore trouvé d'intérêt aux DCVS (j'en doute vu qu'apparement certains travaillent avec git), qu'ils ont un usage particulier pas couverts par les DCVS, une question de performance ou de compatibilité,…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par anaseto (site web personnel) . Évalué à 10.
Une petite recherche nous apprend que ce n'est pas la première fois que cette question est posée :
http://marc.info/?l=openbsd-misc&m=134408828426309&w=2
En résumé, et si j'interprète bien, je retiens surtout une chose : le fait que git, par sa gestion plus efficace des branches et des merges, encourage à faire tout plein de branches, et l'esprit d'OpenBSD est plutôt d'encourager tout le monde à tester la branche principale, et favoriser les petits commits nombreux, pour s'assurer que tous les six mois la branche principale est suffisamment stable et testée. La difficulté de faire des merges compliqués imposerait une certaine façon de faire les choses qui serait bénéfique au projet.
Du coup ce ne serait pas un opposition à d'autres systèmes, mais plutôt le fait que cvs convient à la dynamique de développement d'OpenBSD comme système dans son ensemble.
Il y a aussi le fait que changer les habitudes entraînerait une perte de productivité, du moins pendant un certain temps, j'imagine, ce qui n'est pas à prendre la légère non plus.
Et puis sinon, ça servira toujours à éloigner les fous : c'est peut-être là la vraie raison cachée ;)
[^] # Re: Gestionnaire de source
Posté par ckyl . Évalué à 10.
[^] # Re: Gestionnaire de source
Posté par Albert_ . Évalué à 2.
Ah ah ce workflow me rappelle ce que un collegue fait… c'est chiant au possible car grace a lui, la branch dev est toujours casse et pour stabiliser on serait obliger d'arreter tout development. Heureusement que git/mercurial existe pour contourner ce genre de problemes…
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 3. Dernière modification le 20 mai 2014 à 16:47.
Franchement, git si tu rebase pas tout les jours, tu te retrouves très vite dans la merde. Quand tu veux rebaser 2semaines plus tard, il te faut une journée tout entière pour pouvoir rebaser et gérer tout les conflits. Personnellement, j'utilise git mais je suis plus pour développer dans la branche principale pour tout projet qui prend plus de 2 jours.
Surtout que quand tu résouds les conflits parfois tu comprends pas toujours très bien le code qui a été introduit et tu risques d'introduire un bug, donc il faut aller parler avec le type qui a fait l'autre commit. Alors que si c'était dans la branche principale, c'est lui qui gérerait ça quand il commit son code.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 5.
Je ne comprends pas ce que tu dis.
Soit ça signifie que tu commit du code non fini soit que pour toi tout développement prends moins de 2 jours. Sinon le problème est identique c'est juste que tu as le problème au moment de chaque fois que tu push et pas quand tu merge.
Après entre faire un rebase quotidiens et en faire un de temps en temps (juste avant le push) c'est à mon avis dépendant du projet et de la tâche que tu as à faire. Si vous êtes plusieurs à travailler sur des bouts du programme fortement couplés, c'est à mon avis une bonne idée de discuter, si ce sont des modules indépendants, ça ne pose pas de problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Albert_ . Évalué à 3. Dernière modification le 20 mai 2014 à 18:02.
Il commit des qu'il ecrit un truc c' est a dire que c' est parfois (souvent) a moitie fini et il voudrait que tout le monde fasse la meme chose. Il pretend que cela permet de savoir sur quel partie du code les gens bossent".
Je ne suis pas d'accord avec ce genre de workflow. Je prefere ecrire mon code dans mon coin commiter sur mon depot, faire mes tests, debuguer et enfin quand j'ai tout bien comme il faut je fait un pull, je merge mes changement et je fais un push de mes modifications sur le serveur principal.
CVS tu ne peux pas bosser comme cela car tu ne peux pas faire de commit local, tu es oblige de commiter sur le depot central alors heureusement aujourd'hui tu peux avoir ton depot git et envoyer tout en git-cvs mais bon dans ce cas la pourquoi ne pas utiliser git tout simplement?
ps: ratage de personne pour repondre :)
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 0.
Justement, non. Je dis juste que le workflow que tu décris n'est pas forcément le One True Way et qu'on peut trouver des avantages à faire différement. Je ne dis pas que le workflow que tu décris ne marche pas, je trouve juste qu'il ne scale pas bien sur les gros projets fortement inter-dépendants comme les OS. Bon manifestement, ça doit marcher/scaler vu que des gens l'utilisent. Mais des gens utilisent aussi d'autres workflows, qui marchent aussi.
Oui. En quoi c'est un problème ? Tu n'es pas obligé d'activer l'option dans le système de compilation.
C'est vrai. Mais si justement l'idée c'est de ne pas bosser comme ça, je ne vois pas en quoi ça pose un problème.
[^] # Re: Gestionnaire de source
Posté par wilk . Évalué à 3.
Tu peux aussi travailler avec ce workflow de faire des pushs de commits instables toutes les 5 minutes avec git/hg. Tu as aussi le choix de décider à qui revient la tâche du merge. Bref, on ne comprend pas trop pourquoi faire un choix restrictif plutôt que de garder plus de possibilités.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
Tu trouve que tout le monde qui envoie des commit dans un même dépôt très fréquemment ça scale ? Si tu le fait avec quelques développeurs ça peut marcher, si vous êtes plus ça ne me semble pas réaliste. Ton dépôt central devient un amas de travail en cours divers et de qualité assez faible, ton historique est inutilisable,…
Ben tu gêne tout le monde. Si tu veux lancer une analyse statique du code tu as des faux positifs, potentiellement ton code à moitié fini a des effets de bords que tu n'a pas encore imaginés ou pris en compte,… Tu augmente la charge globale de tous le monde pour prendre en compte ton travail, alors que si c'est ton travail, ce serait logique que ce soit à toi que reviens la charge d'intégrer proprement ton code. Tu gagne un historique propre. Pour gérer les gros merge, d'une part tu va naturellement avoir tendance à écrire du code moins invasif, tu ça va te pousser à communiquer avec les développeurs qui travaillent sur la même portion de code que toi (et ça c'est bien parce que c'est pas parce qu'il n'y a pas de conflit détecté par ton VCS qu'il n'y a pas de conflit entre vos travaux) et ça pousse à écrire des tests. Bref oui c'est pas forcément simple, mais ça pousse de bonnes pratiques.
Si tu as un couplage tellement fort que tu dois passer ton temps à faire des merges je doute que tu puisse le faire proprement.
D'ailleurs rien ne t'interdit de faire 300 rebase par jour pour que le jour où tu pousse tes modif' tu n'ai pas de gros merge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à -2.
J'abandonne.
Je viens de me rendre compte que ce type de workflow avait un nom, Agile. J'avais pas fait le lien. Comme je suis pas fan des discussions sans fin à propos de la manière de développer, et qu'apparament plus d'encre a coulé là dessus qu'il n'y a d'eau dans l'océan, autant laisser le soin à google de répondre au pour et au contre de ce genre de méthodes.
Je suis sûr que si je disais aux mecs d'openBSD qu'ils font du developpement agile, je me ferais massacrer, mais là n'est pas la question.
[^] # Re: Gestionnaire de source
Posté par wilk . Évalué à 6.
Au contraire, pour faire de la méthode Agile il faut impérativement que les commits préservent la stabilité de l'application, puisque cette méthode consiste à pouvoir tester l'application à chaque itération.
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 0.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
Tu veux dire que tu arrive à avoir quelque chose de testable (de testé et qui ne casse pas les autres tests) dans du code qui a un fort couplage avec d'autres développement en 2 jours (et à le maintenir ça tous les 2 jours) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 1.
j'arrive à avoir du code testable qui casse pas les autres tests en 3h… Je comprends pas ton point de vue. Ajouter du code sans casser les tests, ça peut signifier ajouter 50 lignes.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
Ce que je ne saisi pas c'est que soit tu es capable de faire ça et il n'y a pas de problème de merge (ce dont tu parlais au départ) soit (comme tu le dis à un moment) il y a un couplage fort entre ce que tu fais et ce que les autres font et ça me semble difficile d'être systématiquement capable d'avoir un code testable et qui ne casse rien en un temps court.
Le pire dans tout ça c'est que dans tous les cas j'ai l'impression qu'un DCVS va de toute manière t'apporter un gain.
Si tu es capable d'avoir ce genre de petits commits, tu peut très bien garder tes commits locaux, les faire à la fréquence qui te convient et faire des rebase quotidiens. Tu poussera ton code une fois que ta fonctionnalité est terminé. Ça ne gêne en rien le fait de faire du développement agile. au contraire ça te permet d'ajouter ou de retirer ta fonctionnalité de manière très simple. Pour pouvoir faire une démonstration au client et qu'il puisse dire que finalement ça ne l'intéresse pas sans que ça représente du travail en plus de retirer ton code (comme tu as soit un commit soit une série de commits qui se suivent tu pourra sans effort garder ces patchs sous le coude pour historiques par exemple). De plus si tu fais de l'agile en principe tu as un paquet de test et si tu n'a pas de politique de test à chaque commit ou push parce que les tests prennent trop de temps tu as le bisect qui va te rendre de bons services.
Je comprends bien que tout le monde ne se mettent pas aux DCVS. C'est vraiment compliqué et je vois déjà suffisament de monde qui ont du mal avec subversion (difficulté de gestion des merges, commits sans message ou avec message inutile, difficulté de gestion des branches ou des tag,…) pour ne pas les accablés un peu plus encore avec un DCVS. Mais d'un point de vu fonctionnel, je ne vois vraiment pas ce que tu perds avec un DCVS (l'argument des développeurs OpenBSD étant qu'avec les DCVS gérer les merges est trop simple…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par ckyl . Évalué à 5.
Elle est marante votre discussion, mais je ne comprends toujours pas pourquoi vous raisonez en utilisant le concept de test, au sens "self-testing code", pour des projets où ce concept est entièrement inconnu.
Prendre comme exemple des projets comme Linux ou OpenBSD comme exemple de modèle de developpement ou essayer de leur appliquer les modèles classiques est rarement une bonne idée car ce sont juste exception qui marchent en raison d'un contexte très particulier.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 1.
Justement ce n'est pas ce dont on parle (du moins c'est pas mon cas), j'ai aucune idée du workflow des contributeurs d'OpenBSD et celui de Linux est très particulier (ils ont une arborescence de dépôts) et est impossible à reproduire (ou très complexe) sur d'autres projets.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Paul . Évalué à 5. Dernière modification le 22 mai 2014 à 11:57.
En l'occurence, LibreSSL est développé au sein d'OpenBSD non ? Même dépôt tout ça.
Édit : le dépôt
[^] # Re: Gestionnaire de source
Posté par Enj0lras . Évalué à 1.
Il y a peut de tests unitaires, mais ça veut pas dire qu'il n'y en a pas du tout ou que tu ne testes pas. Il y a de plus en plus de tests pour tester les API posix ou les appels systèmes. Evidement, ce n'est pas unitaire, mais ça reste un test.
[^] # Re: Gestionnaire de source
Posté par Miod in the middle . Évalué à 10.
Il y a une raison toute simple : l'historique. On a un arbre cvs qui contient près de 20 ans d'historique et plusieurs centaines de millier de commits.
Migrer vers un autre VCS, pour OpenBSD, n'est acceptable que s'il est possible de récupérer la totalité de cet historique. Ce n'est pas du luxe, il arrive fréquemment que l'on aie à effectuer des recherches dans le code sur plusieurs années en arrière, et obliger à utiliser deux outils et deux arbres source selon la période concernée n'est pas acceptable.
On a essayé, par le passé, divers outils de migration de VCS afin d'étudier la possibilité de la chose. Par exemple, cvs2svn n'est pas capable de gérer un arbre aussi gros (aussi bien en consommation mémoire qu'en consommation CPU). Notre meilleur espoir est actuellement effectivement une migration vers git, et un des développeurs a écrit un script qui arrive à traiter tout l'arbre, et reconstruire de véritables commits (i.e. retrouver les fichiers qui font l'objet d'un commit cvs avec le même message et au même moment). Il y a encore quelques opérations cvs qui lui posent problème, cependant.
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 4.
C'était je crois l'argument de Linus pour ne pas utiliser mercurial et plutôt développer git. Récupérer l'existant est en effet très important (même d'un point de vu non technique juste pour l'histoire d'informatique que ça représente). Je ne pensais pas que ça posait tant de problème (notamment parce que le noyau linux l'a lui même fait), mais c'est vrai que depuis cvs ce n'est pas forcément très simple (d'autant qu'il faut, je présume, prévoir un temps en double phase avec les 2 gestionnaires, le temps de tester).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . Évalué à 5.
J'ai vérifié et le premier commit sur le dépôt git de linux date de 2005. Linus y explique :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par Moonz . Évalué à 2.
Il me semble que reposurgeon a été fait très exactement pour ça.
[^] # Re: Gestionnaire de source
Posté par zul (site web personnel) . Évalué à 3. Dernière modification le 22 mai 2014 à 11:14.
Il y'a plein d'outils qui sont fait pour ça :) Et la majorité ne passe pas à l'échelle. On ne parle pas de quelques milliers de commit. On parle de projet avec des centaines de millers de commits, un tas de branches, des branches vendor, … Le mirroir git de NetBSD, c'est 230 000 commits, et pas loin de 400 branches. OpenBSD doit être dans le même ordre de grandeur.
Mais bon globalement, les outils se sont améliorés, et on arrive à récupérer l'historique de manière satisfaisante (même si je ne sais pas sur quel monstre joerg@ a utilisé pour arriver à faire la conversion) (en tout cas pour git). Les mirroirs hg et fossil sont basés sur celui de git de mémoire. Un des problèmes de ce mirroring, c'est l'emploi (abusif ou pas) de cvs admin pour amender les messages de commit.
[^] # Re: Gestionnaire de source
Posté par Moonz . Évalué à 2.
C’est ce que je veux dire : reposurgeon a justement été fait pour les dépots « problématiques » (corrompus, honteusement obèses,…)
Voir par exemple http://esr.ibiblio.org/?p=5634
[^] # Re: Gestionnaire de source
Posté par wilk . Évalué à 1.
Si c'est juste pour l'historique, pourquoi ne pas conserver l'historique avec cvs pour tout ce qui est recherches et utiliser un dvcs pour le développement actuel ? Voir, basculer les nouveaux commits vers cvs.
Ceci dit on comprend que ce ne soit pas l'urgence du moment, parce qu'automatiquement cela s'accompagnerait d'une prise de tête sur toutes les possibilités…
# Grosse erreur de compréhension
Posté par Boa Treize (site web personnel) . Évalué à 10.
Non, 1 million, c'est le budget annuel de la fondation, dont une partie provient des dons. Le reste provient d'activités commerciales (consultance) qui ne sont manifestement pas bénéficiaires. (Source: Wikipedia).
Le texte anglais de la présentation de Bob Beck se traduit plutôt ainsi :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.