Autant, une image de 2Go, je comprends que c'est chiant. Autant, une image de 30Mo, avec les débits réseau et les espaces de stockage qu'on a, je me demande si c'est encore utile de réduire la taille.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Oui, c'est bien, mais est-ce que si on en vient à expliquer ce que sont les liaisons statiques et dynamiques d'un programme compilé en C, c'est qu'il ne faut pas reprendre par la base ?
Ensuite, je l'ai lu pour me faire une idée de Docker, qui confirme ce pourquoi je ne l'utilise pas : c'est vraiment sous-optimal par défaut. Et la confiance est très difficile à établir : "FROM gcc" ou "FROM ubuntu", qui me dit que ça ne fait pas autre chose que ce que c'est sensé faire ?
Quand on utilise le compilateur de sa distribution, ou bien téléchargé depuis le site du « fabricant », la chaîne de confiance est courte : sa distribution et le fabricant, avec une vérification cryptographique bien sûr.
Quand on rajoute, avec une image Docker, un FROM gcc on doit faire confiance à un tiers supplémentaire. Certaines parties de cette image ont pu être corrompues afin d'être malveillantes, et je n'ai pas l'impression qu'il y ait un moyen simple de détecter ces corruptions. Je me trompe ?
Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 09 mars 2020 à 10:39.
Une image c'est identifiée par un hash cryptographique de son contenu. Ça peut te permettre de valider une image et de t'assurer qu'elle n'est pas modifiée. L'intérêt du truc c'est d'avoir une chaîne de construction stable. Tu parle d'une chaîne de confiance plus longue, ça n'est pas vraiment le cas :
version distrib' : upstream → distribution
version docker : upstream → repository docker (des fois c'est l'upstream eux-même qui produisent l'image)
Que tu utilise une distribution validée ou une autre tu es sûr d'avoir la même chaîne de construction.
Pour utiliser ça, il suffit de déclarer ainsi :
FROM gcc@sha256:fa369b0da44afd4fe92e20559b55627556621221b9659ed6dc370924b98568dc
Tu peux aussi ne pas faire confiance au docker hub et configurer ton docker pour ne jamais aller chercher chez lui tes images. À la place tu peux avoir ton propre dépôt ou en choisir d'autres (j'imagine que ça ne te fais pas particulièrement confiance, mais les cloud providers exposent leur propre dépôt généralement, gitlab en expose un par projet aussi).
C'est probablement pas parfait, mais ça fait tout de même le taff.
Après il n'est pas obligatoire de faire son build dans docker. Tu peux avoir le même résultat en gardant que la dernière partie en en faisant le build là où tu as envi.
On peut voir pour chaque tag de chaque architecture le log complet de build de l’image
(exemple pour gcc)
Ils chargent même la clé GPG que tu peux vérifier dans le log, et si jamais tu hésites encore, tu pourrais vérifier le hash du binaire une fois dans l’image pour voir que ce qui est loggé correspond bien à ce qui est dans l’image. Et pour gcc, on voit bien que l’image est buildée depuis les sources officielles de gcc.
Je ne pense pas que ce soit si compliqué à vérifier (un onglet tag, plus click sur chaque étape) et on peut le faire également localement. Et comme dit, si tu manques de confiance, tu peux copier ce Dockerfile et le builder toi-même. Dernière étape de paranoïa : est-ce que docker a un bon DNS configuré pour aller sur le bon site officiel de gcc et que le log indiquant récupérer le tar.gz n’est pas en train d’aller sur un site tiers.
Mais bon, à ce niveau là, on arrête l’informatique et on se fait berger, car on peut vraiment tout dévier, y compris le matériel. Tu fais confiance aux puces Intel ? Aucun composant d’espionnage n’a été glissé par les fondeurs techniques ?
# Utile ?
Posté par claudex . Évalué à 4.
Autant, une image de 2Go, je comprends que c'est chiant. Autant, une image de 30Mo, avec les débits réseau et les espaces de stockage qu'on a, je me demande si c'est encore utile de réduire la taille.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Utile ?
Posté par Graveen . Évalué à 3.
Le début de son lien explique comment passer de 1Go à 65Mo, justement, en faisant une compilation avec l'image docker.
Ensuite c'est effectivement un peu plus technique, mais l'idée initiale est sympa :D
# Public ciblé
Posté par Glandos . Évalué à 2.
Oui, c'est bien, mais est-ce que si on en vient à expliquer ce que sont les liaisons statiques et dynamiques d'un programme compilé en C, c'est qu'il ne faut pas reprendre par la base ?
Ensuite, je l'ai lu pour me faire une idée de Docker, qui confirme ce pourquoi je ne l'utilise pas : c'est vraiment sous-optimal par défaut. Et la confiance est très difficile à établir : "FROM gcc" ou "FROM ubuntu", qui me dit que ça ne fait pas autre chose que ce que c'est sensé faire ?
[^] # Re: Public ciblé
Posté par barmic 🦦 . Évalué à 2.
Je ne comprends pas ta critique ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Public ciblé
Posté par Glandos . Évalué à 2.
Pardon, c'était un peu lapidaire.
Quand on utilise le compilateur de sa distribution, ou bien téléchargé depuis le site du « fabricant », la chaîne de confiance est courte : sa distribution et le fabricant, avec une vérification cryptographique bien sûr.
Quand on rajoute, avec une image Docker, un
FROM gccon doit faire confiance à un tiers supplémentaire. Certaines parties de cette image ont pu être corrompues afin d'être malveillantes, et je n'ai pas l'impression qu'il y ait un moyen simple de détecter ces corruptions. Je me trompe ?[^] # Re: Public ciblé
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 09 mars 2020 à 10:39.
Une image c'est identifiée par un hash cryptographique de son contenu. Ça peut te permettre de valider une image et de t'assurer qu'elle n'est pas modifiée. L'intérêt du truc c'est d'avoir une chaîne de construction stable. Tu parle d'une chaîne de confiance plus longue, ça n'est pas vraiment le cas :
Que tu utilise une distribution validée ou une autre tu es sûr d'avoir la même chaîne de construction.
Pour utiliser ça, il suffit de déclarer ainsi :
Tu peux aussi ne pas faire confiance au docker hub et configurer ton docker pour ne jamais aller chercher chez lui tes images. À la place tu peux avoir ton propre dépôt ou en choisir d'autres (j'imagine que ça ne te fais pas particulièrement confiance, mais les cloud providers exposent leur propre dépôt généralement, gitlab en expose un par projet aussi).
C'est probablement pas parfait, mais ça fait tout de même le taff.
Après il n'est pas obligatoire de faire son build dans docker. Tu peux avoir le même résultat en gardant que la dernière partie en en faisant le build là où tu as envi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Public ciblé
Posté par 16aR . Évalué à 2.
On peut voir pour chaque tag de chaque architecture le log complet de build de l’image
(exemple pour gcc)
Ils chargent même la clé GPG que tu peux vérifier dans le log, et si jamais tu hésites encore, tu pourrais vérifier le hash du binaire une fois dans l’image pour voir que ce qui est loggé correspond bien à ce qui est dans l’image. Et pour gcc, on voit bien que l’image est buildée depuis les sources officielles de gcc.
Je ne pense pas que ce soit si compliqué à vérifier (un onglet tag, plus click sur chaque étape) et on peut le faire également localement. Et comme dit, si tu manques de confiance, tu peux copier ce Dockerfile et le builder toi-même. Dernière étape de paranoïa : est-ce que docker a un bon DNS configuré pour aller sur le bon site officiel de gcc et que le log indiquant récupérer le tar.gz n’est pas en train d’aller sur un site tiers.
Mais bon, à ce niveau là, on arrête l’informatique et on se fait berger, car on peut vraiment tout dévier, y compris le matériel. Tu fais confiance aux puces Intel ? Aucun composant d’espionnage n’a été glissé par les fondeurs techniques ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.