Bonjour, j'ai une idée qui trotte dans ma tête, je sais pas si elle est bonne, alors je demande votre avis.
J'ai bien compris que plusieurs distributions, plusieurs façon de d'empaqueter, etc... ce n'est pas une mauvaise chose.
Cependant, il y a un point pour lequel j'ai des doutes : c'est la sécurité. J'ai du mal à concevoir que sur le nombre de logiciels (et de distributions) existants, les mainteneurs d'une version 'stable' d'une distribution puissent rétroporter quand il y a lieu _toutes_ les corrections des éventuelles failles existantes. Le fait qu'il y ait ne serait-ce qu'une petite faille dans une application critique comme un serveur me fait frémir de peur. Alors l'idée qui a germée de mon esprit tordu la voilà :
« Pour toutes les applications "importantes" comme Apache, Postgresql, python, la libc, le kernel, etc... POURQUOI (il faut toujours un pourquoi dans les questions idiotes) ne pas faire un site commun qui gère (c'est à dire héberge les sources et fait les maj de sécu) ces applications dans les conditions suivantes :
(i) Elles doivent rester (les applications) identiques à la version amont (+ patchs du "site" pour les éventuelles corrections)
(ii) _tout_ le monde est convié à participer aux maj de sécu (i.e les différentes distributions, les concepteurs amonts, des entreprises etc...)
(iii) C'est le point crucial : une 'release' (donc juste un 'freeze' d'une version v) par an, ou par version majeure (ça dépend des cas), avec maintenance de chaque version pendant 3 ans par ex.
»
Le principe c'est qu'après chaque distribution prélève la version qu'elle veut de ce site commun quand elle en a besoin, ce qui ne change pas grand chose aux principes de l'indépendance de celles-ci, mais permet un travail vraiment collaboratif. Si pour une raison X ou Y elles choisissent de ne pas garder une des versions du site, ce sera toujours plus facile pour elle de rétro-porter les changements en s'inspirant de ce qui a été fait.
Une précision, pour les applications comme par ex. le kernel linux, parfois les développeurs décident de maintenir une version particulière (noyau 2.6.16), et il est évidemment judicieux de considérer en priorité ces versions).
Ah oui aussi ce serait indépendant de linux/bsd.
Bon alors je suis pas mainteneur de paquet ni responsable de sécurité ni rien du tout et on m'a certainement pas attendu pour trouver des idées. Donc ils (ceux qui sont directement confrontés à ça) doivent avoir leurs avis sur la question (que j'aimerais bien connaître), mais je code quand même à mes heures perdues, et je sais combien il peut être stressant et difficile de rétro-porter du code, surtout quand ce n'est pas le nôtre, sans risquer de nouveaux bogues.
Journal Une simple idée sur la sécurité
26
jan.
2007
# Je me suis déja posé la question
Posté par briaeros007 . Évalué à 4.
Je pense que ca peut etre vraiment une bonne idée, meme si elle peut etre difficile à mettre en place, au moins elle permettrait d'avoir un pool de logiciels stables bien connu, et pour tout le monde.
# N'importe quoi
Posté par IsNotGood . Évalué à 3.
N'importe quoi pour la bonne raison que les patchs de sécurité *DOIVENT* être en updstream pour que tout le monde en profite. De plus, c'est en upstream qu'il y a les compétences pour bien évaluer un patch.
Et ça c'est le ponpon :
> les développeurs décident de maintenir une version particulière (noyau 2.6.16), et il est évidemment judicieux de considérer en priorité ces versions).
Du grand n'importe quoi.
[^] # Re: N'importe quoi
Posté par BAud (site web personnel) . Évalué à 3.
c'est bien beau côté kernel de décider du 2.6.16 mais si ce n'est pas suivi, peut-être le LSB aurait son mot à dire ou l'utilisateur au final ? (perso je serais pour un 2.6.x + patchs identifiés, la méthode de le nommer 2.6.16.x me plaisait bien si le process avec les distrib' avait été mis en place, ce que la coordination "évidente" a bien montrer ne pas fonctionner _pour l'instant_ => un axe d'amélioration clairement identifiable si tous les constructeurs se coordonnent).
/me rêve d'une coordination et contribution des constructeurs qui imposeraient la validation de leur plateforme en temps utile (2 mois suffisent pour Linux je pense).
[^] # Re: N'importe quoi
Posté par briaeros007 . Évalué à 3.
L'un n'empeche pas l'autre, mais rajouter des fonctionnalités peut aussi rajouter des bugs.
C'est pourquoi debian backporte les patchs de sécurité pour sa version stable si je ne m'abuse.
Ce que j'ai compris c'est de faire ça :
- on 'freeze' une version de n logiciels
- on enleve les bugs connu de ces logiciels. Ce debuggage on le met bien entendu en upstream, mais le logiciel a déja pu évoluer, donc ne convient pas forcément pour nous.
- on regarde attentivement le cert, secunia, etc... pour les maj de sécu.
Quand il y a un problème nous touchant, on essaye de le régler.
Et au bout de n mois, voir à une release majeur, on recommence.
Le dialogue upstream/version du site peut etre présent sans probleme.
Mais tu connais beaucoup de site qui s'amusent à implémenter les patchs de sécurité sur les versions qui ont été sortis il y a 6 mois, et qui ne mettent pas le patch dans le cvs/ release qu'ils estiment stable au moment du correctif ?
L'autre avantage d'un site comme ca, est de pouvoir proposer ca ... en continue !
On freeze m paquets , on s'y occupe. Quand c'est terminé, il y a 'plus que' les patchs de sécu a s'occuper, donc on s'occupe de debugger m autres paquets .... Et ce jusqu'a ce que les m premiers doivent être remis à jour avec leurs version 'courante'.
Debian propose ca , une fois tous les n mois. Forcément ca demande beaucoup de travail et de mobilisation de finir les bugs à partir d'une date précise. Alors qu'en découpant le nombre de logiciels , c'est plus souple amha.
Et on peut assurer le meme niveau de stabilité (en tout cas au niveau de chaque logiciel) , comme on a pas releaser l'ensemble des logiciels dans une distrib ;)
[^] # Re: N'importe quoi
Posté par ciol . Évalué à 2.
Oui, mais si un logiciel est assez vieux (2 ans) est-ce que les développeurs upstream vont continuer à apporter des patchs (et surtout auditer le code pour trouver les failles) ?
Et ça c'est le ponpon
Je ne comprends pas ce que tu veux dire. Le truc ici, c'est de ne pas refaire le travail qui est fait en upstream, on peut imaginer au pif de choisir de maintenir le 2.6.11, 2.6.13, 2.6.15 ? à ben non là on va faire une entorse, vu que le 2.6.16 est maintenu pour un bon moment, 2.6.18.
En fait je ne pense pas vraiment aux grosses distrib qui ont les moyens de backporter et de suivre la sécurité, plutôt les "petites".
À la limite, pour les grosses disto, on peut imaginer qu'elles continuent comme elles ont toujours fait (en participant ou non), ensuite :
- elles peuvent très bien maintenir leurs versions + une version du "site", ce qui ne devraient pas prendre beaucoup plus de temps, d'une façon officielle ou non, et les clients choisissent ensuite leur version
- si au moment où elles passent en version stable leur version d'un logiciel est la même que celle du site, alors c'est tout bénèf pour elles. Sinon bah elles font comme d'hab.
Mais en fait si je me pose cette question c'est surtout par rapport aux alertes de sécurités, il me semble que ces alertes ne fournissent pas toujours le patch et ne concernent pas les versions trop anciennes non ?
Il y a autre chose aussi dont je n'ai pas parlé. Les distributions qui ont un long cycle, peuvent dire : "bon voilà nous on va maintenir le logiciel Y version X pendant tant de temps, donc si ça vous intéresse on va bosser dessus", et ainsi faire profiter les autres, qui à leur tour peuvent participer.
Enfin, ce que je veux dire, c'est qu'on peut imaginer des tas de choses, si une version du site va devenir trop vieille pour être maintenu, et qu'une distribution l'utilise toujours et est prête à la maintenir, ben ok on continue.
[^] # Re: N'importe quoi
Posté par Misc (site web personnel) . Évalué à 3.
> je ne m'abuse.
Oui, ç'est exactement ça ( ce que presque tout le monde fait, pas que debian d'ailleurs ).
# Deux remarques
Posté par Snark_Boojum . Évalué à 3.
2. (a priori pas encore faite) cette description ressemble énormément à ce qu'est une distribution!
Bref, aucun intérêt.
[^] # Re: Deux remarques
Posté par briaeros007 . Évalué à 3.
2°) Une distrib c'est pas juste un dépot de logiciel. Et Ce qu'il propose est de mettre en commun les forces des distribs orientés serveurs pour éviter que chacun fasse ca dans son coin (ce qui est fait actuellement).
Exemple avec juste debian et redhat (ce sont pas les seuls loins de la)
Debian décide que la version n.1 est sa version stable -> il la débugge extensivement, garde cette version (et bien entendu renvoie les patchs de corrections.)
Bien entendu les dvp de debian doivent surveiller les patchs de sécu pour les backporter sur leur version.
Red hat décide que la version n.3 est sa version stable -> il peut profiter du debugge de debian, sauf si il est fait en meme temps... Mais il va devoir se coltiner tous les bugs entre n et n.3 !
Bien entendu les dvp de redhat doivent surveiller les patchs de sécu pour les backporter sur leur version.
Tandis que la :
Le site décide que la version n.2 est sa version stable (par exemple concertation entre les != distribs).
Redhat et debian ont leurs todo lists, et corrigent chacun qu'une fois les bugs.
Les deux surveillent les patchs de sécu, et les corrigent suivant les besoins, et suivant ce qu'ils ont dis sur la mailing list (mais je t'en prie rh , corrige le. Ah non je veux pas t'enlever ton travail, etc...)
Comme ca le travail n'est fait qu'une fois.
Et si une entreprise décide de releaser à la date T, elle sait que ce dépot est stable, et n'as donc qu'a l'utiliser.
[^] # Re: Deux remarques
Posté par Snark_Boojum . Évalué à 1.
[^] # Re: Deux remarques
Posté par Gniarf . Évalué à 3.
# Recompiler
Posté par Grumbl . Évalué à 2.
Vous me direz, il y a à peine dix ans de cela, on expliquait, au contraire, que maintenir des distributions purement binaires n'avait pas beaucoup de sens d'une part, et rendait la question de la sécurité plus délicate à gérer. Mais lorsqu'on ne parvint plus à faire tenir sources et binaires sur un seul CD..... (à l'époque, les modems 9600 à 28.8 étaient la crème de la crème)
[^] # Re: Recompiler
Posté par Aldoo . Évalué à 3.
Il y a 10 ans les modems 56k frappaient déjà à la porte (norme v90 finalisée en 1998, mais il y avait déjà les X2 et les K56Flex avant cela) ! Et l'ADSL a été lancé commercialement il y a 8 ans en France !
Cela dit, l'argument reste pertinent : aux débuts des distributions GNU/Linux, le haut-débit chez le particulier n'était qu'un doux rêve. Je me rappelle l'époque où on allait acheter sa distrib chez Surcouf ;-).
[^] # Re: Recompiler
Posté par Grumbl . Évalué à 2.
Bon, je vais aller m'acheter une paire de charentaises et une robe de chambre molletonnée.
Bon ben je vais réactualiser mon CV et remplacer 10 (arrondi) par 15 (arrondi) années d'exp.
[^] # Re: Recompiler
Posté par dawar (site web personnel) . Évalué à 6.
Souvenez vous, vous baviez devant le Pentium II à 300 Mhz, qui venait de sortir et coutait une fortune, pour remplacer votre brave Cyrix...
# Nicolas, c'est toi ?
Posté par André Rodier . Évalué à 1.
[^] # Re: Nicolas, c'est toi ?
Posté par ciol . Évalué à 0.
[^] # Re: Nicolas, c'est toi ?
Posté par ナイコ (site web personnel) . Évalué à 7.
# ...
Posté par M . Évalué à 4.
Et pourquoi tu ne montes pas un tel site ?
Le gros probleme c'est qu'il faut des gens qui maintiennent les sources sur ton site. Qui va le faire ? Pas l'upstream puisqu'ils ont deja leur propre source (et version a eux). Pas les distribs puisqu'elles ont deja leur propre paquets.
Ensuite chaque distrib utilise des versions différentes avec parfois des patchs maison. Ca suppose que ton site soit capable de maintenir toutes les versions qui existent ... bon courage.
[^] # Re: ...
Posté par ciol . Évalué à -1.
Et pourquoi tu ne montes pas un tel site ?
J'en suis au début de l'apprentissage du XHTML/css/php/sql. Mais bon, j'avoue, même si je maitrisais, j'oserais pas le faire.
[^] # Re: ...
Posté par briaeros007 . Évalué à 2.
Monter le site en soit c'est pas trop dur. Mais faut réussir à ce que les distribs veulent contribuer, donc leurs poser la question itou.
Pas les distribs puisqu'elles ont deja leur propre paquets.
Le but, d'après ce que j'ai compris ; est justement de jouer la :
Pourquoi chaque distrib doit maintenir ses paquets, alors qu'on pourrait essayer de faire que les grosses distribs serveur s'entendent sur ca (ie sur les sources stables à utiliser. Ca évite que chacun fasse son truc dans son coin)
Ensuite c'est faisable ou pas, mais , amha, la question mérite d'etre étudier , non ?
Ensuite chaque distrib utilise des versions différentes avec parfois des patchs maison. Ca suppose que ton site soit capable de maintenir toutes les versions qui existent ... bon courage.
Moi je l'avais compris comme l'inverse :
Les distribs utilisent les versions déja stabilisé du site, et ensuite applique leurs patchs si elles veulent.
Ca permet de centraliser la sécurité des versions stables, et de diminuer le cout total de maintiens de ces paquets, vu que chaque distribe y participe.
[^] # Re: ...
Posté par M . Évalué à 5.
Justement ce que je dissais c'est que je doute que toutes les distribs partent des meme bases et puissent mettre en commun quelque chose. (et si elle parte sur des bases communes par exemple basé sur debian, je me demande si elles ne s'echangent pas deja leur patch de secu).
De plus la definition de version stabilisé rique d'etre tres dur a definir : une distrib plutot orienté user va vouloir du support sur la derniere version, une autre sur celle d'y a 6 mois, une autre sur celle d'1 an.
Les distribs utilisent les versions déja stabilisé du site, et ensuite applique leurs patchs si elles veulent.
Sauf que si leur patch n'est pas compatible avec les modifs de secu, elles sont obligées de faire les modifs en interne.
Dans ce cas autant prendre le patch qui corrige a faille en upstream et l'adapter a son paquet.
Enfin les distribs commerciales ont tout interret a sortir les fixs de secu le plus rapidement possible (et pas attendre d'avoir un fix sur un tel site) pour montrer a leur clients qu'ils maitrisent leur produit et que c'est le plus sur/reactif du marché.
# Précision
Posté par ciol . Évalué à 2.
La question principale que je me pose c'est : les distributions sont-elles sûres ?
(si oui ben ce journal est inutile désolé)
Je ne parle pas seulement des grosses distributions. J'ai l'impression que la sécurité est un frein à la création, par ex. si je décide de créer une nouvelle distribution, je pourrais toujours me débrouiller, si je fais des erreurs ce n'est pas très important, sauf au niveau de la sécurité (à moins d'avoir une distro qui n'a pas de version stable, toujours les derniers logiciels).
Moi ce que j'aimerais c'est décharger au maximum le poids que représente la préoccupation des failles.
# C'est déjà le cas !?
Posté par Victor STINNER (site web personnel) . Évalué à 5.
http://www.debian.org/security/
http://www.gentoo.org/security/en/index.xml
http://www.slackware.com/security/
http://www.openbsd.org/security.html
Ce que j'en ai compris de la sécurité dans les distributions Linux/BSD :
- Chaque distribution choisit une version d'un logiciel lors de la publication d'une nouvelle version de la distribution
- Les failles sont publiées sur des sites tels que le Common Vulnerabilities and Exposure de mitre.org, exemple :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6101
- Un choix est fait entre prend la nouvelle version en upstream ou alors isoler le bug et faire un patch.
Debian étant très conservateur, ils écrivent des patchs. Ubuntu fait pareil.
Pour information, le choix d'une version de logiciel pour une distrbution s'explique par les faits des incompatibilités. Lorsqu'on change la version du noyau Linux par exemple, il faut vérifier que tous les modules soient toujours disponible et que tous les outils proches du noyaux soient compatibles (FUSE, udev, hotplus & co).
J'en ai fait l'expérience : passer du noyau 2.6.17 à 2.6.19 sur Ubuntu m'a changé le nom de mon disque dur (/dev/sda* => /dev/hda*). C'est pas négligeable comme modification, Grub m'a refusé de booter... (bon pour info, Ubuntu utilise désormais des UUID pour identifier les disques dur, ce qui évite ce genre de problème mais j'ai fait mon boulet)
Haypo
[^] # Re: C'est déjà le cas !?
Posté par Raphaël G. (site web personnel) . Évalué à 2.
J'ai mis un 2.6.19tmb de la cooker sur ma mandriva 2007.0 (mare des des corruptions de données de mon FS XFS a chaque fois que le load montait un peu trop).
Nickel, pas eu de problème ni de renommage a faire...
(ni touché a lilo.conf, ni a fstab)
Bon c'est pas non plus super compliqué un tel changement, suffit de s'arranger pour que grub/lilo trouve ton kernel+initrd et après tu le boot avec un root=/dev/sdXY init=/bin/sh et paf tu fait les changements qui vont bien + reboot.
(live cd ou autre comme méthode de boot)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.