WRT SBOM (Julian): My general experience is that most large orgs use scanners now (either open or closed) and they will scan whether you have a bill of materials or not. I wouldn't worry about adding something additional.
WRT too many dependencies (Gunnar): I completely agree with the general feeling of too many (and with Guava, jackson less so). I think the core challenge (no pun intended) is that calcite-core is really a lot of different components. For example, I have frequently wished that parser, planner and enumerable were separate modules. And if they were, I'd guess that each would have a narrower dependency range. I've also wished many times that runtime compilation was an optional addon as opposed to required/coupled in the core... When I've thought about how to dissect in the past, I think the big challenge would be tests, where things are sometimes mixed together. Breaking change possibilities could be at least somewhat mitigated by moving classes but not packages. On Wed, Dec 29, 2021 at 1:51 AM Gunnar Morling <[email protected]> wrote: > 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 > > >
