Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.
À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.
Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.
L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.
Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par benoar . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 7.
À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.
Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.
L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.
Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.