Is your feature request related to a problem? Please describe.
Currently Zarf uses a generic application/vnd.zarf.layer.v1.blob to describe every layer in the OCI manifest. This is confusing because many of these layers point to blobs with well-defined mediaTypes already.
Overloading application/vnd.zarf.layer.v1.blob makes the existing OCI manifests difficult to consume by other tooling. Preserving the mediaTypes for these layers makes it much easier to disambiguate the blobs.
For example, when implementing container image scanning, it would be great if we could just look for application/vnd.oci.image.manifest.v1+json layers as a starting point.
Along the same lines, the "harder stuff" would bring us inline with other CNCF/OpenSSF tooling and ultimately reduce the plumbing necessary to use things like trivy with Zarf packages.
Thanks for making this issue! I agree using more accurate media types for layers would be a boon.
A couple notes
If this was implemented then during partial pulls Zarf would have to check the version the package was published with to determine which media type to pull. Currently we grab the manifests from the index.json, then alter the descriptors to the Zarf media type so we can correctly pull. We'd only need that line for packages created before this change.
checksums.txt is necessary unless we create an alternative. Zarf packages are used outside of OCI, and when used on a signed Zarf package which has a zarf.yaml that holds a checksum of the checksums.txt file, it verifies that no tampering has happened within the package.
Is your feature request related to a problem? Please describe.
Currently Zarf uses a generic
application/vnd.zarf.layer.v1.blob
to describe every layer in the OCI manifest. This is confusing because many of these layers point to blobs with well-definedmediaTypes
already.Describe the solution you'd like
The Easy Stuff
images/oci-layout
:application/vnd.oci.layout.header.v1+json
images/index.json
:application/vnd.oci.image.index.v1+json
images/blobs/sha256/*
(as appropriate):application/vnd.oci.image.manifest.v1+json
application/vnd.oci.image.config.v1+json
application/vnd.oci.image.layer.v1.tar+gzip
zarf.yaml
: => (deprecate?) alternatives:zarf.json
usingapplication/vnd.zarf.package.config.v1+json
ZarfPackageConfig
could be included in the imageconfig
(we already have a customapplication/vnd.zarf.config.v1+json
)checksums.txt
: => (deprecate?)application/vnd.zarf.package.checksums.v1+json
manifest.layers[*].annotations
org.opencontainers.image.base.name
(i.e. source image tag) that the image blob is associated withThe Harder Stuff
sboms.tar
: => (attestation(s) using sigstore bundle format)application/vnd.dev.sigstore.bundle.v0.3+json
dev.sigstore.bundle.predicateType
annotation for disambiguating SBOM formats (ex.sbom.spdx.json
orhttps://cyclonedx.org/schema
)components/<component>.tar
: => (separate layer per chart, use Helm-native OCI format):application/vnd.cncf.helm.config.v1+json
application/vnd.cncf.helm.chart.content.v1.tar+gzip
application/vnd.cncf.helm.chart.provenance.v1.prov
application/tar+gzip
(legacy fallback)Additional context
Overloading
application/vnd.zarf.layer.v1.blob
makes the existing OCI manifests difficult to consume by other tooling. Preserving themediaTypes
for these layers makes it much easier to disambiguate the blobs.For example, when implementing container image scanning, it would be great if we could just look for
application/vnd.oci.image.manifest.v1+json
layers as a starting point.Along the same lines, the "harder stuff" would bring us inline with other CNCF/OpenSSF tooling and ultimately reduce the plumbing necessary to use things like
trivy
with Zarf packages.