Reproducibility for Java -> technical details

[Roland Clobus]

On 13/11/2024 00:19, Vagrant Cascadian wrote:
> On 2024-11-12, John Gilmore wrote:
>> Roland Clobus <rclobus at rclobus.nl> wrote:
>>> My proposed change would be:
>>> * At startup of Java, check if SOURCE_DATE_EPOCH is set. If so, create
>>> a Clock.fixed with the timestamp from SOURCE_DATE_EPOCH
>>> * In java.util.Date replace System.currentTimeMillis() with
>>> Clock.getInstance().currentTimeMillis() (as suggested at [4] and other
>>> sources)
>>
>> The clock functions in Java shouldn't stop working because somebody set
>> a common environment variable.  This is hitting a fly with a
>> sledgehammer.
> 
> We've been hitting those flies with this particular mechanism for nearly
> a decade now and it is largely working as intended:
> 
>    https://reproducible-builds.org/docs/source-date-epoch/
> 
> SOURCE_DATE_EPOCH is not pretty or ideal, but it sure is pragmatic. I
> would rather people not embed timestamps, there are no timestamps like
> no timestamps! Moving forward sometimes requires making imperfect
> compromises...

Indeed, SOURCE_DATE_EPOCH overrides the value of 'now' with a value that 
the person that set the environment variable deemed more suitable.

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

Many programs will keep on working, they just have a different value for 
'now'. If you need to measure a duration, you should not use 'now-1' 
minus 'now-2', but use a monotonic clock, which is relative and 
therefore will (and should) not be affected by SOURCE_DATE_EPOCH.

>> A much less intrusive fix would be to provide a date option on
>> ca-certificates-java that would override the current date with
>> a date specified on the command line.
> 
> Having to patch each and every package to specify a bespoke build flag
> is really not feasible for tens of thousands (millions?) of packages...
> that sounds pretty intrusive to me.
> 
> Would I rather there be no timestamps embedded anywhere? Definitely!

However, the KeyStore class does not offer an API to explicitly set the 
timestamp, it always uses 'now'.
Even if such an API would have been available, what would the suitable 
value be? The timestamp of the file of the certificate, the timestamp of 
the symlink to the certificate, 'now' or something else?

You can see the timestamps:
keytool -list -cacerts -storepass changeit

It will break the file format, and possibly some other tools as well, 
but perhaps the file `cacerts` could work very fine without this timestamp.
However, as recently in a non-related discussion on debian-devel: 
"Chesterton's fence" -> someone might actually need this timestamp and 
assign something meaningful to its value.

With kind regards,
Roland Clobus
-------------- 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/20241113/37ee2c13/attachment.sig>