Adds HELM_OCI_DATE_EPOCH wich can be use to reproducibly push a Helm chart to an OCI registry

[inteon]

Currently, when using helm push, the creation time of the Helm tar file is used. This makes it impossible to push the same chart twice reproducibly. This PR introduces HELM_OCI_DATE_EPOCH to overwrite the timestamp used.

What this PR does / why we need it:

This environment variable allows us to reproducibly create and push a Helm chart:

$ helm pull jetstack/cert-manager
$ HELM_OCI_DATE_EPOCH=0 helm push ./cert-manager-v1.15.3.tgz oci://localhost:5000/test123
Pushed: localhost:5000/test123/cert-manager:v1.15.3
Digest: sha256:ce96368a62b8c8a68518df374e853677210ffd7f34ca8eb57112eb6ac28b61c8
$ touch cert-manager-v1.15.3.tgz 
$ HELM_OCI_DATE_EPOCH=0 helm push ./cert-manager-v1.15.3.tgz oci://localhost:5000/test123
Pushed: localhost:5000/test123/cert-manager:v1.15.3
Digest: sha256:ce96368a62b8c8a68518df374e853677210ffd7f34ca8eb57112eb6ac28b61c8

[TerryHowe]

Wouldn't it be easier to just change the create time of the file?

[inteon]

Wouldn't it be easier to just change the create time of the file?

Is there a straightforward way to do this on linux?

As far as I can see, creation time is not part of POSIX.
Instead, the value used Stat_t.Ctim is the "inode change time" (see https://stackoverflow.com/a/67708814).
This value cannot be set to a arbitrary value (see https://unix.stackexchange.com/a/132661).

[TerryHowe]

I thought Ctim was ctime, so I may be off

[gjenkins8]

If I had to speculate, the intent here was to use Chart's archive file's "created" time. But, to spell out the above, this is not seemingly what is happening here:

ctime.Created() function is returning st_ctim (on Linux). Which, as @inteon correctly points out, the "Time of last status change" (man stat). Or the "when the inode was last changed" time. And so not really a "created" time IMHO.

This mismatch in the functions name and its actual behavior, I think is causing confusion here. Semantically I think a "created" time corresponds to the files modified time. Helm cares when the files content was last written.

I thought Ctim was ctime, so I may be off

ctim is ctime (but not "created time" :) ). POSIX.1-2008 introduced nanosecond precision:

struct timespec  st_ctim;  /* Time of last status change */
#define st_ctime  st_ctim.tv_sec  /* Backward compatibility */

---

Wouldn't it be easier to just change the createmodified time of the file?

Overall, I think this is a simpler proposal. And perhaps the correct solution. Setting a file's time can be done easily, like e.g. touch -m -t 197001010000.00 chart.tar.gz. But it would have to be agreed that the "Time of last status change" is not the correct way to determined a charts "created" time. And e.g. the chart file's "modified" time was.

Overall, I think it would be preferable to fix the existing behavior if possible. Rather than introduce a new thing to work around. So it would be great if we could classify the existing behavior as a "bug" and fix that IMHO. Then folk who want deterministic (reproducible) OCI digests have a path forward.

edit: reworded for clarity

[gjenkins8]

@sabre1041 -- thoughts on the above?

[sabre1041]

@sabre1041 -- thoughts on the above?

#12903 was introduced to achieve a constant creation time based on the time the package was created. I agree that the best approach forward is to correct the existing behavior instead of introducing a workaround/new functionality

[gjenkins8]

I created: #13376 (which changes the behavior to utilize the files modified time)