Hi Alexander, On 9/24/24 01:19, Alexander Kanavin wrote:
I don't understand. If we fix a CVE with a backport, then there's metadata in the backported patch to indicate that even though the overall version doesn't change to the one that isn't vulnerable, the patch addresses the vulnerability. Why is a whole separate mechanism still needed?
Thanks for looking into this, the problem is that the metadata (CVE patch info) is not in the binary packages such as RPMs, so the cve scanners such as Trivy doesn't know that. For example, CentOS and Ubuntu also has the similar issues, they use the vendor revisions such as 29.el6.centos and 0.4ubuntu3.3 to help Trivy know that the CVE is fixed in a lower version package. // Robert
Alex On Fri, 20 Sept 2024 at 10:53, Robert Yang via lists.openembedded.org <liezhi.yang=windriver....@lists.openembedded.org> wrote:From: Robert Yang <liezhi.y...@windriver.com> 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. // Robert The following changes since commit 161c5b311f1aeb8f254dca96331b31d5b67fc92d: build-appliance-image: Update to master head revision (2024-09-17 12:31:45 +0100) are available in the Git repository at: https://github.com/robertlinux/yocto rbt/vr https://github.com/robertlinux/yocto/tree/rbt/vr Robert Yang (2): enable-vendor-revision.bbclass: Add it to append VENDOR_REVISION to PR gen-vendor-revision.bbclass: Add it to update VENDOR_REVISION automatically .../enable-vendor-revision.bbclass | 125 +++++++++ .../gen-vendor-revision.bbclass | 243 ++++++++++++++++++ 2 files changed, 368 insertions(+) create mode 100644 meta/classes-global/enable-vendor-revision.bbclass create mode 100644 meta/classes-global/gen-vendor-revision.bbclass -- 2.25.1
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204832): https://lists.openembedded.org/g/openembedded-core/message/204832 Mute This Topic: https://lists.openembedded.org/mt/108555445/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
