Hi, On Tue, Sep 24, 2024 at 04:21:49PM +0800, Robert Yang wrote: > On 9/24/24 15:52, Mikko Rapeli wrote: > > Hi, > > > > On Fri, Sep 20, 2024 at 01:53:13AM -0700, Robert Yang via > > lists.openembedded.org wrote: > > > From: Robert Yang <[email protected]> > > > > > > The VENDOR_REVISION is for cve scanners to know the CVEs have been fixed > > > in a > > > lower version, CVE scanners such as Trivy can know the CVEs have been > > > fixed in > > > a higher version, but it can't know the CVE is fixed in a lower version > > > without > > > a helper, we have the following ways to set the helper: > > > 1) Use PR server > > > This doesn't work since the server updates PR for any changes. > > > > > > 2) Update PR manually when add a CVE patch > > > This is doesn't work either since: > > > - This is very trivial and people may forget to update the PR > > > - The PR may be updated for other reasons except CVE patches > > > > > > So we need a specific part such as VENDOR_REVISION for cve scanners. > > > The VENDOR_REVISION is designed as part of PR: > > > PR:append = ".vr51" > > > - ".vr51": The VENDOR_REVISION > > > - "vr": Vendor Revision, can be set to other values such as oe or poky > > > - "51": Convert from DISTRO_VERSION (Yocto 5.1), it can be customized with > > > a function defined in GET_CURRENT_VENDOR_REVISION. > > > - The VENDOR_REVISION will only append to the recipes which have patches > > > > > > There are two bbclasses to manage the VENDOR_REVISION automatically: > > > - gen-vendor-revision.bbclass: This is used for generating VENDOR_REVISION > > > automatically, and save all the recipes' VENDOR_REVISION in > > > vendor-revision.conf, it is like: > > > VENDOR_REVISION[meta_recipes-support_libssh2_libssh2_1.11.0.bb] ??= > > > '${VENDOR_REVISION_PREFIX}51 \ > > > CVE-2023-48795:CVE-2023-48795.patch:b6c68cd1f0631180914ff112ac0c29c4 \ > > > > > > notcve:0001-disable-DSA-by-default.patch:61b6368d4a969d187805393d8b8fee85' > > > > > > And in the second release such as Yocto 5.1.1, the bbclass will update > > > the > > > vr51 to vr511 when both of the following 2 conditions are met: > > > - The DISTRO VERSION is updated, for example, from 5.1 to 5.1.1 > > > - The recipe's patches are changed (Patches added, removed or updated), > > > otherwise, it will still be "51" when Yocto updated to 5.1.1, this > > > can avoid > > > unnecessary PR bump. > > > > > > - enable-vendor-revision.bbclass: Append VENDOR_REVISION to PR > > > After the VR is appended, the rpm package is like: > > > openssl-3.3.1-r0.vr51.core2_64.rpm > > > > > > There is no change if the recipe doesn't have patches, for example: > > > base-files-3.0.14-r0.qemux86_64.rpm > > > > > > Check the comments in the header of gen-vendor-revision.bbclass for more > > > details. > > > > This is very much backwards, like Alex mentioned as well. > > > > There is no need for this. If CVEs are fixed with patches, then those > > patches will > > mark the specific version and patch applied as not affected by the CVE. > > The classes export this data. If anyone feeds this data to external > > tooling, then > > the CVE patch status is a critical detail which must be exported and > > imported into > > the tools as well. Otherwiser the external tooling is not really up for the > > job. > > > > I've seen several commercial tools not managing the patch status at all. > > IMO these > > tools are broken and can't be used to manage secure patches of real products > > which have to apply CVE patches and can't always update SW versions. > > Maybe you're right, but the mainstream distributions work with those tools > such as Trivy: > > https://aquasecurity.github.io/trivy/v0.17.2/vuln-detection/os/
I think maintaining CVE and security patches of a distro using tools which are not used by the uptream maintainers of the distro is not a good idea. I understand that organizations and managers may want to use specific, sometimes commercial tools. But these may not help. If you only look at the RPM package data exported by yocto, then CVE patch status is lost. Same is true for other package output from yocto builds. In the past I was asked to provide and use Black Duck tooling and have explained these problems multiple times, and eventually the requests went away. Time was better spent fixing actual issues found by upstream compatible tooling, e.g. cve-check.bbclass. If there is a standard for RPM package metadata to include CVE patch status, then that could of course be added to the package built by yocto. In similar way, if I were asked to maintain a Debian/Ubuntu variant for CVE security patches, then I'd start with https://security-tracker.debian.org/tracker/ and the data embedded there. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204842): https://lists.openembedded.org/g/openembedded-core/message/204842 Mute This Topic: https://lists.openembedded.org/mt/108555445/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
