use timestamp from commit in tarballs to make archive downloads reproducible

[eighthave]

Right now, when downloading from an +archive link, the resulting .tar.gz file is entirely the same except for one trivial difference: the timestamps in the tar file listing. It seems that the current time is used. To see this, do:

$ wget https://android.googlesource.com/platform/frameworks/native/+archive/android-10.0.0_r36.tar.gz
$ mv android-10.0.0_r36.tar.gz first-android-10.0.0_r36.tar.gz
$ wget https://android.googlesource.com/platform/frameworks/native/+archive/android-10.0.0_r36.tar.gz
$ tar tvzf first-android-10.0.0_r36.tar.gz | head -1
-rw-r--r-- 0/0             349 2020-11-22 16:29 .clang-format
$ tar tvzf android-10.0.0_r36.tar.gz | head -1
-rw-r--r-- 0/0             349 2020-11-22 16:35 .clang-format
$ diffoscope  first-android-10.0.0_r36.tar.gz android-10.0.0_r36.tar.gz

Instead, I propose setting the timestamp to the timestamp from the commit that is being archived. So for the android-10.0.0_r36 tag, that would be Sun Jan 12 00:16:24 2020 +0000. With this trivial change, the downloaded tarballs would be the same every time.

[eighthave]

It seems that this issue was fixed in JGit, but is still present in Gitiles:

• https://git.eclipse.org/r/c/jgit/jgit/+/144172
• https://git.eclipse.org/c/jgit/jgit.git/commit/?id=9387288a8612eb9e9478c5ecfe4b1351a0ed4717

Yes, there might always be changes in the future that change the compression algorithm. But this issue is referring to something that can be fixed once and for all. And that increases the chances that the SHA-256 will remain the same. And it also makes comparing different versions of the same release tarball much easier, since there would only be a diff in the compressed stuff, not in the contents.

[vapier]

this is a dupe of #84 basically

[eighthave]

IHMO #84 is perhaps broader than this issue, though this issue does fit under #84