Closed glyn closed 5 years ago
I'm wondering if this change is robust given this observation: https://github.com/deislabs/duffle/pull/691#issuecomment-480893767. I need to investigate.
I need to investigate that PR again, but from what I recall, we can't rely on the digest calculated locally (as different registries can output different digests for the same content).
During bundle development, it may be ideal to omit the contentDigest field and/or skip validation. Once a bundle is ready to be transmitted as a thick or thin bundle, it must have a contentDigest field.
Based on a recent discussion in #cnab and to the spec, we proposed adding digest to the images on the first push, if any digest is missing.
(Note that this would be the only instance where push
would mutate the bundle).
What do you think?
Supplying any missing digest on first push is a partial solution, but it doesn't cover the case where the bundle is never pushed. With this PR the following scenario becomes possible:
In this case, the image's content digest ends up being that which was derived from the daemon and may (I'm still investigating this) therefore be subject to the risk pointed out in the other PR.
Without this PR, duffle export
will only succeed if the images have already been pushed and it will use the content digest produced by the (initial) registry.
It turns out we can't depend on the docker daemon forming the same digest as a repository. It seems to do at the moment, but that's just (bad IMO) luck. Closing.
This is implemented by bumping pivotal/image-relocation to pick up the docker daemon support.
Fixes https://github.com/deislabs/duffle/issues/828