> 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 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/422/files - new: https://git.openjdk.java.net/jfx/pull/422/files/3ada5a30..b24a86cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=422&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=422&range=00-01 Stats: 95067 lines in 1313 files changed: 56763 ins; 14002 del; 24302 mod Patch: https://git.openjdk.java.net/jfx/pull/422.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/422/head:pull/422 PR: https://git.openjdk.java.net/jfx/pull/422
