RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds
jan.lahoda at oracle.com
Thu Apr 30 12:50:04 UTC 2020
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:
>>> 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.  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
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).
>  https://reproducible-builds.org/specs/source-date-epoch/
>> There is some curious code that generates the timestamp with:
>> Could this use Instant.now().toEpochMilli() instead?
More information about the build-dev