[rfc] adding version and mediatype information to image config?

[cyphar]

While looking at porting the validation code from oci-image-tools to umoci, I noticed that application/vnd.oci.image.config.v1+json does not contain a schemaVersion tag nor mediaType (a-la CVE-2021-41190).

While you can derive this from the manifest pointing to it (and there's no real point to just pointing directly to an image configuration) it really would be nice for validation to be able to be done purely by looking at the blob itself. Not to mention that not having the version be self-describing seems like it's an opening for CVE-2021-41190-style issues where two systems might interpret the version differently (though I somewhat doubt this would happen).

The backwards compatibility path is kind of obvious -- if schemaVersion is empty, you assume that it's the same version as the manifest pointing to it. Historically this wasn't done because we wanted to maintain compatibility with Docker's image config format, but I suspect adding this at this stage is probably not the big of a deal?

[tianon]

I think CVE-2021-41190 was particularly nasty because it was about manifests and they're treated in "special" ways by registries/tools in order to calculate children, so the DAG itself might change based on how they're parsed. Blobs are kind of designed to have this "the content is what the parent object says it is" fluid relationship, so I'm not convinced -- is there a specific problem you're seeing / hoping to solve?

[sudo-bmitch]

Similar to Tianon, I'm not strongly opposed to adding these fields, but I'm also not convinced there's a problem being solved by adding them.

With manifests, it's possible to pull them without a descriptor referencing the manifest you are pulling (when you pull by a reference to a tag or digest, vs pulling a child of an index). With the blobs, there will always be a descriptor that references the blob, and the descriptor will have the media type of that blob. So I believe the interpretation of the content should never be ambiguous.

If we ever made a change to the config JSON that was not backwards compatible (versus adding a new field that only enables newer functionality), I would expect the version number within the media type to change, and not a schema version inside the JSON body. In other words, instead of changing a schemaVersion from 2 to 3, we could change application/vnd.oci.image.config.v1+json to application/vnd.oci.image.config.v2+json.