RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v20]

Andrew Leonard aleonard at openjdk.java.net
Fri Dec 10 20:30:21 UTC 2021


On Fri, 10 Dec 2021 19:16:49 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> Thanks, CSR now Finalized
>> 
>> Just a minor note: the CSR uses the adjective "extended" in three places for the DOS date and time field, but that field is actually a part of the original ZIP specification and not in an extended field. This implementation make a point never to touch the "Extended Timestamp Extra Field" defined in the 1997 [Info-ZIP Application Note 970311][1].
>> 
>> Maybe the confusion was from the required ISO 8601 extended format (rather than basic).
>> 
>> [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/zip/ZipEntry.html#setExtra(byte%5B%5D)
>
>> @jgneff John, I know you have an interest in this, what is your urgency for this support? jdk-18 or 19 ?
> 
> It's not urgent. I'm just being impatient. ��
> 
> If this pull request is integrated only into JDK 19, JavaFX won't be able to support reproducible builds until OpenJFX 20 in March 2023. Java projects in general are late to the reproducible builds party. Debian, for example, builds 31,571 packages and [less than three percent fail][1] to build in a reproducible manner. Those failing packages include OpenJDK and OpenJFX. Debian plans eventually to make [reproducibility a requirement][2], and other distributions may follow.
> 
> The only true urgency, of course, is to provide Java project owners better tools to detect the next supply chain attack on the packages they distribute.
> 
> [1]: https://tests.reproducible-builds.org/debian/bookworm/index_suite_amd64_stats.html
> [2]: https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility

@jgneff thanks John, i'm going to raise the JEP 3 request and see where I get, as I concur with your statement:

> The only true urgency, of course, is to provide Java project owners better tools to detect the next supply chain attack on the packages they distribute.

The risk is minimal, also given the extensive testing we have done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481


More information about the core-libs-dev mailing list