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

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu May 7 15:48:04 UTC 2020


On 2020-04-30 14:50, Jan Lahoda wrote:
> On 30. 04. 20 14:29, Magnus Ihse Bursie wrote:
>> 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.
>
> I think a standard mechanism would be great. I don't think this patch 
> is very urgent, so I am happy to wait some time (rather than add a 
> timestamp to symbols and then remove it when there's a standard 
> mechanism).

JDK-8244592 is now in mainline, and you can start relying on 
SOURCE_DATE_EPOCH being present in the environment when building.

/Magnus
>
> Thanks,
>     Jan
>
>>
>> /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 compiler-dev mailing list