I'm wondering if this change is robust given this observation: #691 (comment). 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:

1. Build a bundle (but don't push the invocation image)
2. Export the bundle as a thick bundle (which will read the image from the daemon)
3. Relocate the thick bundle
4. Install the thick bundle with the relocation mapping from the previous step.

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.