| Message ID | cover.1726821150.git.liezhi.yang@windriver.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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? Alex On Fri, 20 Sept 2024 at 10:53, Robert Yang via lists.openembedded.org <liezhi.yang=windriver.com@lists.openembedded.org> wrote: > > 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 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#204726): https://lists.openembedded.org/g/openembedded-core/message/204726 > Mute This Topic: https://lists.openembedded.org/mt/108555445/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
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.com@lists.openembedded.org> wrote: >> >> 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 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#204726): https://lists.openembedded.org/g/openembedded-core/message/204726 >> Mute This Topic: https://lists.openembedded.org/mt/108555445/1686489 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Tue, 24 Sept 2024 at 06:24, Robert Yang <liezhi.yang@windriver.com> wrote: > 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. But how is trivy's database updated to include such custom vendor revisions? Is it done centrally by the vendor (and how?), or is it done by users in local installations? This does appear hack-ish to me, the better thing to do would be to actually include the list of fixed CVEs into package metadata. I'm not sure this should be carried in core, if there's only a single known tool that needs it, and core has no support or tests for it. Maybe something like meta-trivy? Alex
Hi, On Fri, Sep 20, 2024 at 01:53:13AM -0700, Robert Yang via lists.openembedded.org wrote: > 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. 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. When managing a yocto based Linux distro, IMO, the tooling is already there to handle CVEs etc. External tools frequently cause more pain than actually improve things. Cheers, -Mikko
On 9/24/24 12:47, Alexander Kanavin wrote: > On Tue, 24 Sept 2024 at 06:24, Robert Yang <liezhi.yang@windriver.com> wrote: >> 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. > > But how is trivy's database updated to include such custom vendor > revisions? Is it done centrally by the vendor (and how?), or is it The vendor itself will update trivy's database, David Reyna (in the To list) is working on a script which can update the database, we will provide more detailed examples later. > done by users in local installations? This does appear hack-ish to me, > the better thing to do would be to actually include the list of fixed > CVEs into package metadata. The problem is that Trivy can't work in this way AFAIK. > > I'm not sure this should be carried in core, if there's only a single > known tool that needs it, and core has no support or tests for it. > Maybe something like meta-trivy? Trivy is just an example, we're trying to make more tools such as blackduck work. // Robert > > Alex
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 <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. > > 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/ // Robert > > When managing a yocto based Linux distro, IMO, the tooling is already there > to handle CVEs etc. External tools frequently cause more pain than actually > improve things. > > Cheers, > > -Mikko
On Tue, 24 Sept 2024 at 10:18, Robert Yang <liezhi.yang@windriver.com> wrote: > > done by users in local installations? This does appear hack-ish to me, > > the better thing to do would be to actually include the list of fixed > > CVEs into package metadata. > > The problem is that Trivy can't work in this way AFAIK. You do need to raise this with trivy. It's open source, and can be improved. This whole CVE ecosystem is already mad enough and that's why I'm not getting involved, managing vendor revisions instead of directly looking at what has been fixed is just adding to that madness. Or let's just not use broken external tools, and do things right ourselves. Alex
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 <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. > > > > 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
On 20 Sep 2024, at 09:53, Robert Yang via lists.openembedded.org <liezhi.yang=windriver.com@lists.openembedded.org> wrote: > 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: I understand what you're trying to do here, but the class doesn’t just work on its own out of the box, as there needs to be further configuration and workflow to make it actually useful, and the only users it is useful for are people who are maintaining a binary distribution and have sufficient clout to update the CVE tooling. I suggest that you keep this class in your Wind River Linux layer. Cheers, Ross
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