-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr C’est là que ça bifurque. La version « théorique » voudrait qu’effectivement les devs gèrent les maj de sécu du système global. On sait « en pratique » ce que ça donne…
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Une version « propre » voudrait que la partie dépendance devienne de la responsabilité des ops, qui devraient pouvoir mettre à jour les libs en dessous du soft sans intervention des devs. C’est ce que permet le packaging debian. Le soft est indépendant des libs.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et le packaging est là pour assurer les ops de la reproductibilité du truc. Un upgrade système n’impacte pas le soft (l’upgrade système ne change pas le versionning du soft). Un patch de sécu du soft n’impacte pas le système et le soft (.patch dans .debian.tar.gz).
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Le packaging propre permet justement de décoreller assez fortement le taff dev/ops, sans nécessiter aux ops la maîtrise des 38.246 gestionnaires de dépendance des devs.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Eux, ils ont exclusivement leur outil système (deb/rpm/whatever, peu importe ici), qui garantie la reproductibilité à un niveau proche de la perfection (via no-network source-only, etc).
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr C’est ce qui permet par exemple à debian d’avoir aujourd’hui plus de 95% des packages en reproduction 100% jusqu’au niveau binaire : tests.reproducible-builds.org/debian/reproducible.html
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr N’importe où tu sois sur la planète, quelque soit ta machine, tu obtiendras toujours le même binaire identique au bit près à ce que le dev upstream a obtenu à n’importe quel point dans le temps.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et ce quelque soit le gestionnaire de paquets sous-jacent côté dev. Autant dire que docker est très très très très très loin de pouvoir espérer ce type de chose.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et « les gens » pensent que ce détail n’est justement qu’un détail et qu’on s’en fout. C’est à la base même de la sécurité en fait…
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Ça permet énormément de choses que peu de personnes ont conscience. En tout cas pas celles qui ont abandonné le packaging après y avoir passé 10min.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Mise à jour des libs système ? Pas d’impact a priori sur le package existant = pas de relivraison à faire au niveau global. S’il s’avère que la dépendance du .debian.tar.gz doit être bougé, l’ops est autonome pour le faire sans toucher à l’upstream (.orig.tar.gz).
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Mise à jour d’une 0 day à faire en urgence ? Les devs livrent le .patch, les ops savent recompiler .orig.tar.gz + .debian.tar.gz + patch, garantissant l’absolue non régression sur les sources ou les dépendances autres (0 diff possibles sinon le patch).
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Une maj du soft à faire ? Les devs devront justifier du pourquoi le .debian.tar.gz a été modifié, ce qui impliquerait des modifs possibles côté ops. Les modifs équivalents côté .orig.tar.gz sont impossibles, l’intégration de dépendances autres étant bloquées par le no-network.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Une version d’une lib n’est plus admissible en prod parce que trop vieille ? Tout soft qui en dépend est immédiatement non déployable en prod. Ça motive un max à se sortir les doigts pour éviter 10 ans de retard.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Typiquement le cas de CouchDB, refusée en intégration chez Debian parce qu’incapable de sortir les dépendances de leur propre base de code + utilisation de libs obsolètes = removal pur et simple.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr On a eu 2 choix à un moment donné : - enseigner aux devs le pourquoi du comment du packaging et dire fuck aux managers pour leur time to market - régler le problème de time to market des managers en laissant les devs faire n’importe quoi Devine ce qu’on a choisi…
aeris22’s Twitter Archive—№ 104,886