aeris22’s avataraeris22’s Twitter Archive—№ 104,913

            1. …in reply to @oaz
              @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Le dev peut-être. L’ops beaucoup moins. Et il se trouve que c’est lui qui est aux manettes pour patcher la CVE.
          1. …in reply to @aeris22
            @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et forcément qu’on préfèrera de la CI et des tests si possible à rien du tout. Mais là comme ça, le système de docker est absolument sans garantie ni filet même avec test U & cie.
        1. …in reply to @aeris22
          @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Debian avec test U : risque de régression nul Debian sans test U : risque de régression faible Docker avec test U : risque de régression élevé Docker sans test U : suicide assisté par ordinateur
      1. …in reply to @aeris22
        @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Même avec test U, la version docker implique de recompiler l’image de base. Donc l’image soft. Qui n’est pas garanti reproductible. On a donc un canyon entre ce qui sort d’un apt update et d’un rebuild docker…
    1. …in reply to @aeris22
      @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et les gens qui disent qu’on maîtrise du coup mieux avec docker parce que ça va être plus stable sont juste en train de te mentir. Absolument toute la chaîne va avoir bougé avec Docker de manière parfaitement incontrôlée. Seule et uniquement la lib CVE-isée va avoir bougé sans.
  1. …in reply to @aeris22
    @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr La seule chose éventuelle qui te sauve de la merde avec docker est tes test U et d’inté. Comme tout le monde le sait, ils sont à 100% sur 100% des use cases… 🤣
    1. …in reply to @aeris22
      @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Bilan : je préfère (et de loin) patcher à chaud un système avec apt, en étant indépendant du dev (il a pu être passé sous un camion, j’en ai rien à faire pour fixer ma CVE) et avec des gardes-fous upstream de partout qui proscrivent les régressions […]
      1. …in reply to @aeris22
        @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr qui seraient en plus fortement détecté lors du passage préalable sur testing par des millions d’utilisateurs potentiel, que de rebuild des trucs testé par 3 pelés dans un coin et nécessitant l’intervention des devs upstream pour fixer leur dockerfile […]
        1. …in reply to @aeris22
          @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr le tout avec comme seul garde-fou des tests u qui représentent rarement les vrais cas d’usage et d’inté qui couvrent à peine 1% du produit.
          1. …in reply to @aeris22
            @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Et on voit très bien le problème en prenant un truc avant/après : Debian : on passe de OS v1.0 + lib v1.0 + soft v1.0 à OS v1.0 + lib v1.1 + soft v1.0. En effet le paquet du soft n’a pas bougé d’un iota, seule la lib à mettre à jour a bougé.
            1. …in reply to @aeris22
              @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Docker : déjà haut niveau on passe de image soft v1.0 à image soft v1.1… pas fou pour connaître les diffs… bas niveau, on passe de root image v1.0 + base image v1.0 + soft image v1.0 à root image v1.0 + base image v1.1 + soft image v1.**1**. 😱
              1. …in reply to @aeris22
                @oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Un soft non reproductible sous Debian aurait donc conduit quand même à seulement la lib qui a bougé. Parce que le soft n’a pas bougé. Un soft non reproductible sous Docker conduit à devoir rebuild l’image soft… et à tout péter…