Re: debian java BoF - 2014/08/25

[Russ Allbery <rra@debian.org>]

Emmanuel Bourg <ebourg@apache.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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>