Removing ModTime will reintroduce behavior described in #4158, which was fixed in #4161 and ported to V3 in #7272

IMHO, the current implementation of modTime is also wrong because it just sets the time when helm package was run. If it wants to be correct, it should set the original template files timestamp.

Also, zero-ing out timestamps is a common pattern for reproducible builds GoogleContainerTools/distroless#242

Regardless, @baijum is right. We tried this, and someone reported it as a bug that was addressed with #4161. To go back and re-implement this again would be repeating past mistakes.

May be this can be added as a flag to helm package command for those of us want to have reproducible charts.

Everyone wants a reproducible build. It does not need to be hidden behind a flag. What I am trying to convey is that stripping mtime from the file is NOT the right way to go about addressing the issue.

#3612 (comment) suggests the issue is not due to timestamps, but instead the sorted order of the files within the tar file.

Can you please look further into the suggestions made in that thread before coming up with a solution. Even if you strip mtime fields from the archive, you may still not produce a reproducible build. We've looked into this issue multiple times and discovered it's not the mtime of the original files causing the issue here. Or at least, there are multiple layers causing this issue, and to solve it we need to address them all.

We tested this theory in another area and discovered stripping mtime from the archive does not resolve the issue. See #8216 (review).

In other words, it is possible that

1. preserving the original file's mtime, and
2. sorting files by name (as you've done so in this PR)

May fix this issue. but without any test infrastructure in place to confirm, we cannot prove it.

If you're attempting to fix something, please provide tests to ensure that your change addresses the issue.

Can we add a backwards-compatible flag, like helm package --timestamp where timestamp defaults to true, but users can set it to false for reproducibility on that level.

As discussed in the developer call today, the first step would be to write a test to identify the symptom. Then write a fix to alleviate the symptom.

It is possible that we only need to sort the files in the archive to fix the issue, which means there would not be any need for stripping file mtimes (and therefore no need for a --timestamp flag).

We did test the theory of stripping file mtimes before and that did not allay the symptom. @jdolitsky can also attest to this as he and his coworker tried to fix this for helm chart save. So I'm not confident that stripping file mtimes will fix the problem.

Let's get some tests in first before we start providing solutions.

This should be tried without the timestamp going to 0. But, I suspect any timestamp difference will cause a different hash. A different time stored in the tar when everything else is the same is still different content that would produce a different hash.

In another part of the PR there is sorting on the content. The order of the files matters and I hope the change here solves the issue. I have not checked, though.

If the timestamp needs to be 0 then that would need to be hidden behind a flag. We can't break backwards compatibility. I would suggest a name like --reproducible-build.

Please be aware that Git doesn't preserve modification time on files. So an Application Distributor cannot create a reproducible build by preserving the original file's modification time because the modified time will be different whenever the chart source checks out. I think using a flag (--reproducible-build) and setting timestamp to 0 looks acceptable to me—some tests to avoid regression would be great.