On Fri, 30 Apr 2021 00:10:30 GMT, John Neffenger <jgn...@openjdk.org> wrote:
>> This is a continuation of the [pull request][1] started by @bmwiedemann in >> January 2020. After this change is integrated, I can follow up immediately >> with additional pull requests that get us much closer to providing fully >> reproducible builds. >> >> #### Motivation >> >> The only conclusive way to verify a software package is to reproduce it. >> That's the main point of the Linux Foundation article [Preventing Supply >> Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source >> Supply Chain Security. "In the longer term," he writes, "I know of only one >> strong countermeasure for this kind of attack: verified reproducible builds." >> >> It's not enough anymore to trust the person, organization, or company that >> publishes a software package. David Wheeler explains, "Assuming a system can >> 'never be broken into' is a failing strategy." As I see it, any project that >> doesn't yet allow for reproducible builds is on a list of possible attack >> vectors. I'd like to get OpenJFX off that list. >> >> This is a huge undertaking involving the entire open-source community. Just >> [Debian, for example][3], has over 30,000 source packages to build in a >> reproducible manner. Remarkably, it's almost 96 percent complete. The >> OpenJFX package is one of three percent still failing. Our first step >> towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` >> specification][4]. >> >> #### Implementation >> >> When you want to build 30,000 packages in a reproducible manner, >> [command-line flags][5] unique to each package aren't so helpful. The >> environment variable needs to be set, anyway, for the tools invoked by >> Gradle to pick it up. We could allow for a Gradle property in addition to >> the environment variable. The Gradle property would override the default >> current date and export the environment variable, and the environment >> variable would override the command-line property. I think it makes more >> sense in the OpenJFX build to support the environment variable directly. >> >> With these considerations, I added the support just as recommended by the >> example for "Java / gradle" on the Reproducible Builds >> [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does >> the reverse, using the *configure* script option `--with-source-date` to >> export the `SOURCE_DATE_EPOCH` environment variable. >> >> [1]: https://github.com/openjdk/jfx/pull/99 >> [2]: >> https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds >> [3]: https://tests.reproducible-builds.org/debian/reproducible.html >> [4]: https://reproducible-builds.org/specs/source-date-epoch/ >> [5]: >> https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion >> [6]: https://reproducible-builds.org/docs/source-date-epoch/ >> [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 > > John Neffenger has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two additional > commits since the last revision: > > - Merge branch 'master' into source-date-epoch > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Closing this pull request in favor of #446. The [changes in this pull request][1] are included as the [first commit][2] of pull request #446. [1]: https://github.com/openjdk/jfx/pull/422/commits/3ada5a30c490abec884d878b4fd86219f2f8c60c [2]: https://github.com/openjdk/jfx/pull/446/commits/7ef5031c25fe52c3967c482d6960544aa0e1c9f5 ------------- PR: https://git.openjdk.java.net/jfx/pull/422
