Niels Basjes created COMPRESS-640:
-------------------------------------
Summary: Make zip/jar date and time reproducible
Key: COMPRESS-640
URL: https://issues.apache.org/jira/browse/COMPRESS-640
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Reporter: Niels Basjes
*Background*
When creating zip/jar/war files there is a growing need to make the build
reproducible.
Simply put: Anyone can repeat the build in the future and get the exact same
binary from the source (exact as in the hash of the zip is the same).
See also
* [https://reproducible-builds.org/]
* [https://github.com/jvm-repo-rebuild/reproducible-central]
*Problem with timezones*
One of the kinds of problems I recently ran into to make this happen is that
someone in a different timezone doing the build got a different binary because
the timestamps of the files IN the zip were different even though a fixed
timestamp (epoch) was provided.
It turned out that the rootcause was that in a few key places in Commons
Compress the local (system) timezone is used to convert the epoch into a local
timestamp that is placed in the zip file.
The code uses these for this: {{ZoneId.systemDefault()}} and
{{{}Calendar.getInstance(){}}}.
*Possible solution directions*
The need here is reproducibility and I see at least two ways to get there:
# Make the TimeZone/Calendar that is to be used configurable (which is a
backward compatible direction).
# Pin the TimeZone/Calendar to always use UTC instead of the system default
(simpler but not backward compatible).
*Workarounds*
So far I have seen two workarounds
The simple and relatively clean way is to set the timezone for the entire
project (mvn build) from the start.
Yet this is also this solution people choose ...
[https://github.com/spring-projects/spring-boot/commit/998d59b7ac1a75b26634e4fd2843a7833e554840]
What they do here is that they take the timestamp they want, shift it using the
local timezone the wrong way and then the underlying code in ZipUtil will shift
it back again which gives the desired timestamp in the zipfile.
I fully understand this solution and why they chose this (mvn plugins can run
in parallel in a single JVM and may not affect each other), yet I think this
should be made possible in a much much cleaner way.
Hence this improvement issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
