Hi @vvoland. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

This change LGTM, but I wonder if we also need to consider filtering out attestations at the layer "above" the in-toto media type? In the image index, each platform architecture (which is up to 5-7 for many official DockerHub images) has an additional OCI image manifest entry using the standard OCI media type, that, when descended to in this code, will add the config object and the "layers" to the array of children. This PR is filtering out logging of those "layers" which are what actually contain the in toto media type.

Maybe this concern is for a follow-up PR, but if we just filtered out the "dummy" manifests that included in-toto attestations that would keep this code from even doing all that fetching and parsing when it is only going to find in-toto objects as the leaves of that target "dummy" manifest.

For clarity, here is a snippet of the alpine:latest image on DockerHub's list of manifests in the image index; as noted above every entry for a platform also has this image manifest with a specific annotation: "vnd.docker.reference.type" : "attestation-manifest"

{
         "annotations" : {
            "com.docker.official-images.bashbrew.arch" : "amd64",
            "vnd.docker.reference.digest" : "sha256:483f502c0e6aff6d80a807f25d3f88afa40439c29fdd2d21a0912e0f42db842a",
            "vnd.docker.reference.type" : "attestation-manifest"
         },
         "digest" : "sha256:dbfa325a01bb58ad0d54ec0a8041d98329109fd99286e45b36e2dbf9ed407c41",
         "mediaType" : "application/vnd.oci.image.manifest.v1+json",
         "platform" : {
            "architecture" : "unknown",
            "os" : "unknown"
         },
         "size" : 838
      },

if we just filtered out the "dummy" manifests that included in-toto attestations that would keep this code from even doing all that fetching and parsing when it is only going to find in-toto objects as the leaves of that target "dummy" manifest.

Wouldn't it be too much though? They are still children of that manifests, so I would expect the Children function to also return them if I call it on a manifest list containing attestation manifests.

Bump, I think this one is ready to be merged :)

ping @estesp @AkihiroSuda can we add this to merge queue? thank you!

/cherry-pick release/1.6
/cherry-pick release/1.7
/cherry-pick release/2.0

@dmcgowan: #11327 failed to apply on top of branch "release/1.6":

Applying: core/images: Ignore attestations when traversing children
Using index info to reconstruct a base tree...
A	core/images/image.go
A	core/images/mediatypes.go
Falling back to patching base and 3-way merge...
Auto-merging images/mediatypes.go
Auto-merging images/image.go
CONFLICT (content): Merge conflict in images/image.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 core/images: Ignore attestations when traversing children

/cherry-pick release/2.0

Of course 1.6 and 1.7 will have to be manual cherry-pick

@dmcgowan: new pull request created: #11537