[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reproducible jar archives.
From: |
Ludovic Courtès |
Subject: |
Re: Reproducible jar archives. |
Date: |
Fri, 01 Jan 2016 16:51:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Ricardo Wurmus <address@hidden> skribis:
> These archives are created by the “jar” tool, which is part of the JDK;
> they can also be created by “fastjar”, an alternative implementation in
> C.
>
> Unlike “tar” the “jar” tool does not support anything like the “--mtime”
> flag, so file modification dates cannot be reset before packing. Also,
> the manifest is usually generated automatically (unless manually
> provided) and the generated directories and the manifest file itself
> have uncontrollable timestamps.
See also
<https://wiki.debian.org/ReproducibleBuilds/TimestampsInJarFiles>.
Debian leaves jar/fastjar unchanged and instead runs
‘strip-nondeterminism’ to remove the timestamps.
> For Java projects without a build system this is not so bad: we can
> generate our own build.xml and build the project with Ant. The
> build.xml would just have to run a command to reset the modification
> time of all files before archiving them. (This is what my WIP
> ‘ant-build-system’ does and packages built with it are, in fact,
> deterministic.)
OK.
> For many non-trivial projects, however, we have no way to easily inject
> a phase before “jar” is called, because of some indirection through
> build plugins (in the case of Maven projects) or because of a convoluted
> build.xml for Ant, which may use different Ant tasks to package the
> “.jar”. I only came up with two ways to get around this problem:
>
> * build the “.jar” archive as usual, then unpack it, reset all file
> timestamps, and archive them again (this time without generating an
> additional manifest)
>
> * patch up the “jar” tool so that it resets the mtime for archive
> contents.
>
> The first approach might work if we can reliably find a point in the
> build process where all “jar” archives have been created (after the
> “build” phase?). It’s an ugly solution because we have to do so much
> more work for every “jar” (unpacking, touching, and repacking can take a
> lot of time and space for big projects).
Yeah. ‘strip-nondeterminism’ essentially does that, I think (or with
some knowledge of the zip format, since that’s what Jar is, it could
directly modify the timestamps therein; Göran Weinholt’s Industria has
Scheme code to deal with zip files, FWIW.)
> The second approach is tempting. I looked at the “fastjar” code and
> making it set the file modification time is trivial; of course this must
> be optional (e.g. when a certain environment variable is set) lest this
> affects operation under normal conditions. But it’s also really hacky.
>
> I haven’t looked at the sources for the JDK-provided “jar” tool yet, so
> I cannot say if that would work.
Maybe we could modify jar & fastjar to honor SOURCE_DATE_EPOCH and even
submit the change upstream for discussion.
> What do you think about this? Other ideas maybe?
It may be worth discussing with the other “reproducible build” folks at
<https://lists.reproducible-builds.org/listinfo/rb-general> and/or on
#reproducible-builds on OFTC. They probably have useful ideas!
Thanks,
Ludo’.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Reproducible jar archives.,
Ludovic Courtès <=