Hi,
On Fri, Sep 20, 2024 at 01:53:13AM -0700, Robert Yang via
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.
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204837):
https://lists.openembedded.org/g/openembedded-core/message/204837
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]
-=-=-=-=-=-=-=-=-=-=-=-
