4 ms·
The fact that images are not content-addressed is very surprising to me. I just always assumed they were because… why wouldn’t they be? I bet a large proportion
by bspammer 5y ago
The fact that images are not content-addressed is very surprising to me. I just always assumed they were because… why wouldn’t they be? I bet a large proportion of other devs assumed the same.
- voxic11 5y agoThey are if you use the digest rather than the id.
- mleonhard 5y agoYou can specify the digest of a base image when building a new image. You cannot specify the digest of a built image when starting a container.
- cpuguy83 5y agoA built (as in `docker build && docker run`) image does not have a digest because the digests are for the tar+gzipped versions of the layers (+ the image config and manifest). The layers are not tar+gzipped until you attempt to push them, at which point the digest is calculated.
- hda111 5y agoPodman project recently introduced a lot of content addressing features. Some are still experimental though.
- cpuguy83 5y agoThat's because the parent comment is completely wrong. Images have a reference (e.g. "ubuntu:20.04"), they have an ID inside docker (random string), and they have a digest. All image data is stored by digest. Even when you fetch an image reference it is looking up the digest of that reference and fetching that digest and that digest is verified. An image manifest contains the digests of the image config and the digest of all the layers, the image config also stores the digest of all the layers. This is how all the data is traversed from the registry.
- cpuguy83 5y agoI will add, once the image is on disk indeed the integrity is not verified so it can be modified after pull either maliciously or by accident. Once pulled, the content addressed layers are extracted into the storage driver (overlay, btrfs, whatever).