Collaborative Working Sessions - Born reproducible III
Follow up of Born Reproducible II
In this session, we were more concrete. We came up with how each step in the framework in part II could be implemented for Java (especially maven) ecosystem.
Assume that the clean environment is the GitHub action runner. Although you have more control on your system, the information you care about (like
mvn version) is know in GitHub action runner as well.
- Java source code
- Build configuration (
pom.xml): Try to have a minimal working version of that. Remove all the unecessary boilerplate code.
- all the
jars and the SBOMs produced as the build output.
.buildspecin the reference implementation documents all of this.
- all the
Build metadata for Java could mean to know all the transitive dependencies and system dependencies (for example, the compression tool for classfiles could be a system dependency)
maybe not too relevant for Java, but it was for C/android
- Compare the artifacts listed in
outputwith the ones on maven central (
rebuild.sh <buildspec>does that in reference implementation).
mvn packagefor the first build and
mvn packagewithout snapshot lookup for the second build (rebuild).
The differences could be
- order of classfiles in archives
- absolute and relative paths of resources
- differences in classfiles
- difference in manifest files
Reference implementation uses
A different environment could be Jenkins, CircleCI, a separate GitHub action runner with a different architecture.
In theory, architecture should not matter as jars are supposed to be independent of this.
- Let user’s reproduce the CI based on the build step _ Provide tooling for reproducing it. Example: gorebuild is a tool to reproduce go toolchain.
From here on, it gets abstract
Document why the artifacts generated are not reproducible and give reasons why they are not. For example, the signature difference. In Step 6, users could be told to strip signature before comparing.
Step 8,9,10 are release related so we did not discuss them in depth.
Project README should tell how to verify build attestation.
Have your CI sign the artifacts.
Implementing deploy policy is a responsibilty taken by the artifact hosting service (maven central) in Java ecosystem. For example, it checks your manifest (
pom.xml) for certain requirements before deploying.
Last takeaway of this session was that the framework was supported by people working in C and android ecosystems. However, commercial code is a hard problem.
Follow us on Twitter @ReproBuilds, Mastodon @firstname.lastname@example.org & Reddit and please consider making a donation. • Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. • Patches for this website welcome via our Git repository (instructions) or via our mailing list. • Full contact info