search

cnabio / cnab-spec

Cloud Native Application Bundle Specification
https://cnab.io
Other
957 stars 99 forks source link

docs(101-bundle-json.md): add clarification around contentDigest value #384

Closed vdice closed 4 years ago

vdice commented 4 years ago

Proposed fix for https://github.com/cnabio/cnab-spec/issues/287

SteveLasker commented 4 years ago

Curious why the digest is required to be consistent with the tag. While deploying unique tags is a best practice to have consistent deployments across a scale unit, locking to the digest blocks the "break glass" servicing capability. I get that some use docker-lock type rules until we have a better signing, or standard tag locking capability. Just suggesting this shouldn't be a hard requirement.

As a minor point, some of the references refer to "image":"example/microservice:1.2.3" This is a bit confusing. Is this the default docker hub behavior where no registry = docker.io? Or, does the bundle support finding the image in the registry where the CNAB bundle was pulled from? There's some later examples of: "image": "example.com/example/vote-frontend@sha256:aca460afa270d4c527981ef9ca4989346c56cf9b20217dcea37df1ece8120685", Would suggest fully qualified names, if that's what it means, or better yet, support reference artifacts to the registry where the CNAB was pulled enabling better transportability.

For the image reference, the spec states:

The following OPTIONAL fields MAY be attached to an invocation image: size: The image size in bytes. Implementations SHOULD verify this when a bundle is packaged as a thick bundle, and MAY verify it when the image is part of a thin bundle.

Would suggest requiring the full OCI Descriptor information, where digest, mediaType and size are required.

vdice commented 4 years ago

@SteveLasker good points, all. Please feel free to create follow-up issues for spec amendments/proposals mentioned. However, the scope of this changeset is simply to clarify the expected value of the contentDigest field when the invocation image type is docker/oci.

chris-crone commented 4 years ago

Hmm, interesting. Would this break Signy's verification behaviour, @radu-matei? I suppose not unless you consider copying images between different registries?

I remember having discussions about this with @radu-matei so I think he likely implemented Signy with this definition in mind