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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox