RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Apr 30 12:29:17 UTC 2020


On 2020-04-30 12:41, Alan Bateman wrote:
>
>
> On 30/04/2020 08:03, Jan Lahoda wrote:
>> Hi,
>>
>> The building of lib/ct.sym is not reproducible, due to timestamps of 
>> files inside the file (which is basically a zip file).
>>
>> The proposed solution is to use a constant timestamp for the files 
>> inside the ct.sym file. To simplify the construction, the 
>> CreateSymbols tool does not produce files on the filesystem anymore, 
>> but rather constructs the ct.sym directly.
>>
>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8241616/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241616
> 1587656816359 = 2020-04-23T15:46:56.359Z. Is there anything 
> significant with this timestamp? Magnus might have suggestions but 
> maybe it would be saner to pick up the value of DEFAULT_VERSION_DATE.
There is an officially suggested standard, SOURCE_DATE_EPOCH for 
reproducible builds. [1] I have long-term vision to include this in the 
entire JDK build, but has of yet not even started on that. :-(

This might be a good first step to start using it. I can assist in 
making the needed makefile changes to have that environment variable 
available.

/Magnus

[1] https://reproducible-builds.org/specs/source-date-epoch/
>
> There is some curious code that generates the timestamp with:
>    Long.toString(FileTime.from(Instant.now()).toMillis())
> Could this use Instant.now().toEpochMilli() instead?
>
> -Alan
>
>




More information about the build-dev mailing list