On Wed, 24 Mar 2021 21:06:08 GMT, John Neffenger <jgn...@openjdk.org> wrote:
>> Thanks for providing / updating the instructions. >> >> My internal test build failed right off the bat, since we have a >> supplemental closed gradle file that augments the build and downloads >> additional build tools for our internal CI machines. >> >> I don't yet know to handle this, since there is a single, global >> `validation.xml` file and no way that I know of to supplement this. This >> validation file must contain all artifacts that gradle downloads (and their >> transitive dependencies). From the gradle docs: >> >>> A dependency verification configuration is global: a single file is used to >>> configure verification of the whole build. In particular, the same file is >>> used for both the (sub)projects and buildSrc. > >> I don't yet know to handle this ... > > Would any of the following options work? > > 1. If you're using your own supplemental closed Gradle build file, create > your own supplemental closed Gradle verification file, too. Before the > internal build, replace the current file with your own. > 2. Remove the verification file before running your internal build. In this > case, though, you'll also lose its protection against software supply-chain > attacks. > 3. Add your internal dependency checksum entries to the public verification > file and publish the updated file in the repository. > > I think the protection from the verification file is worth having as a > default in the public repository. Gluon, Oracle, BellSoft, and anyone else > building JavaFX can decide, based on their own security assessment, whether > or not they want to use it. The point of including the file in the repository > is to make that decision explicit. The three options you listed are roughly what I had come up with as well. Option 1 would otherwise be ideal, but it would violate the best practice of not writing to an SCM-managed file during the build. If gradle were to provide a way to specify an alternate location -- even if it were a single global file -- then that's what we'd do. I'll check gradle 7 and see if they've added something like this, since we will want to update at some point in the not-too-distant future (so we can support JDK 16 as a boot JDK). Option 2 could be easily achieved by setting system property `org.gradle.dependency.verification` to `lenient|off`. We never download anything from outside our firewall during our CI builds -- we only download pre-verified binaries from our local server. Still, this isn't the ideal situation. What I'd really like is a mode that would verify everything that is in the `validation.xml` file, and warn (but not fail) if an artifact is missing. It would be better than turning it off entirely, but not as good as failing if there are missing dependencies. Option 3 is what I was leaning towards. I'll take a look (not this week, though) at generating the checksums for the internal files and see what it looks like. It's really only cmake (for WebKit build), Ninja (for WebKit build on Windows), and the compiler toolchain "devkit". Unless I'm forgetting something. ------------- PR: https://git.openjdk.java.net/jfx/pull/437
