-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr #define OS Pour moi une lib tierce nécessaire à un soft devient une dépendance système au même titre que tout le reste.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr En particulier ces morceaux ne sont en théorie pas de la responsabilité des devs pour leurs mises-à-jour en particulier de sécurité. Mais des ops. Qui DOIVENT réagir en quelques heures sur une publication de CVE que les devs n’ont aucune chance d’avoir entendu parlé.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr J’ai du mal à voir du coup comment tu plantes ta CI là-dedans. Ou en tout cas comment Docker va résoudre ce problème. Debian oui. Docker non.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Debian gère ça proprement, CI ou pas CI. Il suffira de mettre à jour les libs système, rien d’autre ne bougera et ne pourra bouger (ton paquet soft n’est pas recompilé). Sous Docker, il faut reconstruire l’image de base. Donc le soft. Qui n’est lui pas garanti reproductible.
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Sauf à avoir une tétra-chiée de CI/CD avec 100% de test u/inté, avec Docker je vais serrer les fesses très fort quand je vais cliquer sur « deploy on prod » même si mes tests sont verts. Hors docker, j’ai juste 0 risques d’avoir la moindre régression, même sans aucun test U
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr Avec docker, ça suppose aussi que je sois déjà mainteneur de l’image de base. Si la faille apparaît sur une lib d’une image tierce, je suis fuck complètement et ne pourrait pas mettre l’image à jour, sauf à tout refaire sur une image custom, fixer la faille […]
-
@oaz @_mcorbin @Dr_Alexises @dascritch @damyr_fr modifier l’image de base de l’image soft pour taper sur la nouvelle, rebuilder, déployer… Juste non. Juste non même avec des tests U partout et de la CI/CD.
aeris22’s Twitter Archive—№ 104,907