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
