[PATCH] cve-check-map: Add 'cannot-backport' to status map

[PATCH] cve-check-map: Add 'cannot-backport' to status map

[Dhairya Nagodra]

- Sometimes, the difference in the codebase of the fixed CVE's version
  and the current version of the package is huge.
- This would make the backporting of the CVE not a feasible option.
- And due to other dependencies and limitations, the upgrade of the
  package might not be possible as well.
- This commit would allow users to add a description via CVE_STATUS and
  still show the CVE as vulnerable.

Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com>
---
 meta/conf/cve-check-map.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/cve-check-map.conf b/meta/conf/cve-check-map.conf
index 17b0f15571..b9df41a6f3 100644
--- a/meta/conf/cve-check-map.conf
+++ b/meta/conf/cve-check-map.conf
@@ -13,6 +13,8 @@ CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
 CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
 # use when CVE is confirmed by upstream but fix is still not available
 CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
+# use when CVE fix is not compatible to the current version and cannot be backported.
+CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched"
 
 # used for migration from old concept, do not use for new vulnerabilities
 CVE_CHECK_STATUSMAP[ignored] = "Ignored"

RE: [PATCH] cve-check-map: Add 'cannot-backport' to status map

[Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco)]

A gentle reminder.
This patch can be independently merged and is not dependent on https://lists.openembedded.org/g/openembedded-core/message/202425

Thanks,
Dhairya

>-----Original Message-----
>From: Dhairya Nagodra <dnagodra@cisco.com>
>Sent: Wednesday, July 24, 2024 10:14 AM
>To: openembedded-core@lists.openembedded.org
>Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Dhairya
>Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) <dnagodra@cisco.com>
>Subject: [PATCH] cve-check-map: Add 'cannot-backport' to status map
>
>- Sometimes, the difference in the codebase of the fixed CVE's version
>  and the current version of the package is huge.
>- This would make the backporting of the CVE not a feasible option.
>- And due to other dependencies and limitations, the upgrade of the
>  package might not be possible as well.
>- This commit would allow users to add a description via CVE_STATUS and
>  still show the CVE as vulnerable.
>
>Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com>
>---
> meta/conf/cve-check-map.conf | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/meta/conf/cve-check-map.conf b/meta/conf/cve-check-map.conf
>index 17b0f15571..b9df41a6f3 100644
>--- a/meta/conf/cve-check-map.conf
>+++ b/meta/conf/cve-check-map.conf
>@@ -13,6 +13,8 @@ CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
> CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
> # use when CVE is confirmed by upstream but fix is still not available
>CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
>+# use when CVE fix is not compatible to the current version and cannot be
>backported.
>+CVE_CHECK_STATUSMAP[cannot-backport] = "Unpatched"
>
> # used for migration from old concept, do not use for new vulnerabilities
>CVE_CHECK_STATUSMAP[ignored] = "Ignored"

Re: [OE-core] [PATCH] cve-check-map: Add 'cannot-backport' to status map

[Richard Purdie]

On Tue, 2024-07-23 at 21:44 -0700, Dhairya Nagodra via lists.openembedded.org wrote:
> - Sometimes, the difference in the codebase of the fixed CVE's version
>   and the current version of the package is huge.
> - This would make the backporting of the CVE not a feasible option.
> - And due to other dependencies and limitations, the upgrade of the
>   package might not be possible as well.
> - This commit would allow users to add a description via CVE_STATUS and
>   still show the CVE as vulnerable.
> 
> Signed-off-by: Dhairya Nagodra <dnagodra@cisco.com>
> ---
>  meta/conf/cve-check-map.conf | 2 ++
>  1 file changed, 2 insertions(+)

I don't think this status make sense as it is too hard to define. For
one person, a cannot backport might be a patch that doesn't apply
cleanly, all the way through to a patch which would need many hours of
work to correctly apply to an earlier version.

I think this classification would be too arbitrary and depends on the
person's skill set too much.

Cheers,

Richard