pekko-http icon indicating copy to clipboard operation
pekko-http copied to clipboard

reproducible builds: timezone(?) leaks into build artifacts

Open raboof opened this issue 1 year ago • 3 comments

while trying to verify the reproducibility of the 1.0.1-RC2 artifacts, I ran into a difference: the jar files' entries (for example for pekko-parsing_2.13-1.0.1-RC2.jar) have an extra field of type 0x000a (https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/X000A_NTFS.html) containing file timestamps.

These timestamps are set to Sat Jan 01 00:00:00 CET 2000 on the staged release, while they are Sat Jan 01 01:00:00 CET 2000 on my local build - only the hour is different. It almost seems as if the intent was to have a fixed value here, but the timezone of the build machine is leaking into the artifact.

Changing the TZ environment variable during the build did not affect the timestamps, but building in a different build environment did produce the same timestamps - I still have to figure out what the relevant difference is.

raboof avatar Jan 29 '24 12:01 raboof

Last time I looked into these kinds of things, I think it was a combination of osgi, sbt-assembly, and sbt-reproducible-builds which created weird fields, but I cannot remember exactly. I remember weird code trying to synthesize these fields regarding the time stamps...

Since these fields seems to use an epoch style encoding of instants, is, what you are observing actually different timestamp longs in the files?

jrudolph avatar Jan 29 '24 12:01 jrudolph

This has affected us for a while. My usual timezone is Dublin but I'm currently in CET. It would be great to sort out where this diff comes from.

pjfanning avatar Jan 29 '24 12:01 pjfanning

I think this is caused by https://github.com/apache/commons-compress/pull/472

raboof avatar Jan 30 '24 23:01 raboof

Is still still an issue after https://github.com/apache/pekko-http/pull/488 ?

Philippus avatar Jun 07 '24 05:06 Philippus

Checked the 1.1.0-M1 artifacts, those are now reproducible for 2.13, so indeed the fix seems to have the intended effect.

I used:

sbt "set ThisBuild / net.bzzt.reproduciblebuilds.ReproducibleBuildsPlugin.reproducibleBuildsCheckResolver := DefaultMavenRepository; shell"
> reproducibleBuildsCheck

Filed https://github.com/raboof/sbt-reproducible-builds/issues/323 to make this a little easier

I also tried to reproduce for Scala 3, which showed two further problems:

  • #565
  • #566

raboof avatar Jun 07 '24 08:06 raboof