Fork me on GitHub
#depstar
<
2021-02-24
>
cap10morgan19:02:01

Is there a way to set the timestamp of the built jar file w/ depstar? Along the lines of Maven's reproducible build support: https://maven.apache.org/guides/mini/guide-reproducible-builds.html

seancorfield19:02:39

@cap10morgan Nope. Never had anyone request such a feature -- I've never even heard of such a feature.

seancorfield19:02:15

Is it supposed to set the creation timestamp to be something other than the time the JAR file was created? Or something else?

cap10morgan19:02:48

Yeah. Basically the idea is that if you build two different JARs w/ the same build commands against the same source code (on different machines, yadda yadda yadda), the hashes of the resulting JAR files will match. Not always important / necessary, but was looking into it for one of my projects.

cap10morgan19:02:41

so maybe timestamps of the JAR contents more than the JAR file itself

seancorfield19:02:28

I have a feeling that Clojure builds are inherently non-reproducible due to the "random" naming of anonymous functions during compilation? Or do they use a predictable hash value?

seancorfield19:02:26

Currently, depstar preserves the timestamp inside the JAR of the original file that was added into the JAR -- but any "directories" created inside the JAR have the timestamp of the JAR file's creation. The former is important to preserve timestamps on source and class files so Clojure knows when it loads files from the JAR whether it needs to recompile the source or not -- i.e., is the class file newer or older than the source file -- so overriding that sounds problematic from a Clojure p.o.v. (although I guess giving everything the same timestamp is probably "safe"? Still sounds wrong to me tho', messing with timestamps).

seancorfield19:02:20

I seem to recall there was some obstacle to setting the timestamp on the folder creation but I don't remember the details so I may be off...

seancorfield20:02:18

Hmm, I just ran a few uberjar tests and the names of anonymous functions look predictable for the same source code and dependencies...

ghadi22:02:52

there is some other non-determinism in compilation

ghadi22:02:10

This is something useful from taviso a star hacker on Google’s Project Zero

seancorfield22:02:35

I will confess to rolling my eyes when I hear talk of "reproducible builds" so this piece makes me feel better about that knee-jerk reaction 🙂