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 :
Le côté égoïste du cooldown (j'attends que les autres rencontrent le problème). Et surtout, j'aime bien l'idée de la décorrélation publication/distribution de façon centralisée dans le dépôt plutôt que chacun fasse ça dans son coin de façon bricolée.
Et la solution proposée me semble largement préférable : «Upload queues»
L'obligation d'attendre quelques jours avant que son paquet soit accessible à l'installation. Avec un diff visible par tous. Ça aurait d'ailleurs sauvé bien des utilisateurs de AUR. Bon l'inconvénient évident c'est que c'est un outil supplémentaire à gérer du côté des gestionnaires de paquets. Mais peut-être préféreront-ils ça à se faire afficher à chaque fois qu'une supply-chain attack passe par eux.
Posté par fork_bomb .
Évalué à 1 (+0/-0).
Dernière modification le 24 juin 2026 à 17:38.
Le côté égoïste du cooldown (j'attends que les autres rencontrent le problème)
Le problème de cet argument c'est qu'il est complètement faux. Les paquets vérolés ne sont pas détectés par les autres utilisateurs mais typiquement :
Par les entreprises spécialisées dans l'analyse de dépendances, qui se servent de ces analyses pour faire la pub pour leurs services destinés aux entreprises
Par les mainteneurs qui se rendent comptent que leurs jetons ont été récupérés
Y a encore du monde qui utilise des dockerfile aujourd'hui ?
Si oui c'est en local ou en distribué avec swarm ?
Tous le monde n'ai t-il pas déjà passé à kubernetes et helm ?
Si docker compose est uniquement pour le dev et kubernetes en prod, ca revient pas à faire le travail de description et de tests d'environnement deux fois ?
Evidemment que ça existe encore. Sinon comment tu fais pour créer un image OCI pour l'utiliser, par exemple, dans les technologies que tu mentionnes, avec swarm ou kubernetes ?
Oui désolé pour cette erreur de ma part, je voulais parler de docker-compose, quels sont les cas d'utilisation aujourd'hui ?
Je ne remet pas en cause la technologie conteneur et le standard OCI, juste l'outil et l'utilisation de multi-conteneur et volume associés via docker-compose.
Dans quels cas d'usage est-ce encore utilisé, vous faite des déploiements en prod avec ça ?
Je l'utilise pour partager le setup de l'environnement de développement pour mes projets.
Je trouve que le fichier de description de service assez bien et me suffit pour ce cas. Il n'y a pas besoin d'avoir la complexité de la gestion de plusieurs noeuds, des jobs, des ingress, des routes…
Debian distribue docker-compose et podman-compose, je ne crois pas qu'il y a helm et une distribution de kubernetes packagé dans Debian.
Est-ce que tu aurais un exemple de setup helm et kubrnetes pour par exemple travailler sur un projet qui a une base de données et un serveur web ?
# Dockerfile, Containerfile et compose
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-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é à 5 (+2/-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é à 4 (+2/-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
[^] # Re: Plus largement
Posté par jihele . Évalué à 6 (+4/-0).
Je suis assez d'accord avec les arguments du deuxième lien "contre" : https://calpaterson.com/deps.html.
Le côté égoïste du cooldown (j'attends que les autres rencontrent le problème). Et surtout, j'aime bien l'idée de la décorrélation publication/distribution de façon centralisée dans le dépôt plutôt que chacun fasse ça dans son coin de façon bricolée.
[^] # Re: Plus largement
Posté par Faya . Évalué à 4 (+2/-0).
Et la solution proposée me semble largement préférable : «Upload queues»
L'obligation d'attendre quelques jours avant que son paquet soit accessible à l'installation. Avec un diff visible par tous. Ça aurait d'ailleurs sauvé bien des utilisateurs de AUR. Bon l'inconvénient évident c'est que c'est un outil supplémentaire à gérer du côté des gestionnaires de paquets. Mais peut-être préféreront-ils ça à se faire afficher à chaque fois qu'une supply-chain attack passe par eux.
[^] # Re: Plus largement
Posté par fork_bomb . Évalué à 1 (+0/-0). Dernière modification le 24 juin 2026 à 17:38.
Le problème de cet argument c'est qu'il est complètement faux. Les paquets vérolés ne sont pas détectés par les autres utilisateurs mais typiquement :
Par les entreprises spécialisées dans l'analyse de dépendances, qui se servent de ces analyses pour faire la pub pour leurs services destinés aux entreprises
Par les mainteneurs qui se rendent comptent que leurs jetons ont été récupérés
# Dockerfile ?
Posté par Tangi Colin . Évalué à 0 (+0/-1).
Y a encore du monde qui utilise des dockerfile aujourd'hui ?
Si oui c'est en local ou en distribué avec swarm ?
Tous le monde n'ai t-il pas déjà passé à kubernetes et helm ?
Si docker compose est uniquement pour le dev et kubernetes en prod, ca revient pas à faire le travail de description et de tests d'environnement deux fois ?
[^] # Re: Dockerfile ?
Posté par fork_bomb . Évalué à 3 (+2/-0).
Evidemment que ça existe encore. Sinon comment tu fais pour créer un image OCI pour l'utiliser, par exemple, dans les technologies que tu mentionnes, avec swarm ou kubernetes ?
[^] # Re: Dockerfile ?
Posté par ff9097 . Évalué à 3 (+1/-0).
kubernetes c'est vraiment complexe, pas adapté à tous
[^] # Re: Dockerfile ?
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Tu sembles confondre Dockerfile et
docker-compose[^] # Re: Dockerfile ?
Posté par Tangi Colin . Évalué à 1 (+0/-0).
Oui désolé pour cette erreur de ma part, je voulais parler de docker-compose, quels sont les cas d'utilisation aujourd'hui ?
Je ne remet pas en cause la technologie conteneur et le standard OCI, juste l'outil et l'utilisation de multi-conteneur et volume associés via docker-compose.
Dans quels cas d'usage est-ce encore utilisé, vous faite des déploiements en prod avec ça ?
[^] # Re: Dockerfile ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Je l'utilise pour partager le setup de l'environnement de développement pour mes projets.
Je trouve que le fichier de description de service assez bien et me suffit pour ce cas. Il n'y a pas besoin d'avoir la complexité de la gestion de plusieurs noeuds, des jobs, des ingress, des routes…
Debian distribue docker-compose et podman-compose, je ne crois pas qu'il y a helm et une distribution de kubernetes packagé dans Debian.
Est-ce que tu aurais un exemple de setup helm et kubrnetes pour par exemple travailler sur un projet qui a une base de données et un serveur web ?
[^] # Re: Dockerfile ?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Non, mais sur ma machine c’est plus confortable à utiliser que kube (kind ou k3s inclus)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
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.