| Re: [open-regulatory-compliance] CRA Standardisation request |
On Tue, Feb 18, 2025 at 9:37 PM Jeremy Stanley via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:On 2025-02-18 12:00:53 -0800 (-0800), Scott Lewis via open-regulatory-compliance wrote:
[...]
> Admittedly it's valuable...but it's also *static*. Just the fact that in
> osgi/p2 acceptable version *ranges* constraints are given for dependencies
> means that the target environment (i.e. what else is present at install time
> as well as what repos are know/available) will determine the dependency
> resolution....i.e. what version of a dependency is resolved dynamically at
> install time.
[...]
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.
Two points:
1) OSGi/EF projects are IMHO *far ahead* of much of open source world in putting in place 'solid' dependency management (clear specs and conventions, tools, systems/p2, and processes)...and even with 20 years of head start, there is a regular maintenance effort required of all the upstream projects.
2) The upstream projects are the only ones that can keep the
source meta-data updated, as it requires knowledge of the
semantics of the dependencies.
If consumers want an SBOM or similar record of
what's in installable artifacts like container images or packages,
then the build tools and installers are where that sort of
functionality should be added.
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.
It should be basically transparent
upstream. When it comes to being aware of vulnerabilities in
components shipped in these artifacts and tracked in those
auto-generated SBOMs, such scans can be performed on the artifacts
post-build or in build dry-run processes, where the actual versions
of included components are known and don't have to be predicted.
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].