All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Marta Rybczynska <rybczynska@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
Date: Thu, 19 Oct 2023 12:13:30 +0300	[thread overview]
Message-ID: <ZTDzOs9PFGJUmIRG@nuoska> (raw)
In-Reply-To: <CAApg2=SGxxCJ1yuXoMD6=ySRsL-Z2=rENw6xxn-dpQZ-Ta+4rA@mail.gmail.com>

Hi,

On Thu, Oct 19, 2023 at 10:19:53AM +0200, Marta Rybczynska wrote:
> On Mon, Oct 16, 2023 at 9:01 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> >
> > Many recipes embed other SW components. The name and version of the
> > embedded SW component differs from the main recipe. To detect CVEs in the
> > embedded SW component, it needs to be added to CVE_PRODUCT list using
> > name of the SW product in CVE database or with "vendor:product" syntax.
> > Then the version of the embedded SW component can be set using
> > CVE_VERSION_product variable.
> >
> > For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component.
> > Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database
> > uses product name "mbed_tls":
> >
> > CVE_PRODUCT += "mbed_tls"
> >
> > and set the version of mbed_tls:
> >
> > CVE_VERSION_mbed_tls = "2.28.4"
> >
> > (Real patches for both are a bit more complex due to conditional build
> > enabling mbed_tls support and due to mbed_tls version being set in an
> > .inc file.)
> >
> 
> I like the support for embedded software. In this approach, I'm wondering
> how it would work for packages like curl that have multiple CPEs. Would we
> need  to duplicate the list of CPEs?

The current approach of listing multiple CPEs in CVE_PRODUCT still works.
It's just possible to include a different version for an entry in CVE_PRODUCT
via CVE_VERSION_swcomponent variable. It will fall back to PV.
 
> There are layers/recipes where we have a very long list of embedded components,
> meta-zephyr is probably the best example.

Yes, I think this embedding of SW components is very common. I think some of the
LICENSE data does reflect this but not in all cases.

Cheers,

-Mikko


  reply	other threads:[~2023-10-19  9:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16  7:01 [PATCH] cve-check.bbclass: support embedded SW components with different version number Mikko Rapeli
2023-10-19  8:19 ` [OE-core] " Marta Rybczynska
2023-10-19  9:13   ` Mikko Rapeli [this message]
2023-10-19 11:54     ` Jose Quaresma
2023-10-19 12:21       ` Mikko Rapeli
2023-10-20  7:46         ` Jose Quaresma
     [not found]       ` <178F819D833CF586.20272@lists.openembedded.org>
2023-10-19 12:45         ` Mikko Rapeli
2023-10-20  7:56           ` Jose Quaresma
2023-10-20  7:59             ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZTDzOs9PFGJUmIRG@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rybczynska@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.