Reproducibility for Java

[Roland Clobus]

Hello Chris, list,

On 08/11/2024 20:50, Chris Lamb wrote:
> 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.

Indeed, the source of the non-reproducible file is coming from the 
postinst step of ca-certificates-java. However, none of the code from 
that package needs adjustment, the fix needs to be applied to openJDK 
(as the 'new Date()' calls are in openJDK itself.

>> 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.

Changing Java (just for Debian) will possibly have undesired, 
unmaintainable side-effects, which I cannot oversee, so those need to be 
tested and approved by upstream.

But a stopgap is required too, to get a reproducible live image sooner.

> 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.

After the regular postinst has run, I can run the postinst step again 
but then with faketime active.
There is sufficient control over the order of the installation of 
packages, that it is possible to ensure that the faketime-based version 
will be embedded in the live image.
This will fulfil the need in the live image, but will not be a general 
solution.

Generally, it would be possible to use faketime in the postinst, with 
the same value as SOURCE_DATE_EPOCH.
I would propose faketime as a 'Suggests:' dependency for the package. 
Then only when _both_ faketime is installed _and_ SOURCE_DATE_EPOCH is 
set, the faketime will be applied.

> 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?

The package live-config is the package to use for such first-run steps 
as (re)generating files.

As the stopgap method, I'll go with the faketime version of the postinst 
step, as that will cause no additional startup-delay for the live image. [1]

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

I'll send a mail to the maintainers and debian-java later.

Thanks for thinking along,
With kind regards,
Roland

[1] https://salsa.debian.org/live-team/live-build/-/merge_requests/385
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20241112/e540362a/attachment.sig>