Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reproducible builds: timezone(?) leaks into build artifacts #457

Closed
raboof opened this issue Jan 29, 2024 · 5 comments
Closed

reproducible builds: timezone(?) leaks into build artifacts #457

raboof opened this issue Jan 29, 2024 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@raboof
Copy link
Member

raboof commented Jan 29, 2024

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 raboof added the bug Something isn't working label Jan 29, 2024
@jrudolph
Copy link
Contributor

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?

@pjfanning
Copy link
Contributor

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.

@raboof
Copy link
Member Author

raboof commented Jan 30, 2024

I think this is caused by apache/commons-compress#472

@Philippus
Copy link
Contributor

Is still still an issue after #488 ?

@raboof
Copy link
Member Author

raboof commented Jun 7, 2024

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 raboof/sbt-reproducible-builds#323 to make this a little easier

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

@raboof raboof closed this as completed Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants