3 ms·

That's why it is imperative that you use sha256 digests. Remember, tags are mutable. `latest` today can be different tomorrow. And it expands to all other tag

That's why it is imperative that you use sha256 digests. Remember, tags are mutable. `latest` today can be different tomorrow. And it expands to all other tags. Nothing prevents me from pushing a new 'version' of a container to an existing `v1.0.1` tag. Tags are not a way of uniquely identifying a container.

londons_explore 2y ago
that really depends on your thoughts of the trustworthiness of the 'owners' of those tags vs the security bugs in the sha256 you pinned and then didn't keep an eye on...
horsawlarway 2y ago
Sure, digests are a good tool when needed, but there's a huge gulf between the risk factors here, and they don't really solve the "trust across repos" problem. The top level image hashes tend to change between repos (because the image name changes in the manifest and is included in the hash). So you'd have to go through an verify each layer sha. Good tool for selecting an exact image in a repo, not a replacement for trust at the naming level (it's a bit like the difference between owning a domain and cert pinning with hpkp).
- cpuguy83 2y ago
  Who's adding image name (with or even without repo name) to the manifest? That's just a terrible idea.
  - horsawlarway 2y ago
    Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through. Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list. But it means the manifest needs to be able to reference and resolve other names, and that means including... names. For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-1257873446 https://github.com/moby/moby/issues/44144#issuecomment-12578... Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different image to the same tag later).
    - cpuguy83 2y ago
      The name is not being set in the manifests, though. The only reference between objects are digests. The only place an image name is stored is actually independent of any manifest, it is an endpoint in the registry that resolves the given name to a digest. Once you have that digest the rest is a DAG.
    - arccy 2y ago
      not sure about the old docker image format, but most modern tools use OCI image format, and that doesn't embed the image name in the manifest, just digests, so it's totally portable everywhere.
zdw 2y ago
`latest` also has many different definitions. Some people think it's tip of the dev branch (ie, pulling from `main` git branch), some people think it's most recent stable release (ie, some released tag). One way to get around this is to just not use `latest` at all, and only push docker tags that perfectly mirror the corresponding git branches/tags.

londons_explore 2y ago

that really depends on your thoughts of the trustworthiness of the 'owners' of those tags vs the security bugs in the sha256 you pinned and then didn't keep an eye on...

horsawlarway 2y ago

Sure, digests are a good tool when needed, but there's a huge gulf between the risk factors here, and they don't really solve the "trust across repos" problem. The top level image hashes tend to change between repos (because the image name changes in the manifest and is included in the hash). So you'd have to go through an verify each layer sha. Good tool for selecting an exact image in a repo, not a replacement for trust at the naming level (it's a bit like the difference between owning a domain and cert pinning with hpkp).

cpuguy83 2y ago
Who's adding image name (with or even without repo name) to the manifest? That's just a terrible idea.
- horsawlarway 2y ago
  Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through. Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list. But it means the manifest needs to be able to reference and resolve other names, and that means including... names. For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-1257873446 https://github.com/moby/moby/issues/44144#issuecomment-12578... Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different image to the same tag later).
  - cpuguy83 2y ago
    The name is not being set in the manifests, though. The only reference between objects are digests. The only place an image name is stored is actually independent of any manifest, it is an endpoint in the registry that resolves the given name to a digest. Once you have that digest the rest is a DAG.
  - arccy 2y ago
    not sure about the old docker image format, but most modern tools use OCI image format, and that doesn't embed the image name in the manifest, just digests, so it's totally portable everywhere.

zdw 2y ago

`latest` also has many different definitions. Some people think it's tip of the dev branch (ie, pulling from `main` git branch), some people think it's most recent stable release (ie, some released tag). One way to get around this is to just not use `latest` at all, and only push docker tags that perfectly mirror the corresponding git branches/tags.