On 5/18/21 3:02 PM, Richard Purdie wrote:
On Tue, 2021-05-18 at 17:28 -0400, Trevor Woerner wrote:
On Tue, May 18, 2021 at 4:59 PM akuster808 <email@example.com> wrote:I'd like to try and put some guidance around the discussion if I may?
On 5/18/21 11:32 AM, Trevor Woerner wrote:I'm still investigating and putting together a set of ideas.
I'd like to recommend this be a round-table topic for next week's OEIf meta-doubleopen addresses the issue for folks, what is the topic of
There are a ton of things we could do here but I think the need
is comparatively clear and pressing. Discussions are good where
the outcome is unknown and options need to be explored. I think
some of this is relatively clear for the reasons I'll mention below.
meta-doubleopen says "This meta layer is intended for use with Can I suggest we adopt the position that we aim for SPDX unless someone
Double Open's open source license compliance workflow". *license*
workflow, we're talking about SBOMs. The fact they produce SPDX
files isn't all that's required to create an SBOM. SPDX is just
a file format. In fact there's nothing in that layer that says
anything about SBOM. From what I can tell, all meta-doubleopen is
producing is an SPDX version of the various manifest files one
would find if buildhistory is enabled.
SPDX is only one of several file formats that can be used to
generate an SBOM in a standard way. It could be worth a discussion
to at least mention the others.
produces a strong argument that something else has advantages?
The reason I say this is that it is the standard most projects are
consolidating around, it shows alignment with other work at the LF
and SDPX is aiming to become an ISO standard. To do something different
would put us in a difficult position IMO. People complain that LF
projects don't collaborate enough, here we have an opportunity I want
to make work.
We could look at what an SBOM is, and what are the minimum required We do need to find out what the legislation says about this so we can
fields to produce an SBOM.
Why? OE nor YP sell to the US Government? This seems to be more of a
concern for commercial vendors. They are the ones who need to come to
the table and help support these efforts. Being this is such a new
thing, things will change. Remember, this is the US Government, just
because the President said this, does not mean each Federal agency will
adopt it for verbatim.
Another question for the round table: should we integrate this into We need to be able to say that OE/YP generates SBOM manifests for
oe-core, or leave it as a separate layer?
images out the box, preferably by default. If we don't do that, we will
lose out to projects which can claim this. I think that makes the
The round table is also a great way of introducing this important topicI think aspects which do need discussion is how to handle:
to the community at large. I bet you half the people attending the
conference have never heard of an SBOM, but might be interested to
know YP/OE is looking into integrating it into the build system
especially now that the US government has released an Executive Order
regarding SBOMs, and that the EU is also looking into these sorts of things as well).
I'll look into inviting the DoubleOpen people to the meeting.
Joshua mentioned that the company he works for is also investigating
generating SBOMs from YP/OE builds, so let's make sure everyone is
working on one project, instead of scattering the community.
So there are a couple things we could talk about :-)
* SPDX data at the do_package/do_packagedata level
* SPDX data at the archiver and do_populate_lic level
* whether we can replace existing image manifests
* whether we need tooling to take an SPDX image manifest and process it to
various forms for end user/tool use (e.g. actual file output or API?).
Transitioning to a more accepted format is something YP/OE should
discuss but don't do it to meet the needs of the US Government.
This probably translates into some kind of plan with different phases.