Hi, In a way, Calcite's build configuration as well as the published POM could be considered as such an SBOM? In particular when looking at the latter through services like mvnrepository [1], you get quite a good view on the dependency versions, licenses, any potential CVEs, etc. I think this should satisfy most user needs around this? Or are you referring to the notion of Maven BOM POMs specifically [2], i.e. the notion of publishing a POM with all the Calcite component versions which people can then use with Maven's import scope (there should be something comparable for Gradle)? If so, that could be useful for users working with multiple Calcite components, though I think the usability improvement provided by such BOM POM wouldn't be huge.
I wanted to bring up a related matter though. Coming to Calcite as a user just recently (loving the possibilities it provides!), I was surprised by the large number of dependencies of the project. It looks like 1.29 improves that a little bit (no more kotlin-stdlib, no more transitive dependency to log4j 1.x), but the transitive hull of all dependencies of calcite-core still is quite big. I lack insight about what the different dependencies are used for; but as an application developer, Guava for instance is a dependency which I'd prefer to not get pushed onto the classpath transitively. Jackson is another heavy one; depending on how it's used, perhaps this could be pushed into some separate module which users could optionally pull in? That'd help to avoid having it around when users work with other JSON libs themselves and don't require JSON support in Calcite. >From a supply chain perspective, the less transitive dependencies a library like Calcite introduces to my project, the better IMHO. Less potential for version conflicts with my own (or other transitive) dependencies, and also less potential for introducing CVEs to the dependency graph, as e.g. in the case of the Guava version currently used by Calcite; I suppose it does not impact the usage in Calcite, but these things tend to be tricky to reason about, and typical CVE reporting tooling will now create a warning for a project using Calcite, no matter whether that specific issue actually is a problem or not. Best, --Gunnar [1] https://mvnrepository.com/artifact/org.apache.calcite/calcite-core/1.29.0 [2] https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms Am Mi., 29. Dez. 2021 um 02:27 Uhr schrieb Julian Hyde < [email protected]>: > In the wake of the log4j CVEs [1], people are asking how to improve the > security of open source projects, and one idea is to provide a SBOM > (Software Bill of Materials) [2] along with each release. > > I had not heard of SBOM until a couple of days ago. Is anyone on this list > familiar with SBOMs and their use? Should Calcite be providing an SBOM? Are > people aware of SBOM initiatives in other projects? What, in your opinion, > is the priority of this issue? > > Julian > > [1] > https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html > > [2] https://en.wikipedia.org/wiki/Software_bill_of_materials >
