On Wed, Nov 13, 2024, at 00:19, Vagrant Cascadian wrote: > On 2024-11-12, John Gilmore wrote: > > Roland Clobus <[email protected]> wrote: > >> It should be noted that regular user _will not_ and _should not_ set > >> SOURCE_DATE_EPOCH [6]. That environment variable it typically used for > >> rebuilds. > > > > Certainly many programmers will set the variable, particularly during > > development or debugging sessions. And they will and should expect the > > ordinary programs that they run in that shell to keep working -- whether > > they are written in Java or not. > > What about C? It has been the default behavior in GCC and CLANG for > years. Numerous other programming environments as well. > The vast majority of reproducible builds fixes are from various > toolchains respecting SOURCE_DATE_EPOCH.
We're not talking about the Java compiler here, but about the Java runtime environment - so the equivalent would be to recommend the libc date and time functions to honor SOURCE_DATE_EPOCH. While there's something to be said for that as well, it's a bit more extreme. ca-certificates-java has some Debian-specific Java code that uses the JDK KeyStore APIs to create a keystore (https://sources.debian.org/src/ca-certificates-java/20240118/). As Roland mentions above, the JDK JavaKeyStore implementation uses 'new Date()' to put the 'current' date into the 'date' field of the KeyEntry ('the creation date of this entry'). The KeyStore APIs don't seem to provide a way to influence that value, and it ends up in the end result. This means AFAICT adding a flag to ca-certificates-java like John suggests as an alternative is not really possible without changes to the KeyStore API in the JRE. Perhaps a nice middle ground would be for the JavaKeyStore implementation to honor SOURCE_DATE_EPOCH for the date of the key entries? https://reproducible-builds.org/docs/source-date-epoch/#java--gradle Kind regards, -- Arnout Engelen Engelen Open Source https://engelen.eu
