• [^] # Re: Gentoo, ça criant

    Posté par (site web personnel) . En réponse à la dépêche Vulnérabilités dans OpenSSL. Évalué à 3.

    Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.

    Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
    Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.

    Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.

    Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
    C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.

    Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.

    Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.

    Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
    Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.

    Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !