Avec latest, ça peut simplement échouer si le tag n'existe pas du tout, ou ramener la dernière version buguée toute fraîche ou une version vérolée.
Avec x.y.z, on indique une version donnée mais l'image peut changer (il y a des images qui sont reconstruites régulièrement pour mettre à jour les dépendances sans changer la version du logiciel principal). Et une version x.y.z correcte à l'instant t n'offre pas de garantie en sécurité pour la suite si l'image change (cas récent de trivy et sa version vérolée). Certains projets offrent une image x.y.z mise à jour régulièrement et une x.y.z-immutable figée.
Avec le sha256, on fige une image précise et elle restera ainsi. (x.y.z@sha256 est du sucre syntaxique pour indiquer à l'humain la version mais c'est le sha qui sert).
On peut aussi configurer sa registry pour que les images qui y sont poussées ne sont pas mutables. Dans ma boite les releases son créés pour les passages en prod, les versions de développement ont des tags de type -SNAP-, tous les tags sont immutables dans la registry, même les images de bases qu'on fournit aux developpeurs.
Le sujet de la mise à jour des dépendances, dans un contexte où elles peuvent être vérolées, fait couler pas mal d'encre, avec des propositions, des réfutations, des alternatives :
# Dockerfile, Containerfile et compose
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Avec latest, ça peut simplement échouer si le tag n'existe pas du tout, ou ramener la dernière version buguée toute fraîche ou une version vérolée.
Avec x.y.z, on indique une version donnée mais l'image peut changer (il y a des images qui sont reconstruites régulièrement pour mettre à jour les dépendances sans changer la version du logiciel principal). Et une version x.y.z correcte à l'instant t n'offre pas de garantie en sécurité pour la suite si l'image change (cas récent de trivy et sa version vérolée). Certains projets offrent une image x.y.z mise à jour régulièrement et une x.y.z-immutable figée.
Avec le sha256, on fige une image précise et elle restera ainsi. (x.y.z@sha256 est du sucre syntaxique pour indiquer à l'humain la version mais c'est le sha qui sert).
[^] # Re: Dockerfile, Containerfile et compose
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
On peut aussi configurer sa registry pour que les images qui y sont poussées ne sont pas mutables. Dans ma boite les releases son créés pour les passages en prod, les versions de développement ont des tags de type -SNAP-, tous les tags sont immutables dans la registry, même les images de bases qu'on fournit aux developpeurs.
# Plus largement
Posté par cg . Évalué à 2 (+0/-0).
Le sujet de la mise à jour des dépendances, dans un contexte où elles peuvent être vérolées, fait couler pas mal d'encre, avec des propositions, des réfutations, des alternatives :
Pour :
https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns
https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html
Contre :
https://illegalcode.net/rfcs/phased_rollouts.html
https://calpaterson.com/deps.html
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.