waynebeaton
commented
1 year ago I guess that I should make the Dash License Tool's core library an OSGi bundle. I should probably do that anyway (and factoring out the CLI stuff is overdue). FWIW, SPDX doesn't provide license information about content, they're more about defining how to specify license information. The Dash License tool already knows how handle our rules with regard to ClearlyDefined and the IPLab database.
At least internally, we've latched onto CycloneDX. My recommendation is that we focus on that, leaving SPDX SBOM generation as a nice-to-have for later consideration.
I don't have an opinion regarding whether or not content should be added to Orbit. If you feel that it should be, then we can try to find some resources to help.
I did some prototyping how one might generate an SBOM from a p2 repository
What we'd like to produce first is an SBOM for an Eclipse IDE. I'm quite disconnected from the p2 technology... can we think of the configuration of a particular IDE product as a p2 repository? Or is this a different problem?
My sense is that one can produce some quite good information relatively quickly, but then one starts to slide down the slippery slope of complexity.
My thinking is that if we can produce something that quite good relatively quickly, we should do that. When we actually have something, it will be easier to get help (or allocate funds) to improve it.
Are you able to create "quite good information relatively quickly" within your current mandate?
merks
GuillaumeEscande
I did some prototyping how one might generate an SBOM from a p2 repository.
The prototype creates a bom.xml from the Eclipse Installer self-contained repository:
https://download.eclipse.org/oomph/products/repository
It's implemented by this simple (very rough prototype) p2 application which loads the repository and analyzes the metadata and actual artifacts to produce a CycloneDX representation:
SBOMApplication.java
You can see that the bom.xml includes dependency information by wiring requirements to capabilities.
I've done some extracting of license information too, e.g., what I could find in the pom in the artifact jar, but that information is not always easy to track down in a consistent way or place. Also, I don't want to duplicate work that has already been done, e.g., by spdx or dash.
My sense is that one can produce some quite good information relatively quickly, but then one starts to slide down the slippery slope of complexity. Also many questions remain/arise about the form of the representation and how well these concepts apply to the OSGi world of bundles as well as the Equinox world of features.
The IDE WG's budget can't accommodate what could turn into weeks or months of work, and it's not entirely clear yet in which form folks want to do the analysis. I.e., there appears to be mention of doing the production of a SBOM as part of the build; implementing something that runs in Maven versus something that runs as an OSGi application is quite different technically.
So before investing more time, it would be good to discuss the strategy and plans around this...
Below is more background information and details.
I am reusing cyclonedx's core library, which have quite some dependencies:
To use this stuff in an OSGi environment, i.e., in the above application where p2 functions, one needs quite few new dependencies that could be added to Orbit which I did locally:
I also looked at SPDX's dependencies but that's a massive list and is clearly designed to be used within a maven build: