Journal Rapidité de patch et packages

Posté par  (site web personnel) .
Étiquettes : aucune
0
19
mai
2003
Bonjour,

Suite au fameux troll "Un petit vent d'hiver", je me posais la question: quels sont les délais sous lesquels sont distros (disons Redhat, Mandrake et Debian) fournissent des packages mis à jour (par exemple dans le cas de openssh) ?
Certains arguent qu'un bon administrateur doit savoir compiler ses programmes (Ce qui permet d'avoir une vitesse de réaction très rapide par rapport à la parution des patchs). Cela signifie-t-il qu'il faut oublier les systèmes de packages ? Je vois mal un utilisateur non-informaticien recompiler Mozilla parce qu'une faille vient d'être découverte. Que doit-il faire ? Attendre une mise à jour de la part de sa distro ? Utiliser une solution temporaire "radicale" (comme couper le javascript) ?

  • # Re: Rapidité de patch et packages

    Posté par  . Évalué à 3.

    La plupart des distribs offrent un nouveau paquet dès lors que les failles importantes sont découvertes et qu'un correctif est dispo.

    A priori, à moins d'être admin à plein temps, les gens de la distrib vont faire le paquet plus vite. Et si l'on est admin à plein temps et que l'on doit faire les paquets, pourquoi ne pas directement contribuer aux paquets des distribs (debian en particulier, qui permet cela), plutot que faire son paquet de coté ?

    • [^] # Re: Rapidité de patch et packages

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

      Si j'ai bien compris, tu confirmes que le délai "de 50 jours pour des distribs dont je ne peux pas dire le nom" est du FUD total :-)

      • [^] # Re: Rapidité de patch et packages

        Posté par  . Évalué à 1.

        Bien sûr. Enfin, au moins en ce qui concerne les principales applications.

        Maintenant, il y a sans doute de petits programme, gérés par une ou deux personnes tout au plus et pour lesquelles la correction d'un débordement de buffert peut prendre plus de temps.

        De toute façon, tant que les pontes de M$ compareront pour ce genre de statistique un OS, certe évolué, d'un coté et une distrib complète (parfois 7 CDs) de l'autre, ce genre de FUD ne peut pas être pris au sérieux... Allez, dites-moi que ce n'est pas possible... Si ?
        :-)

      • [^] # Re: Rapidité de patch et packages

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

        Heu il se peut qu'il y ait des distribs pourries aussi hein.
        Parmi les centaines de distribs il doit y en avoir des pas trop maintenues.

  • # Re: Rapidité de patch et packages

    Posté par  . Évalué à 1.

    C'est pour cela que je disais dernièrement que pour moi le mécanisme des ports BSD était plus efficace que le système des paquets type rpm ou même deb. Ils permettent en effet (enfin, c'est mon avis) une très bonne gestion des configurations mixtes installation par ports / compilations à la main.

    Gentoo c'est récemment (tout est relatif) inspiré de ce mécanisme et c'est tant mieux pour Linux...

  • # Re: Rapidité de patch et packages

    Posté par  . Évalué à 1.

    Cela signifie-t-il qu'il faut oublier les systèmes de packages ? Pour info si tu utilises le système de gestion de packages RPM, tu peux utiliser checkinstall pour garder la cohérence de la base rpm tout en utilisant des programmes que tu compile -au lieu de make install, en root, tu tape checkinstall, cela t'installera le packet, créera les paquets rpm et src.rpm -le programme te propose un nom en fonction du nom du répertoire mére des sources -tu peux modifier pour que cela remplace bien le programme déjà installer- et si tu a bien penser lors du configure de mettre --prefix=/le/rep/qui/va/ien (en général /usr au lieu de /usr/local par défaut, car les paquets rpm de distrib se mettent plutôt dans usr- tu as rapidement la mise à jour, en onservant l'homogénéité de ta base RPM, et de plus tu peux envoyer les rpm et src.rpm généré à ta distrib pour qu'ils le mettent à jour plusrapidement, c ceux que je fais -sauf pour des progs pas forcément intéressant pur bcp de monde-

    • [^] # Re: Rapidité de patch et packages

      Posté par  . Évalué à 1.

      oui, et il existe le meme genre d'outils sous debian. De plus, il y a une source debian specialement dediée a ce genre de mis a jour, (security.debian.org . .. pour woody et testing)tandis qu'en sid, le packet est directement mis a jour dedans, le jour meme ou la faille a ete decouverte (pour les grosses qui risquent de toucher du monde hin :)

      • [^] # Re: Rapidité de patch et packages

        Posté par  . Évalué à 1.

        Hmmmm..... Pour autant que je sache, security est en principe seulement destine a la stable. Bien sur, si les versions "stable" et "testing" sont les meme, la mise a jour sur security se fera... De toute facon, en cas d'alerte de securite, il suffit de regarder la page idoine sur debian.og pour etre informe de son impact sur les differents niveaux de release.

  • # Probléme de mises à jour

    Posté par  . Évalué à 1.

    En fait, je me demande comment font les industriels pour par craquer avec leur mise a jour de serveur.
    Un particulier en a rien a foutre, mais pour un industriel serieux, le moindre chagement de soft sur un serveur entraine un serie de test+validation. Mais comment font-ils?

    • [^] # Re: Probléme de mises à jour

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

      > Mais comment font-ils?

      Ils délèguent la phase de test+validation à une boite externe dans laquelle ils ont confiance.
      Ca ne les empeche pas de le faire aussi chez eux, mais en tres rapide.

      Et la boite externe en question c'est probablement souvent ... l'éditeur du logiciel (ou de la distrib).

      Apres vient peut etre la réflexion qu'il vaut mieux risquer un bug hypotétique qu'une faille de sécu réelle et connue

Suivre le flux des commentaires

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