[
https://issues.apache.org/jira/browse/COMPRESS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695725#comment-17695725
]
Herve Boutemy edited comment on COMPRESS-640 at 3/2/23 1:58 PM:
----------------------------------------------------------------
this problem has been solved a long time ago in maven-jar-plugin,
maven-assembly-plugin and so on: see
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 and
more particularly https://github.com/codehaus-plexus/plexus-archiver/pull/121
(after discovery in https://issues.apache.org/jira/browse/MSOURCES-120 )
there is no problem in commons-compress (which does exactly the same work as
java.util.zip): it's adapted to low level zip format that was invented when MS
DOS was a thing, and did not know about timezone, then Unix zip/unzip command
working with timezone add a binary variability in zip stream that is unwanted
in Reproducible Builds
all Maven plugins that use plexus-archiver to create archives benefit from the
tweak: every other plugin that does their own work have to discover this
low-level fact from zip binary format (practically undocumented)
so to me: no problem for commons-compress (or eventually try to create a
documentation on zip format and timezones that people will understand: good
luck :) )
was (Author: hboutemy):
this problem has been solved a long time ago in maven-jar-plugin,
maven-assembly-plugin and so on: see
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 and
more particularly https://github.com/codehaus-plexus/plexus-archiver/pull/121
(after discovery in https://issues.apache.org/jira/browse/MSOURCES-120 )
there is no problem in commons-compress: it's adapted to low level zip format
that was invented when MS DOS was a thing, and did not know about timezone,
then Unix zip/unzip command working with timezone add a binary variability in
zip stream that is unwanted in Reproducible Builds
all Maven plugins that use plexus-archiver to create archives benefit from the
tweak: every other plugin that does their own work have to discover this
low-level fact from zip binary format (practically undocumented)
so to me: no problem for commons-compress (or eventually try to create a
documentation on zip format and timezones that people will understand: good
luck :) )
> 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
> Priority: Major
>
> *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)
