Re: [OE-core] [PATCH v2] cve-check.bbclass: support embedded SW components with different version number

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Fri, Oct 20, 2023 at 08:54:14AM -0700, Khem Raj wrote:
> On 10/20/23 12:49 AM, Mikko Rapeli 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.)
> > 
> > Now trusted-firmware-a CVE check output shows:
> > 
> > NOTE: recipe trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task do_cve_check: Started
> > WARNING: trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0 do_cve_check: Found unpatched CVE (CVE-2021-36647 CVE-2021-43666 CVE-2021-45451 CVE-2023-43615), for more information check /home/builder/src/base/build/tmp/work/arm64-poky-linux/trusted-firmware-a/2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122/temp/cve.log
> > NOTE: recipe trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task do_cve_check: Succeeded
> > 
> > Here CVE-2023-43615 is a newly added and fixed CVE in version 2.28.5 and the CVEs
> > from 2021 need to be checked but are likely fixed in 2.28.3 and newer 2.28.y releases.
> > 
> > Note that CVE-2023-43615 does not impact trusted-firmware-a since it doesn't use
> > TLS or null or RC4 ciphers, but I think it's a good idea to extend
> > CVE checker for this use case. I hope the "CVE_VERSION_vendor:product"
> > does not cause odd breakages.
> > 
> 
> This is a good improvement. There is one more kink to it, where the vendored
> subpackage might be there in source but we might have configured the recipe
> to use the system version of the package instead, so how do we cater to such
> situation ?

Very good point. I think yocto project maintainer should recommend recipe maintainers
what to do in these cases. I think safest option is to remove/delete such code paths from
upstream sources in do_patch(). Debian does something similar also due to license compliance
with their pristine/dfsg source package format
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackaged-upstream-source
when they can't distributed certain files inside the source package.

This issue goes way beyond CVE related data though. LICENSE, PN and PV are affected.
AFAIK, currently recipe maintainers decide on what goes into LICENSE for example,
based on how they have configured the SW component build and dependencies. These may
not be correct though and for complex SW components this really is an issue where
users who create real products need to check a lot of details. High level SW components
like javascript engines and browser are very eager to build their own versions SW components
which are already available as recipes in the build environment.

At least for CVE scanning, this patch enables telling the tooling "this recipe
embeds a custom version of tool/lib xyz" so recipe maintainers can fill in the data
if they know and care about the details. For license compliance, I hope LICENSE is up to date :)
though I know that the deeper on looks the more problems will pop up...

Cheers,

-Mikko