strip-jar goal breaks TAR entries
mabrarov opened this issue · 8 comments
It looks like strip-jar goal breaks entries in TARs:
- date / time is set to zero epoch time
- UNIX permissions are changed
This behavior makes strip-jar goal unwanted when I build TARs which I use with Dockerfile ADD directive to place files with correct permissions (my solution of https://medium.com/@lmakarov/the-backlash-of-chmod-chown-mv-in-your-dockerfile-f12fe08c0b55 issue) - refer to mabrarov/dockerfile-test.
Refer to feature/reproducible-buids branch of mabrarov/dockerfile-test for reproducing this issue. When project is built using this branch, I get:
$ docker run --rm -it -p 8080:8080 abrarov/dockerfile-test
docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"exec: \\\"/app/bin/run.sh\\\": permission denied\"\n".
because execute permission of start script - /app/bin/run.sh - is removed by reproducible-build-maven-plugin.
It would be helpful if strip-jar goal could:
- use commit timestamp like it's done for JARs
- keep UNIX permissions as is
when processing TARs .
Advantage of reproducible-build-maven-plugin is that it makes usage of TARs more Docker cache friendly and results in a better utilization of Docker layers.
Hi!
Thanks for reporting this problem. I'll have a look at it.
Hi!
I had a look at the code:
- date/time is set to 0 => it's an error, it should be set to the value of the "reproducible.zipDateTime" property. I'll fix it.
- UNIX permissions are changed: also true. I don't understand why. I'll fix it.
@Zlika, sorry for out of scope question, but isn't it more efficient to modify existing maven plugins (EAR, WAR, EJB, JAR, Assembly, Archiver, Plexus, etc.) and introduce additional options to change timestamps when building archives instead of strip (modification of built archive) approach (which looks like a temporary non-intrusive quick fix but not as a general solution)?
I know there is Reproducible JAR files project for Plexus Archiver (is it related to reproducible-build-maven-plugin?) and I have MASSEMBLY-918 with almost ready code changes (tests for the new code are missing).
Hi @mabrarov.
Changing the Maven ecosystem to allow reproducible builds is indeed the "right" thing to do, but it is not "simple". There is a pending initiative, mainly lead by @hboutemy (cf. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318), but it takes time to move such a big project. So this reproducible-maven-build plugin is a kind of "workaround" to wait until Maven has this feature built-in.
I've added a commit to fix your problem. Could you please compile and test the HEAD version to see if it's now ok for your use case?
Thanks.
Regarding
BUT the uid/gid are set to 0 and uname/gname are set to the empty string.
Take a look at MASSEMBLY-918 - it's different approach (the long way of changing Maven ecosystem and existing projects) but votes are appreciated.
I've added a commit to fix your problem. Could you please compile and test the HEAD version to see if it's now ok for your use case?
Checked. Fix works for me (refer to repro project and branch in description of issue).
Now I need to understand why my EARs are different b/w builds, but it's not related to this issue.
UNIX permissions are changed: also true. I don't understand why. I'll fix it.
Maybe there is some meaning in doing this, but it's definitely cannot be done by default (i.e. should be configurable). One would prefer to not care about permissions (playing with Maven Assembly plugin, for example) and just relay on reproducible-build-maven-plugin instead.