Re: [OE-core][PATCH v6 09/15] spdx30: Skip install package CVE information

Joshua Watt
2026-03-12T14:15:41Z

On Thu, Mar 12, 2026 at 5:55 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via lists.openembedded.org wrote:
> > Skips adding the install package CVE information by default. This
> > information grows exponentially, since it ends up be N_CVES *
> > N_PACKAGES. The CVE information for a given installed package can be
> > determined by following the "generates" link between the install package
> > and the recipe and looking at the CVE information for the recipe,
> > meaning that the CVE information is only included once in the SPDX
> > document.
> >
> > If users still need the legacy method of including CVE information for
> > each package, then then can set SPDX_PACKAGE_INCLUDE_VEX = "1"
> >
> > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > ---
> > meta/classes/create-spdx-3.0.bbclass | 11 ++++++++
> > meta/lib/oe/spdx30_tasks.py | 39 ++++++++++++++--------------
> > meta/lib/oeqa/selftest/cases/spdx.py | 12 +++++++++
> > 3 files changed, 43 insertions(+), 19 deletions(-)
> >
> > diff --git a/meta/classes/create-spdx-3.0.bbclass b/meta/classes/create-spdx-3.0.bbclass
> > index c3ea95b8bc..88b7ef9f42 100644
> > --- a/meta/classes/create-spdx-3.0.bbclass
> > +++ b/meta/classes/create-spdx-3.0.bbclass
> > @@ -45,6 +45,17 @@ SPDX_INCLUDE_VEX[doc] = "Controls what VEX information is in the output. Set to
> > including those already fixed upstream (warning: This can be large and \
> > slow)."
> >
> > +SPDX_PACKAGE_INCLUDE_VEX ?= "0"
> > +SPDX_PACKAGE_INCLUDE_VEX[doc] = "Link VEX information to the binary package outputs. \
> > + Normally, VEX information is only linked to the common recipe that `generates` the \
> > + binary packages, but setting this to '1' will cause it to also be linked into the \
> > + generated binary packages. This is off by default because linking the VEX data to \
> > + each package causes the SPDX output to grow very large, and the same information \
> > + can be determined by following the `generates` relationship back to the recipe. \
> > + Before recipe packages were introduced, this was the only way VEX data was \
> > + expressed; you may need to enable this if your downstream tools do not \
> > + understand how to trace back to the recipe to find VEX information."
>
> To me, removing this duplication and keeping the SPDX docs usable seems
> like a very sensible thing to do. Do we want/need to make it
> configurable?
>
> I appreciate some tools/usage may need fixing to work with this but
> adding configuration options like this makes it harder to use our code
> and also adds maintenance/testing overhead.

Maybe, but I'm very hesitant to break any existing SPDX based CVE
workflows that people may have in a LTS release, which is the only
reason I added the option. I'm fine to remove this after the LTS, IMHO
it's just too close to LTS release to suddenly say "sorry this is all
broken for you now"

>
> I think I'm very much in favour of just changing and generating things
> like this unconditionally and if someone needs to work with it
> differently, they can post process the output.
>
> This goes back to my concern about the complexity of the code and
> configuration, I think we need to simplify and present fewer options to
> the user...
>
> Cheers,
>
> Richard