Image digest different for local image and the pushed image on a registry

[tarun360]

Let var X = The image digest value returned by podman inspect or buildah inspect or skopeo inspect on a local image

Let var Y = The image digest returned by skopeo inspect of the same image that was pushed to some registry using podman push / buildah push

The variables X and Y do not match. Since the image digest is supposed to be unique for a image, shouldn't the image digest match whether it's stored locally or on a registry? Does pushing a image to registry change the image itself and that is why the image digest is different?

Is there some other unique hash value for an image rather than image digest which remains constant whether the image is present locally or on a registry? If yes, how can one access it?

[mheon]

@vrothberg @mtrmac PTAL

[afbjorklund]

The digest differs between different registries, the id is constant - but only within a certain engine instance.

        "Id": "2bd29714875d9206777f9e8876033cbcd58edd14f2c0f1203435296b3f31c5f7",
        "Digest": "sha256:eefcea3b8ce262bc408d717cc2e1b5c99b9742d0f96adbe8f05fdb43cac6ba11",
        "RepoTags": [
            "docker.io/library/busybox:latest"
        ],
        "RepoDigests": [
            "docker.io/library/busybox@sha256:bbb248c803ff97f51db3b37a2a604a6270cd2ee1ca9266120aeccb3b19ce80d2",
            "docker.io/library/busybox@sha256:eefcea3b8ce262bc408d717cc2e1b5c99b9742d0f96adbe8f05fdb43cac6ba11"
        ],

Where eefcea3 is the multi-arch manifest, and bbb248c is the amd64 image.

[tarun360]

certain engine instance

What does engine instance mean?

the id is constant

Can you fetch the id of remote image without pulling it? skopeo inspect doesn't provide image id in it's output.

So the answer to the question in the last paragraph is a 'No' then?

[afbjorklund]

What does engine instance mean?

The server running podman engine

[afbjorklund]

As far as I know, both digest and multi-arch requires a registry since they are like after-thoughts to the format.

I think you can hack it by trying to make predictable checksums, but that also requires fixing the compression etc

[afbjorklund]

This is how it was explained to me: google/go-containerregistry#895 (comment)

I don't know if podman has any other checksum that can identify an image, beyond the id and the digests and the layers ?

[mtrmac]

Since the image digest is supposed to be unique for a image

That’s not a bijection. A unique digest guarantees a specific image representation, but “the same” image can have many different representations: compressed/uncompressed, different compression algorithms, same compression algorithm but different choices made during compression, or perhaps even different whitespace in metadata.

Is there some other unique hash value for an image rather than image digest which remains constant whether the image is present locally or on a registry?

To answer that correctly requires a very careful thinking about what you mean by “an image” or “the same image”.

In the traditional understanding of these concepts (roughly “the same image” is a set of images that are deduplicated when pulling into a single locally-stored object), which might not at all be the semantics you want, there is no such universal value. The config digest is used that way for schema2 and OCI images, but schema1 images and multi-arch images don’t have that value.

---

Typically, the approach needs to be to create a specific image representation, and then freeze that digest value, and work with that digest value.

---

But really, this conversation should not start with these implementation details and build “up” from that low level.

What are you actually trying to do?

[tarun360]

The config digest is used that way for schema2 and OCI images

I forgot to mention I was asking in context of OCI images only. So the config digest (that is image id) does remain unique for 'the same OCI image'?
Also I am unaware of how to to fetch this image id from a remote image (without actually pulling the image), as I believe skopeo inspect doesn't return image id.

What are you actually trying to do?

I am trying to map a OCI image to a object. I could think of two ways to do this

1. Add some label to the image itself to store some metadata to map it to the object. But adding label to a image would change the image itself, so I wanted to avoid this side-effect.
2. Use some unique id of the OCI image to map it to the object (this unique id would be same regardless where the image is stored - locally, some remote repository, or how the image is compressed etc.). Also this unique id should be fetch-able from a remote repository (without actually pulling the image)

[tarun360]

Hi @mtrmac , could you take a look at my above response once ...

[mtrmac]

*shrug* if you are limited to the OCI manifest format, the config digest is a reasonable ID (at least it is consistent with the deduplication semantics of “the same image”) — but it is not automatically suitable for multi-arch images, which are quite prevalent nowadays.

skopeo inspect only provides that value in --raw; it would not be hard to add it.