Expose OCI image manifest annotations through the Engine API

[tboby]

Tell us about your request
Include the Annotations provided in the image manifest application/vnd.oci.image.manifest.v1+json when an Image is pulled in the output of the /images/{name}/json API endpoint. Consider including it in images/json.

It would probably make sense to include them in the docker image inspect output as well.

Which service(s) is this request for?
Docker Engine API, (+ Docker client CLI?)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

I'm trying to build a security scanner/patching tool which inspects running containers and traces back to the version of the application running inside the container.

The standardised format of this information seem to be the "Pre-defined annotation keys" from the OCI image-spec https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys. These include org.opencontainers.image.version, org.opencontainers.image.source, etc.

While many images place these annotation in the image labels, I believe the appropriate place to put them is in the annotations. It seems that Docker Hub Official images enforce this (docker-library/cassandra#260 (comment), @tianon), meaning that official image builds tend to be the only source of images which don't have source/version information available.

Are you currently working around the issue?

The only workaround I'm aware of is to use the distribution spec `/v2//manifests/" endpoint.
However, this has two major draw-backs:

• This metadata endpoint is heavily rate-limited by Docker Hub as it is used as a proxy for image pulls
• This requires internet access/remote registry access in order to inspect simple annotations on images which are already present on the host

Additional context
A note on the official images: Technically they are exempt from the rate limiting, however it's not ideal to have to special-case tooling based on commercial policies which may change.

This could arguably be an extension to /distribution, however that explicitly mentions retrieving information from the remote registry, which is unnecessary for already pulled images/manifests.

The output from /images/json comparing redis:latest to a non-official image