Proposal: set custom config media type on attestation manifests

[jedevc]

This patch sets the media type for attestation manifests to application/vnd.docker.attestation.config.v1+json instead of faking a application/vnd.oci.image.config.v1+json type.

This updates the attestation manifests inline with the OCI artifact type defined at https://github.com/opencontainers/artifacts. Aside from just making us inline with the spec here, we would hopefully be able to see better integrations in registries that just handle config media types and don't inspect the custom buildkit attestations.

Additionally, this makes it firmly impossible for runtimes to accidentally download and run the attestation manifest, treating it as an image manifest.

[jedevc]

I did a quick test to confirm how well this works across the different registries we test against: https://github.com/docker/build-push-action/actions/runs/4124641031. Looks like the only failure major failure is on GitLab container registry, which is because they validate the config media type against a list of hardcoded types in the database (for example, see here).

[sudo-bmitch]

I believe quay.io is also filtering on the config media type.

[jedevc]

Ah shoot, I could have sworn we had e2e tests for quay in docker/build-push-action 😢 cc @crazy-max is it feasible to set something like that up?

[jedevc]

Did a test that includes quay as well 👀 https://github.com/docker/build-push-action/actions/runs/4142977994

Yup, as expected this fails, it explicitly fails against a validation check:

MANIFEST_INVALID

failed to parse manifest: manifest data does not match schema: 'application/vnd.docker.attestation.config.v1+json' is not one of ['application/vnd.oci.image.config.v1+json', 'application/vnd.cncf.helm.config.v1+json', 'application/vnd.oci.source.image.config.v1+json', 'application/vnd.unknown.config.v1+json']

[jedevc]

Marking as do-not-merge until:

• We can test with more registries to find out who we break against
• We can notify those upstream registries of our plans so we can avoid breaking pipelines (again 😢)

[jedevc]

We've added a few more tests to the e2e suite for build-push-action, I'm fairly confident that the list includes most of the registries we're interested in.

Out of those, the only ones that break are GitLab and Quay (https://github.com/docker/build-push-action/actions/runs/4321829355/jobs/7543515404), so I think we can try and reach out to them to see about making this change for the next release of BuildKit.

[deleteriousEffect]

Speaking for the GitLab registry, we don't accept media types we don't recognize. Explicitly adding support for anything new gives us the opportunity to ensure that we can properly validate media types we accept and that they behave with our features, particularly online garbage collection, in expected ways.

Essentially, we're choosing to value stability over flexibility and experimentation.

Please open an issue if you want us to support this media type: https://gitlab.com/gitlab-org/container-registry/-/issues

[tianon]

With opencontainers/image-spec#1043, this should maybe be updated to use artifactType instead? 👀

(probably also / separately worth considering setting subject to the original image manifest descriptor so that you're "referrers API ready" 😅)

[sudo-bmitch]

If the config is currently empty and there are no plans to add config blob contents in the future, then artifactType would be a better option. The docs currently say other content may be added later, so this becomes a question to the buildkit devs if that's really needed or if you can put everything inside the SLSA attestation.

For registry support, GitLab is the only one I'm aware of that has an approve list for config.mediaTypes, Quay has removed theirs.

If the subject field is used (which is the OCI way to associate artifacts with an image), then expect issues with Docker Hub and ECR until we release OCI image/distribution 1.1.0.

Personally, I'd like to see the artifactType set to something like application/vnd.in-toto+json with an annotation indicating it was built by docker to allow these attestations to be used by multiple tools.