Created should be omitted from image json

[vishvananda]

It is preferable for container images to build reproducibly, which means content shouldn't be dependent on build time. It is possible to ignore Created when building ocis since it is optional, or to set it to a standard value, but it seems that including it in the spec is just inviting people to build images in a non-reproducible way. One could make a similar argument against the Created in the history section.

[vishvananda]

Ideally, build date is metadata that is stored separately from the image.json, perhaps as part of #176

[wking]

On Wed, Oct 19, 2016 at 01:39:52PM -0700, Vish Ishaya wrote:

… but it seems that including it in the spec is just inviting people
to build images in a non-reproducible way.

Many from-scratch builds are going to be non-reproducible for other
reasons, and in that case you may be interested in setting the field.
We could make it less prominent by switching to annotations (or
similar, #371, #372) and applying the usual annotations boilerplate
(including org.opencontainers.created) 1, but that would be a
reasonable syntactic departure from the Docker schema. Translation
shouldn't be too bad, but there has been pushback against simple
translation in the past 2.

If for whatever reason translation is ok in this instance, I'd be in
favor of landing #372 and pointing folks at
org.opencontainers.created. And this wouldn't be a problem at all if
we just drop the config format in favor of runtime-spec's config 3,
which would solve #329, #371, #372, and #375 and make image-spec
maintainer life easier all in one fell swoop ;).

[stevvooe]

@vishvananda While, ideally, we'd like our images to build reproducibly, the reality is that there is always something in the way to break this guarantee. Thus, if we rely on that property, we make the system hard to modify and sensitive to bugs that create artifact instability. On the other end of this, trying to reduce the input to the hash function increases the likelihood of collision, reducing the security of CAS.

In practice, the image config is small enough to the point that this doesn't actually matter. The large data, in layers, is stored separately, and can be stabilized with techniques like tar-split.

I propose we close this issue. In the very least, we can make these fields optional, but I don't recommend it.

[wking]

On Tue, Oct 25, 2016 at 11:18:07AM -0700, Stephen Day wrote:

On the other end of this, trying to reduce the input to the hash function increases the likelihood of collision, reducing the security of CAS.

There are two reasons for hash collisions:

a. You're hashing the same content. Collisions because of this are a good thing (#339).
b. Your hash function returns the same value for different content. Collisions because of this are a bad thing.

Dropping Created makes (a) more likely, but that doesn't effect CAS security. I see no reason why dropping Created would make (b) more likely; if you do can you elaborate?

In the very least, we can make these fields optional, but I don't recommend it.

created is already optional.

I agree with your point that there are lots of other reasons for potential hash changes (e.g. you have a different history entry or a different diffID). I'm fine leaving created alone and letting folks who don't want it not set it. I'm also fine moving created, history, and other metadata not important to running the container into annotations (or some such, #371, #372) to downplay their importance in the hopes that that increases type-(a) hash collisions and saves some bandwidth and disk space.

[philips]

This field is already optional. I am going to close this.