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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189700): https://lists.openembedded.org/g/openembedded-core/message/189700 Mute This Topic: https://lists.openembedded.org/mt/102076964/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
