Do we have any way to copy additional annotations while copying oci images

[shimish2]

While copying oci images I want to copy other annotations also apart from "org.opencontainers.image.ref.name".

[mtrmac]

Thanks for your report.

Please provide a complete reproducer to show what exactly you need.

[shimish2]

Let us suppose this is my one of the manifest entry in index.json and I want to copy it to some destination

src/index.json

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:6dad2f7f67b743f7164373566fc01def942674c07c03bfc7dede4ea0cb1978b64",
      "size": 1911,
      "annotations": {
        "org.opencontainers.image.ref.name": "test-1",
        "org.skopeo.test":"ann-test"
      }
    }
  ]
}

and when I do copy
skopeo copy oci:src:test-1 oci:dest:test-1
I want my manifest entry like this

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:6dad2f7f67b743f7164373566fc01def942674c07c03bfc7dede4ea0cb1978b64",
      "size": 1911,
      "annotations": {
        "org.opencontainers.image.ref.name": "test-1",
        "org.skopeo.test":"ann-test"
      }
    }
  ]
}

but as of now "org.skopeo.test":"ann-test" annotation entry will not be there.

Do we have any way where we can copy additional annotation also while copying ?

[mtrmac]

Thanks.

This is currently difficult to do in the c/image data model, where an image is sort of an atomic complete unit, which “starts” at the manifest/index level (apart from signatures) — in particular the manifest digest is supposed to authenticate the entire contents of the image. Annotations that are “outside” of the area authenticated by the digest don’t really fit that — we might be able to extend the model to preserve annotation the way signatures are preserved, of course, but that would break the security assumptions of digest references and signatures.

Right now I think the code can preserve annotations inside a multi-arch image (i.e. the OCI index pointing at other manifests), but that’s not the general case.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mtrmac should this issue be closed?

[mtrmac]

Short-term. this does seems like something that would best be handled by an OCI-archive-specific tool.

It’s difficult enough to provide a common interface for images across transports; the repo/archive/collection-of-images featuresets are so wildly different across the formats, that building a common abstraction on top would not be much more than just a collection of special cases.

OTOH, c/image is very slowly building up in that direction - docker-archive now has a whole-archive Reader/Writer, and oci-archive will have something similar soon (containers/image#1381 ). The two are definitely not going to have a common interface for the foreseeable future, so skopeo copy won’t work with any format-specific repo annotations.

But after that c/image OCI Reader/Writer interface is added, a special-purpose tool specific to OCI that can work with those annotations could probably be built with just a little effort. That’s probably some one-off tool, not Skopeo — though we could revisit if this ends up being a widely needed feature.