On Wed, Jun 2, 2021 at 5:43 PM Philip Balister <email@example.com> wrote:
On 6/1/21 5:39 PM, Joshua Watt wrote:
Given the recent interest in SBOM support for OE-core, I'm going to
start looking at integrating meta-doubleopen as an SBOM solution for OE.
I've taken a look around in the project, and I think it covers most of
the requirements that I think OE needs for SBOM support:
1) It provides almost all of the information about recipes and packages
that is considered "minimum viable" for SBOM support (based on the
presentations from Kate Stewart that I watched). The only field I've
noticed is lacking is the "Supplier Name" (SPDX "PackageSupplier"). I'm
by no means an SBOM expert, so I'm not quite clear what that field
should be or how to populate it, but I think we can worry about that later.
2) It's self contained; there is not dependency on external components
3) It produces SPDX JSON output, which is a standardized format and
should be fairly easily translated to just about any other format
It's possibly that meta-doubleopen does more that what would be
considered a minimum viable SBOM solution for OE, but it seems quite
useful and I suspect any extra functionality are things we would want
anyway. I'd be curious for the Mikko (the author) to chime in and let us
know what works well and what doesn't with the layer.
Short term goal, get an OpenEmbedded presence at the next SBOM plugfest.
I feel this will get us important feedback we can use to shape SBOM
support in openembedded-core. Joshua, do you think we can build an SBOM
from openembedded-core and meta-doubleopen that would be good for the
I think that we can get something pretty good for the plugfest using
meta-doubleopen. Ideally, we would generate something that passes the
SPDX online validator (https://tools.spdx.org/app/validate/
). I tried
with the current output, but it complained that our licenses were not
valid SPDX identifiers (which I think is a known issue in OE). I think
a simple mapping table for the GPL(+) licenses is all that is needed.
Hopefully that's all that is needed there, but we shall see. Beyond
that there are probably a few "nice to have" things that are not
strictly necessary, such as the package licenses, the Package
Supplier, and maybe some knobs to make the output smaller (it's about
500MB for core-image-minimal; although I'd *love* to see some of the
SPDX consumers parse it *evil laugh*). Perhaps we can see how much we
get done by before the 17th (or earlier if necessary)? I think all of
these changes should be pretty simple and can easily be made in the
A couple of links:
It's not quite clear to me: are they providing something we should
generate a SBOM from, or do we just make one from whatever and they
will pass it around?
I am glad to help with registration an attend the meeting. I understand
several people have conflicts on the day of the plugfest who are better
prepared to talk about this stuff, but with some support I am glad to
submit the form.
And crap, I may not be available on the 17'th. Let's see what we can
Ideally, I think this could be brought into OE-core in some form; does
anyone have any thoughts on this idea? I think that the code as-is needs
a little bit of cleanup to make that happen, but moving it to core would
make that a little easier (it seems there is some duplication between
what meta-doubleopen is doing and other various components in OE).