"Created" date for signature is always Dec 31, 0

[jackie-kinsler]

When signing images and pushing them to Google Cloud Registry, the signature's "Created" date is always Dec 31, 0.
I would have expected the "Created" date for the signature to be the date the container was signed.

printenv GCR_ACCOUNT | docker login -u _json_key --password-stdin gcr.io
cosign sign -key cosign.key $NAMESPACE:$version

[dekkagaijin]

We generally avoid unnecessarily breaking reproducibility whenever possible, which means setting such timestamps to a constant value. If there's demand for it, we could add a flag to timestamp the signature images

[patrickdung]

On GitLab, the signature or attestation files would be created as a very old date.
If the user enabled house keeping of container register (by tags), I am not sure if the signature or attestation files would be removed by house keeping.

[dlorenc]

I'd be fine setting this to a real value. Reproduciblity is good, but the signatures are random anyway.

What do people think? Setting a real time could be useful, with a flag for reproducible? Time seems like it would be better to set by default TBH.

[joshuagl]

I like the idea of using wall time by default and allowing clamping if an option is passed (maybe even using SOURCE_DATE_EPOCH from the environment?).

[dekkagaijin]

What's the main goal of adding the creation timestamp to the sig images?

I'd be worried about potentially misleading interpretation when an image has multiple signatures, if the goal is to associate a signature with the timestamp.

[dekkagaijin]

FWIW I'd also want to go through some formal design process and consider registry implementations if we just want to easily enable age-based garbage collection. Guess what contributed to "GKE's largest outage?"

[Lerentis]

On GitLab, the signature or attestation files would be created as a very old date.
If the user enabled house keeping of container register (by tags), I am not sure if the signature or attestation files would be removed by house keeping.

I can confirm that they do get removed 😅
Any update on the decision to change this behavior or giving the user an option to use the timestamp of the signing date here? This is really frustrating to be forced to choose in between signing and housekeeping

[dlorenc]

Cc @imjasonh who has been talking about timestamps lately

[imjasonh]

ref: docs for Gitlab Registry housekeeping: https://docs.gitlab.com/ee/user/packages/container_registry/reduce_container_registry_storage.html

I don't totally agree with Gitlab's decision to implement housekeeping in this way, but since they do, I think it makes sense to set the .config.created timestamp so these don't get reaped.

[Lerentis]

I tried to have a look where in the code base this date is set but I could not find it. Using reflect to modify the signature does not seem like a good idea, so if one could drop me a hint where to set this date I could try to create a pr for this issue (:

[imjasonh]

The reason you can't find code for setting that date is because we don't set that date anywhere, and the zero date is the default. Sorry that's a bit confusing.

The place where we'd set the time is probably in https://github.com/sigstore/cosign/blob/main/pkg/oci/mutate/signatures.go when we append a signature to the existing set of signatures. When there aren't any previous signatures, we append to an empty.Image (whose created date is zero), and if there are signatures we just append a layer (and don't update the created date).

So where we mutate.Append(base, ...), we should also mutate.Time mutate.CreatedAt to either the new signature's time, or just time.Now(). This will have the effect of setting the created-time when we add the first signature, and update the time when we append to the list.

edit: it looks like we might have an issue calling mutate.Time when the layer contents aren't tar files, as with our signatures. If that's a problem I can make a change in go-containerregistry that lets you ignore non-tar layers when mutating image time. cc @jonjohnsonjr

edit again: Nevermind, there's mutate.CreatedAt which only updates the created-at date, and doesn't try to read layers. This is exactly what we need.

[Lerentis]

Thanks @imjasonh , this seems longer than the implementation. highly appreciate your effort :)
PR here: #2108