set base image annotations by default according to OCI image spec

[developer-guy]

According to the discussion on Slack: docker/roadmap#243 (comment)

I know BuildKit provides an additional image config for reproducibility, but as @imjasonh asked, would it make sense also to have BuildKit put that information into annotations (when/if it produced OCI images that support image annotations)?

Here is the spec: https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys

[developer-guy]

Kindly ping @crazy-max @tonistiigi 🙋🏻‍♂️

[developer-guy]

I'm willing to do this as well 🤩

[tonistiigi]

As described in the other issue I think our new buildinfo features are superior to this annotation that only captures a single specific field for a specific build type.

Adding custom user-defined annotation support is fine though as described in #1220

[imjasonh]

As described in the other issue I think our new buildinfo features are superior to this annotation that only captures a single specific field for a specific build type.

I somewhat disagree. Though buildkit's buildinfo references will tell you about more images involved in building the image (esp multistage build stages, and buildkit frontend interpreters), AFAIK there's no way to identify which of those image represents the "base" of the final produced image.

The OCI annotations only tell you that, but it does (intend to) make it clear that's what's being communicated. This came up a lot in the discussion about the OCI annotations, and we decided that since "multi-stage builds" aren't a thing in the general OCI landscape, only in buildkit/Dockerfile-originating builds, that it would be more useful to limit the scope of the annotation to only communicate "this image shares base layers" and not "this image was nebulously involved in building your image"

[tonistiigi]

There is no such thing as "base" for an image. Images can be created in a lot of ways, not only via Dockerfile and not only via Dockerfile that uses FROM <image-from-a-registry> in the last stage. Layers can be also flattened, diffed, merged from multiple images etc. in buildkit.

If you want to see if one of the build sources shares the same layers as the top layers of the image only thing you need to do is pull a manifest or config for both of them and see if the layers property is a subset of the other.

[imjasonh]

There is no such thing as "base" for an image. Images can be created in a lot of ways, not only via Dockerfile and not only via Dockerfile that uses FROM <image-from-a-registry> in the last stage. Layers can be also flattened, diffed, merged from multiple images etc. in buildkit.

I agree! (And even made many of the same points in the many discussions about the OCI annotations 😆)

But, when there is an easily-defined base -- that is, FROM image-in-registry as the last stage, not having been flattened, diffed, merged, scrambled or hard-boiled, then surfacing that information in the OCI annotation can have downstream benefits. Not all images are guaranteed to have the annotations set, and if they don't, that's fine.

If you want to see if one of the build sources shares the same layers as the top layers of the image only thing you need to do is pull a manifest or config for both of them and see if the layers property is a subset of the other.

That is certainly another approach. However, given an image of unknown provenance, there's no effective way to identify its base aside from comparing it to a list of possible base images, and all old versions of those images, including images where the tag may have changed and is no longer present in the registry due to GC.

Having a build tool insert this information -- a subset of the same information present in buildinfo today -- narrows the field considerably. Tooling should still inspect and verify the value is correct (the base image's layers equal the built image's layers[0:N]), but at least they don't have to scan a universe of possible base images to find it.