Deux failles importantes de sécurité découvertes dans 7-Zip

Disons qu'il y a un vivier conséquent de personnes élevées au clicodrome redmondien depuis leur plus jeune âge... certains se satisfont aussi d'une boite noire opérée à coups de recettes de cuisine niveau sorcellerie (finissant souvent selon l'adage "un windows ne se dépanne pas, il se réinstalle!"), quand une boite blanche favorise plutôt une réflexion structurée (voir permet de pousser un patch).

Pourtant, les dépôts Debian sont assez riches pour ne pas avoir besoin de bricoler comme sur les RH (dépôts vides en comparaison, d'où du bricolage à ajouter des dépôts Fedora par exemple... quand ce n'est pas, pour éviter cela, faire des build à partir des sources de ce qui manque aux utilisateurs et ne sera jamais suivi niveau vulnérabilités/bugs), au hasard!

Au départ, une des motivations d'Ubuntu était d'ailleurs de concurrencer RH en entreprise avec une base Debian: Mixer l'offre de support de RH qui fait son succès en entreprise avec la richesse de Debian qui facilite bien la vie.

Maintenant, tout OS peut s'installer et/ou s'utiliser n'importe comment: Je dirais qu'un Java pas à jour, c'est la norme vu que tout ce qui est encore codé dans ce langage (désormais en lent déclin) vient quasi systématiquement avec sa JVM et dépendances telles que testées/validées par celui qui l'édite, vu les nb pb passés. Impossible d'imposer une version système maintenue sans casse probable. Python prends d'ailleurs à son échelle le même chemin, à coups de venv chez les utilisateurs pour ne pas casser la version système. Fini le temps ou juste tirer les dépendances des dépôts suffisait à faire tourner tout ce qu'on trouve ainsi codé sans risquer de casse.
De toutes manières, windows n'offre pas la cohérence système globale assurée par les dépôts, les exécutables même natifs qui viennent avec leurs librairies quasi doublon de celles systèmes (ou buildées statique) dans la version testée c'était la norme bien avant les machines à bytecode... et c'est inévitable, en fait, dans un système de sources clos: Impossible d'avoir des mainteneurs pouvant builder (au besoin en les faisant évoluer à la marge) en accord avec les librairies/versions système de chaque distro. Enfin pour celles qui refusent les snap&co ailleurs que, éventuellement, côté utilisateur qui aurait un réel besoin de ces dégueulasseries coûteuses en stockage et mémoire (quasi doublons que la gestion de mémoire virtuelle ne pourra optimiser).

Bref, voir se plaindre de tels bricolages qui sont largement évitables côté distros Linux alors qu'ils ont toujours été la norme côté Windows, ça fait un peut bizarre je dois dire!

C'est un point de vue, mais franchement avec Debian j'ai vu peu de problèmes justement car on n'a pas à sortir des clous et que dans ce cadre, toutes les MAJ et même les upgrades d'une version à la suivante se passent bien, du raspberry au Proliant.
Et si je conçoit le besoin d'avoir certaines applis évoluant à un rythme différent de l'OS (voir n'évoluant plus du tout et dont on a perdu les sources depuis longtemps, mais dont le besoin perdure) imposant une forme de conteneurisation, sur un poste de travail ça doit largement se compter sur les doigts d'une main. Puis cela pourrait être fait via l'ajout d'un dépôt tiers d'une application bien maintenue, surtout si on la paie.
Niveau dimensionnement des machines, ce qui en parc fait des pépettes, cette cohérence globale est quand même la raison majeure pour laquelle une distro Linux restée dans ce classicisme (éviter Ubuntu&Co) tourne toujours sans problème sur les ressources d'une machine de plus de 10 ans, livrée alors en windows 7 et sur laquelle un windows 10 était déjà quasiment inutilisable... un 11 ne s'y installant même pas.
Niveau pilotes, le constat est encore plus favorable je dirais: Sous Linux le cas général c'est qu'on branche et ça marche, tout simplement: Le module noyau sera en général là et alors chargé sans la moindre action utilisateur requise. Même ce qui a longtemps été à la traîne vs Windows (imprimantes/scanners) c'est OK avec pour les imprimantes le bonus de pilotes libres qui ne te bloquent pas l'impression quand l'imprimante dit que le toner est vide (permettant de se rendre compte qu'on imprime encore facilement le tiers de la capacité annoncée en nb de page avant que la qualité des impressions ne se dégrade vraiment), chose que font classiquement les pilotes fournis par les fabricants histoire d'alimenter leur business.
Note aussi que 99% des pilotes sont gérés upstream, ce qui veut dire que les driver-model peuvent évoluer niveau kernel (car on peut faire évoluer les drivers en face, ce qu'on fabricant ne fait pas forcément suite fin de vie produit... ou clef sous la porte) radicalement au besoin (niveau réseau ou USB, en 25 ans, y'a eu bien du changement lié aux évolutions du matériel) tandis que windows est obligé de les multiplier ou gérer des rustines plus ou moins élégantes pour ne pas casser la compatibilité de ce qui n'évoluera plus en source clos mais reste utilisé: Alors ok, on a de la doc, mais la dette technique inévitable en est un sacré générateur d'une part et en prime intellectuellement travailler à ces niveaux devient une plaie. D'ailleurs, les échecs de Microsoft en embarqué/téléphonie résultent aussi du fait du manque de développeurs ayant bien voulu s'y coller, même en se bouchant le nez avec la consolation d'un meilleur salaire temporaire (vu l'issue).