Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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
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.