All steps for producing Eclipse Temurin are defined by version-controlled Jenkins pipelines that invoke build scripts stored in the adoptium/temurin-build repository. The pipeines and build scripts are available for anyone to view and verify, and the Jenkins system runs are open to scrutiny. Documentation for using the build scripts is available in the build repository’s readme file.

Adoptium provides SBOM attestations for the provenance of Eclipse Temurin builds. The SBOM is in OWASP CycloneDX format and available alongside each of our Temurin release artifacts.

The SBOM includes the information required to recreate the build if required, including the source repository tags used by the build process, the full set of parameters used, the output from the configuration steps, and various other pieces of information. We are continually evolving the specific details included in the SBOM.

Adoptium mirrors the OpenJDK Java SE reference implementation source code into our local Github repository (e.g. adoptium/jdk17u). Every change to the source we build and the scripts we use is tracked by Github’s version control system. This ensures a record of the history of changes that went into each revision. Each change contains the identities of the uploader and reviewers, timestamps of the reviews and submission, the change description/justification, the content of the change, and the parent revisions. All committers and reviewers undergo strong authentication, and all contributors must execute and abide by the Eclipse Contributor Agreement.

Each immutable revision of the code under our control has a unique reference with an indefinite lifespan via Github (repo URL + branch/tag/ref + commit ID). Eclipse Temurin is built from tagged revisions of our mirror, and we make source archive files available for each release.

All Adoptium’s build steps run on our own managed Jenkins build service and the Eclipse Foundation’s code signing service. These services perform the builds, generate the SBOMs, and build the installers where applicable. The output from the builds are uploaded to GitHub release repositories by the Jenkins CI system. No parts of the process run on a developer’s workstation.

Access to build services is carefully managed by the project. The build system is as open as possible to allow scrutiny by the community without compromising security.

TODO: The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.

All of Adoptium provenance data is generated directly by the project continuous build and test systems. Service users cannot inject or alter the contents of the provenance. Eclipse Temurin’s GNU Privacy Guarg (GPG) code signatures are generated by the Eclipse code-signing service, other provenance data including the software bill of materials, cryptographic hashes, build metadata, etc. is directly emitted by the project build system.

All revisions to source code and its change history are preserved indefinitely and cannot be deleted, except when subject to an established and transparent policy for obliteration, such as a legal or Eclipse Foundation policy requirement. This level of superuser control for changing or deleting history is maintained directly and exclusively by the Eclipse Foundation on behalf of the project.

Since we store all our code in GitHub it is not be possible for persons to delete or modify the history, even with multi-party approval, except by trusted Eclipse Foundation platform admins with two-party approval following the foundation’s obliterate policy. Questions about this policy should be addressed to the Eclipse Foundation.

Adoptium’s build definition and configuration executed by the build service is verifiably derived from text file definitions stored in our version control system.

Ephemeral environment builds such as a container or VM, provisioned solely for this build, and not reused from a prior build is in place for Linux x86, ARM32, and aarch64 builds. Other platforms are still a work in progress at the project.

The Adoptium build service ensures that each build step runs in an isolated environment free of influence from other build instances, whether prior or concurrent.

It is not possible for a build to access any secrets of the build service, such as the provenance signing key, as these are stored outside the build system and accessed by a remote call to a separate system. It is not be possible for two builds that overlap in time to influence one another. Each build step runs in an isolated machine environment orchestrated by the Jenkins CI system, and steps from each build are assembled through the use of managed pipelines. Build caches, where used, are purely content-addressable to prevent tampering.

We continue to work on ensuring that is not possible for one build to persist or influence the build environment of a subsequent build. Each part of the environment is specified in the build scripts. This will be ensured by running builds on ephemoral machines everywhere and checking the results are identical.

The SBOM provenence informaton cannot be falsified by service users since it is machine generated by the build process and cryptographically signed by the Eclipse Foundation code signing service to prevent tampering. The code signing service is not accessible to regular project committers or Jenkins users.