Re: debian java BoF - 2014/08/25
Emmanuel Bourg <firstname.lastname@example.org> writes:
> Le 28/08/2014 00:24, tony mancill a écrit :
>> Reproducible builds:
>> There is interest in having reproducible builds of JARs (timestamps are
>> a problem - perhaps other attributes as well?). There will be some
>> hacking in this area; the team will then assess integrating this into
>> our packaging toolchain.
> I'd like to highlight that the timestamp are sometimes useful for
> debugging issues. For example, when a package embeds other libraries in
> its jar, the timestamp on the class files may be used to guess what
> version of the dependency has been embedded (see #729171 for example).
That sounds like a problem in search of a better solution, like embedding
the actual version of the dependency in the metadata somewhere.
> Instead of developing a tool that strips the timestamp and sorts the
> content of the jars (like sortjar in ITP #759822) I'd rather suggest
> developing a tool that computes the checksum of a jar by ignoring the
> variable elements.
This has a few significant drawbacks:
1. One can no longer verify the reproducibility of a build by simply
verifying a hash matches. Now one has to use a custom tool. This
means that verification is not composable. The current reproducible
build work has a goal of producing the same *.deb file with the same
checksum, since that's what makes verification easy. That would be
impossible with this approach, which I think would significantly
undermine the utility of this work.
2. This is a Java-specific approach. If we add language-specific
approaches for each build artifact, this will quickly become complex to
the point of no longer being tenable.
3. The existence of variable elements in the build artifact becomes a
back-channel to leak information from the build environment. While
this isn't a major issue, there are a variety of security reasons for
reproducible builds and, in some scenarios, it's desirable to not leak
any information out the build environment. (I realize this is directly
contrary to the traceability of the build when debugging problems.)
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>