On 13/11/2024 00:19, Vagrant Cascadian wrote:
On 2024-11-12, John Gilmore wrote:Roland Clobus <[email protected]> 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 changeitIt 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
