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. 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. 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.
This is very much aligned with my understanding too. However, given multiple discussions I have had on this topic and the conversation we had here, it is clear that this needs more research to arrive at a common understanding even before considering building consensus.
As discussed during the workshop, a good step forward here would be to create a whitepaper that helps clarify what problems SBOMs are solving and how they should be implemented to do so.
--tobie
