image
image copied to clipboard
Perhaps reconsider or adjust MIME type enforcement on manifest parsing
manifest.Schema2FromManifest uses SupportedSchema2MediaType to verify s2.Manifest and layer.MediaType is recognized:
- At least comparing with OCI, might the intent have been to verify the config MIME type instead of (or, in addition to?) the MIME type of the manifest itself?
- OTOH, verifying that the manifest MIME type value is recognized before doing anything else with the data seems like a very useful sanity check.
- The check uses
SupportedSchema2MediaType, which recognizes all kinds of s2 MIME types. That seems unlikely to ever be precisely the check that is wanted; e.g. using a config MIME type for the manifest would be very surprising.- Should
SupportedSchema2MediaTypebe a public API, given the above? Who is going to call it?
- Should
- (Maybe except for the MIME type of the manifest), should we be hard-coding enforcement like this at all? The enforcement not forward-compatible. (OTOH, we should be enforcing recognized MIME types before expecting the referenced content to have any particular format, and this might end up being the best way to do that anyway.)
Most of this similarly applies to OCI.
OCI is no longer doing any MIME type checks of this kind, to allow OCI artifacts to work. (Some of the code is gated on m.Config.MediaType != imgspecv1.MediaTypeImageConfig, but that’s specific to individual operations.)