| Re: [open-regulatory-compliance] CRA Standardisation request |
On 2025-02-18 15:40:51 -0800 (-0800), Scott Lewis via open-regulatory-compliance wrote: > On Tue, Feb 18, 2025 at 9:37 PM Jeremy Stanley via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote: [...] > > So for the most part, from where I sit, upstream open source > > projects shouldn't need to mess with explicitly creating, tracking > > and publishing SBOMs. > > The only thing that makes p2 profiles *possible* is that OSGi-based modules > are *required* to explicitly declare dependencies and version (ranges) [1]. > This by itself creates a consistent, non-trivial burden on Eclipse-based > projects even now...after standardization/specification, many years of tools > development, and coordinated build and release processes. [...] > I don't disagree with this, but without maintained project/code-level > dependency meta-data there is no way to build such functionality. Most > package managers that I'm aware of are not even close to the level of spec, > rigor, tooling, and process support that OSGi-based apps currently enjoy. > Getting to even that level with will not be a small matter for those > communities, and then the dynamics problems (e.g. not idempotent) will still > be present. [...] > That sounds great...and the existence of a modular runtimes like > OSGi/Eclipse bodes well (e.g. see Eclipse Simultaneous Release of the > generation tooling you are talking about), but I still want to emphasize > that all that wonderful automation is actually based upon the project-level > meta-data...which is...by necessity rather than choice...maintained by > humans [1]. > > [1] https://github.com/eclipse-simrel/.github/blob/main/wiki/SimRel/Simultaneous_Release_Requirements.md#required-bundle-forms-and-formats I haven't spent much time in Java-focused projects, but if I understand what you're saying I think we're in agreement. From a concrete proposal perspective, what upstream open source projects can do *now* is start making sure they're implementing standard descriptive metadata which current and future build tools can use to generate SBOMs for inclusion in distributed artifacts. There are likely plenty of other good reasons to be doing that anyway, and "free SBOMs down the road" is just another perk. For example, Python packaging community discussions are leaning toward doing SBOM generation in the cibuildwheel/auditwheel tools, and using modern Python packaging metadata standards in projects makes that possible (or at least more accurate). Telling open source communities that they should "start including SBOMs in their projects," on the other hand, simply doesn't make sense. An SBOM is part of a built artifact (and even then, only in artifacts where there's a need to indicate the presence of non-obvious included software), not something you expect to stick in your Git repo next to your deps list or lockfile. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature