From: <liezhi.yang@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Cc: <david.reyna@windriver.com>
Subject: [PATCH 0/2] proposal: Append VENDOR_REVISION to PR for CVE scanners
Date: Fri, 20 Sep 2024 01:53:13 -0700 [thread overview]
Message-ID: <cover.1726821150.git.liezhi.yang@windriver.com> (raw)
From: Robert Yang <liezhi.yang@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
next reply other threads:[~2024-09-20 8:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 8:53 liezhi.yang [this message]
2024-09-20 8:53 ` [PATCH 1/2] enable-vendor-revision.bbclass: Add it to append VENDOR_REVISION to PR liezhi.yang
2024-09-20 8:53 ` [PATCH 2/2] gen-vendor-revision.bbclass: Add it to update VENDOR_REVISION automatically liezhi.yang
2024-09-23 17:19 ` [OE-core] [PATCH 0/2] proposal: Append VENDOR_REVISION to PR for CVE scanners Alexander Kanavin
2024-09-24 4:24 ` Robert Yang
2024-09-24 4:47 ` Alexander Kanavin
2024-09-24 8:18 ` Robert Yang
2024-09-24 8:23 ` Alexander Kanavin
2024-09-24 7:52 ` Mikko Rapeli
2024-09-24 8:21 ` Robert Yang
2024-09-24 8:34 ` Mikko Rapeli
2024-10-01 13:59 ` Ross Burton
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=cover.1726821150.git.liezhi.yang@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=david.reyna@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/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.