Why are the signatures OCI Images rather than OCI Artifacts?

[TBBle]

Question

Why are the signatures OCI Images rather than OCI Artifacts?

I've been poking through the docs and website for a while, but couldn't track down an answer, or even a discussion.

It seems to me that the current OCI Images created by this tool (relevant source) are not valid per the OCI Image spec because the layers are application/vnd.dev.cosign.simplesigning.v1+json, which is not covered by the layer spec. This means that, for example, if you pointed a container runtime at the uploaded image, its initial checks would pass (i.e. config application/vnd.oci.image.config.v1+json is recognised) but then the layer itself is in an unknown format. (If there's no actual OCI Image Config object being uploaded, then it'd probably barf on looking for that too... It's <omitted for brevity> in the spec, but glancing at the code, I don't think a config object is linked at all? I did see a bug report with a SHA reference for a config object though, but I don't know what that would be...)

And it's pretty explicitly stated in the OCI Artifact guidelines:

Note: The config.mediaType of application/vnd.oci.image.config.v1+json is reserved for artifacts intended to be run and instanced by docker, containerd and other OCI Image runtimes and tool chains.

I was clued in to this oddity by this change in quay where you can see it specifying the layer types allowed for Helm OCI Artifacts, and bizarrely specifying that OCI Images have a layer type of application/vnd.dev.cosign.simplesigning.v1+json (which I assume is additive in their code-base)

This projects seems like a prime candidate for being an OCI Artifact, and defining your own config mediaType, e.g., application/vnd.dev.cosign.config.v1 (assuming there's actual config data to be stored), would meet the desired criteria that anything pulling such a manifest knows immediately if it can handle it or not. It would also allow projects like quay which require explicit OCI Artifact opt-in, to support opt-in distinctly for cosign as its own artifact type, rather than a weird appendage of OCI Images.

[dlorenc]

OCI Artifacts don't work on DockerHub. See here for some more info: https://dlorenc.medium.com/oci-artifacts-explained-8f4a77945c13

Unfortunately we have to operate in the gray area between "actually follows the spec" and "actually works in registries".

[TBBle]

For DockerHub (and other services that don't support OCI Artifacts -- the only one I could identify was quay.io pending software updates) one could use the existing Docker manifest option; that way there's only one "non-standard" approach, rather than two; and we also get a standards-applicable version that people can build other tooling on reliably.

The current approach also pushes registry code away from standards compliance, by requiring that a well-defined OCI Image also support a layer format outside that spec, which seems like the opposite of where we want to apply user-pressure for OCI Artifact support, i.e. instead of "The last couple of hold-outs need to get OCI Artifact support deployed" (the message coming from Helm in particular, but also BuildKit is pushing that way), the message from cosign is "We need everyone to disable their OCI Image validation for layer media types".

In some sense, if a registry doesn't support OCI Artifacts via config.mediaType other than "OCIContainerImage" and "DockerImage", isn't that a declaration that they only want container images in their registry?

That said, I didn't realise DockerHub didn't have OCI Artifact support yet, and so I found the tracking ticket, https://github.com/docker/roadmap/issues/135, which has seem some movement in the last month.

[dlorenc]

That said, I didn't realise DockerHub didn't have OCI Artifact support yet, and so I found the tracking ticket, docker/roadmap#135, which has seem some movement in the last month.

When this one goes in I think it should be safe to switch. I'd rather not require people to set a flag to make things work on Dockerhub :(

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[TBBle]

Still a thing, but pending on https://github.com/docker/roadmap/issues/135 before any changes can be made on this.

[imjasonh]

In the last ~month, the OCI working group for reference types has proposed and accepted https://github.com/opencontainers/distribution-spec/pull/335 and https://github.com/opencontainers/image-spec/pull/934 which describe an OCI-official method both for describing and querying artifacts-that-reference-things (e.g., signatures), and a fallback naming mechanism for registries that don't yet support the new official method.

Over time I expect cosign to adopt this new method, hopefully/probably via support in go-containerregistry, so the ecosystem of things that create signatures/etc (e.g., Tekton Chains) can do so in a common, OCI-specified way, and rely on the fallback naming mechanism to push to and pull from older registries.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[TBBle]

DockerHub has now gained support for OCI Artifacts, so that's one fewer roadblocks for the changes @imjasonh described above.

[dlorenc]

Yes! We should make the migration.

[znewman01]

Duplicate of https://github.com/sigstore/cosign/issues/1397 which has more activity recently