desruisseaux commented on PR #1726: URL: https://github.com/apache/maven/pull/1726#issuecomment-2373444529
Correct me if I'm wrong, but it seems to me that one of the main goals of reproducible build is security: allowing developers to verify that the released JAR files do not contain altered byte codes (e.g. malicious code injected by a compromised compiler). For this goal, the timestamp of ZIP entries does not matter. Only the content of ZIP entries matter. In my understanding, a verification focussed on what matter is called "semantically reproducible build" or "semantic equivalency". [Microsoft seems to propose a tool for semantic equivalency](https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible) at least for NPM packages. Are we pushing a bit for bit reproducible build because we have no easy tool for semantic equivalency? If yes, what about instead developing a new Maven plugin or modifying `maven-deploy-plugin` with a new goal? Instead of deploying to the server, it would download from the server and compare the ZIP **content**. Differences in timestamp and compression would be ignored. We could also ignore a limited set of `META-INF` attributes. This proposal would allow the following workflow during release: the release manager deploys the JAR files on a staging repository and give the URL to other developers. Other developers would use that URL with the above-cited new plugin, which would automatically build the project and compare semantically with the JARs on the staging repository. >> as a developer, I want to build my source code twice and get the same output (which will also help build-cache) > To be honest I never wanted that in the last 10+years :-D Same for me. What I want is security check. Actually, I would rather not desire bit for bit reproducibility, as I would find more useful to keep the (non-standard) `Built-By` and `Built-On` attributes in `META-INF` with accurate values if it can be done without compromising security. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
