[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH [v2]
From:       Kevin Rushforth <kcr () openjdk ! java ! net>
Date:       2021-04-30 13:50:58
Message-ID: RQY25knYLRLAlqYWHx1CQ91JgRVJPMl72R2EYBHYiSw=.68f9abe1-a757-4268-bcb3-5d1a506ee78d () github ! com
[Download RAW message or body]

On Fri, 30 Apr 2021 00:10:30 GMT, John Neffenger <jgneff@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

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/422


[prev in list] [next in list] [prev in thread] [next in thread]