Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make generated bom.xml and bom.json reproducible #84

Closed
hboutemy opened this issue Feb 2, 2021 · 5 comments
Closed

make generated bom.xml and bom.json reproducible #84

hboutemy opened this issue Feb 2, 2021 · 5 comments

Comments

@hboutemy
Copy link
Contributor

hboutemy commented Feb 2, 2021

cyclonedx-maven-plugin build has been made reproducible, which is perfect to check binary from source: https://github.com/jvm-repo-rebuild/reproducible-central#org.cyclonedx:cyclonedx-maven-plugin

but bom.xml and bom.json files that are published along the source and binary artifacts are not reproducible, see diffoscope result https://github.com/jvm-repo-rebuild/reproducible-central#org.cyclonedx:cyclonedx-maven-plugin

  • they contain a timestamp: using build timestamp used for the jars should do the job
  • generated serial number is not reproducible
  • bom.json has much missing content
@stevespringett
Copy link
Member

The serial number is a UUID and is not predictable nor reproducible. This is by design as all SBOMs require a unique serial number per OWASP SCVS and NTIA guidance. Having two SBOMs that just so happen to have identical content does not make them the same, therefore unique serial numbers are required.

Serial number can be omitted if this is a problem. The Maven plugin allows you to disable serial number generation.

I'd recommend altering the timestamp if this is concern. The CycloneDX object model is intentionally simplistic to allow for progressive enhancement of the SBOM throughout the build pipeline. Overwriting the timestamp with a value that is not an accurate representation of the current time does not align to the facts-first values of the project. The other option is to generate CycloneDX v1.1 SBOMs instead of v1.2, since v1.1 does not include the metadata section.

Not sure what is meant by bom.json is missing content.

@hboutemy
Copy link
Contributor Author

Using Reproducible Build timestamp is just a choice: it's easy to update the plugin to detect and use it.
But if UUID is not intended to be reproducible, using reproducible timestamp is not really useful.

It's sad that UUID is the only data that is not reproducible at all: instead of being random, can't it be based on a fingerprint? eventually a fingerprint based on SBOM content + GAV of the project?

Having a reproducible SBOM would IMHO be a useful feature.

Waiting for that, I just added a parameter to artifact:buildinfo to ignore generated SBOM, given they are not intended to be reproducible for now

@stevespringett
Copy link
Member

Reproducible builds cripple forensic capabilities. If the software concerns public safety, critical infrastructure, or national security, I would not recommend this approach. It would also violate OWASP SCVS principals.

@hboutemy
Copy link
Contributor Author

it's a choice I respect: I switched myself from putting timestamps everywhere for tracking every build result to remove everything with Reproducible Builds, I know that each approach has pros and cons
I won't force: you can choose to close this issue as "won't fix" or let open to reevaluate sometime later, no problem for me

@hboutemy
Copy link
Contributor Author

closing this request, even if there are new ones #226

@hboutemy hboutemy closed this as not planned Won't fix, can't repro, duplicate, stale Dec 24, 2022
eclipse-jgit-bot pushed a commit to eclipse-jgit/jgit that referenced this issue Nov 10, 2023
- configure Maven to run build reproducibly [1]
- use UTC timestamp of checked out commit as build timestamp
- add git-describe, git-commit-id, git-commit-id, git-tags,
  git-remote-origin-url to MANIFEST.MF files
- configure cyclonedx-maven-plugin to also use UTC timestamp of
  checked out commit
- for packaging build use tycho-buildtimestamp-jgit [2] to ensure
  version uses the timestamp of the last commit
- SBOMs are not reproducible by design [3] they should have a build
  timestamp matching the time when the build was executed and a serial
  number which is a unique UUID per build run. Hence exclude them from
  comparison [4].
- Use gmavenplus-plugin to format build timestamps. Maven expects
  build timestamp in ISO-8601 format, to replace the qualifier in
  versions the timestamp format must be compatible with rules for OSGi
  version numbers. Didn't find a way to read the properties set by the
  git-commit-id-maven-plugin from another plugin. Hence use JGit in a
  groovy script to get the commit time of the current HEAD and provide
  it in these two formats.

TODO: packaging build (features and p2 repository) is not yet binary
reproducible since that's not yet supported by Tycho [5], artefacts have
reproducible version numbers but file lastModified timestamps are not
yet reproducible.

Test plan for Maven build:
- build using
  mvn clean install"
- verify second build is reproducible:
  mvn -T1 clean verify artifact:compare
  verification seems not to be thread-safe, hence run it with a single
  thread using option -T1

For packaging build (still fails due to non-reproducible file
timestamps):
- build using
  mvn -f org.eclipse.jgit.packaging/pom.xml clean install
- verify second build is reproducible:
  mvn -T1 -f org.eclipse.jgit.packaging/pom.xml clean verify artifact:compare

[1] https://maven.apache.org/guides/mini/guide-reproducible-builds.html
[2] https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers
[3] CycloneDX/cyclonedx-maven-plugin#84
[4] https://maven.apache.org/plugins/maven-artifact-plugin/compare-mojo.html
[5] eclipse-tycho/tycho#233

Change-Id: I0202f55a1b6ae0edd922cfef638beb39d2ce9417
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants