Hi. if web-download cache be in part of your, Reproducible Builds? Jorge Solórzano <jor...@gmail.com> 于2024年9月25日周三 22:26写道：
> There are some solutions/alternatives here: > > 1) Fixed value by default. > 2) Warning to the user for having reproducible builds off. > 3) Use the SCM last commit date. > > I have worked a tiny bit for the Reproducible Builds effort so here is my 2 > cents: > > * Using the SCM last commit date is a bad choice, not everyone will use SCM > or the source code could be downloaded without scm information (eg.: Source > Code download links from GitHub), so this is a -1 for me. > * Throw a warning to the user to force the set of the project.build > .outputTimestamp value is also a -1 for me, this reminds me of the project. > build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and > having that default value is the correct way to proceed instead of an ugly > warning. > * This leaves us with the fixed value by default, the current value (in the > PR) is 2001-01-01T00:00:00Z.... this is a good approach, but my personal > preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed. > > There should be a way to opt out of this and get the previous behavior for > those that don't what this. > As fo the release plugin, it should simply use the fixed date (if the > property is not set), having a warning seem ugly the same way as the > sourceEncoding warning was ugly. > > Now, in my experience, sometimes setting the outputTimestamp is not enought > and is not a silver bullet to make a reproducible build. > > So just to be clear, what is the really the end goal of enabling it by > default? I know the advantages and benefits, but what would be the goal of > having this opt-out instead of having it opt-in? > > > > On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit : > > >> > > >> For me this looks more like an issue of the jar plugin and should > > >> probably be handled there, then even though I wonder why the zip > > >> entries need a timestamp for a jar to be reproducible, should it not > > >> be enough to compare the zip-entries and leave the timestamp alone? > > >> > > > The idea of a reproducible build is to create binary exact artifacts > > > which you can quickly calculate checksum to compare with some > > > reference build. As the timestamp entry is used in zip/JARs, it > > > changes the binary representation of a jar as well. So yeah, that's > > > important. > > > > > (note: I'm duplicating here a comment I just made on the PR). I guess > > that checksum is not a goal in itself, but the higher level goal is > > security (checking that a JAR file has not been compromised)? If yes, > > then we do not necessarily need bit for bit reproducibility. > > "Semantically reproducible build" or "semantic equivalency" can be as > > good or even better, as it does not force us to throw away useful > > metadata like the real build time. Microsoft has short discussion about > > semantic equivalency there: > > > > https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible > > > > Could the real issue be that we do not have a Maven plugin for making > > semantic equivalency check easy? E.g. a plugin that build a project and > > automatically compare semantically against the JAR file on Maven Central > > or elsewhere? > > > > Martin > > > > >
