Reproducibility for Java

[Chris Lamb]

Roland Clobus wrote:

> Should production runtime environments 
> be sensitive to SOURCE_DATE_EPOCH (instead of during building)?

Starting with this bit first: given the context of your question is in
relation to building live images, I assume that installing the
ca-certificates-java package is the source of the non-reproducibility…
presumably via the postinst script doing some processing.

Indeed, yes, this seems to be the case:

  https://salsa.debian.org/java-team/ca-certificates-java/-/blob/master/debian/ca-certificates-java.postinst

If so, then I agree in general and specific terms: I believe that
preinst and postinst scripts should be deterministic, and I've filed
many such bugs in the past to make them so, chiefly in the process of
getting Tails reproducible.

> What strategy would you propose? [The package] embeds timestamps for
> 'now' in /etc/ssl/certs/java/cacerts.

Hm. Given that the codebase calls 'new Date()' in a bunch of places,
then I think that any of the options that propose changes to Java are
not going to be visible in the short- or medium-term because of the
time it would take for those changes to filter down to Debian. They
are, of course, worth pursuing; but I suspect you would also like a
stopgap situation as well.

Using faketime would of course 'work', but are you proposing that the
maintainer of the ca-certificates-java patch their postinst to always
use faketime? Otherwise, I am not sure how you would ensure that this
bit was called within the faketime environment only when building your
live image.

Now I do like your idea of not shipping the unreproducible file, and
it would be especially elegant if the package worked with or without
the file(s) being present. But I don't think that is the case: the
very point is that it generates these files in a known place on the
filesystem so that other programs can access them.

Similarly, I don't think this package has any broader concept of a
'first run' in which it could be generated if it doesn't exist. You
can't even be 100% sure that these files will only be accessed by a
Debian-shipped Java runtime.

But I do note that the update_cacerts method is called in that
postinst when a new Java runtime is installed. The very fact that this
is abstracted out is promising. I wonder if you could: (a) remove the
offending file as you outline; and then (b) call this very method
during the live script's boot, perhaps by manually invoking the dpkg
trigger that is meant to be for when a new JRE is installed?

Lastly: the package's maintainers may have a more elegant solution,
so it might be worth looping them in.


Best wishes,

-- 
      o
    ⬋   ⬊      Chris Lamb
   o     o     reproducible-builds.org 💠
    ⬊   ⬋
      o