Re: [Buildroot] [RFC PATCH 01/14] docs/manual: add vulnerability status and justification

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Thomas Perale <thomas.perale@mind.be>
Cc: buildroot@buildroot.org,
	 Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Subject: Re: [Buildroot] [RFC PATCH 01/14] docs/manual: add vulnerability status and justification
Date: Thu, 20 Aug 2026 22:47:13 +0200	[thread overview]
Message-ID: <aodnYtE4laq3em8i@windsurf> (raw)
In-Reply-To: <20260624140645.185318-2-thomas.perale@mind.be>

Hello Thomas,

On Wed, Jun 24, 2026 at 04:06:32PM +0200, Thomas Perale via buildroot wrote:
> In Buildroot, we can put the ignore CVEs entries in different
> categories:
> 
> - Vulnerability fixed by a patch.
> - Vulnerability ignored because the internal tooling detect it as a
>   false positive
> - Vulnerability ignored because the database is wrong or not up-to-date.
> - Vulnerability ignored because it doesn't apply to Buildroot
>   (platform/hardware specific, ...).
> - Vulnerability ignored because Buildroot is using an upstream fixed
>   version (based on a hash for instance) while the CPE metadata
>   reference the latest known version.
> 
> Since the introduction of `_IGNORE_CVES` the justification for the
> vulnerability were added as a comment on top of the ignored
> vulnerability. With the introduction of the rule for the `CVE:` trailer
> it's now possible to distinguish the vulnerabilities that are patched
> from the one that are not-applicable for another unknown reason.
> 
> This commit add documentation to introduce two new variables:
> 
> - `<pkg>_<vuln-id>_STATUS`
> - `<pkg>_<vuln-id>_DETAIL`
> 
> This allows to have machine readable variables that are exposed and
> contains the reasons why a vulnerability is set as ignored instead of
> storing this knowledge in a comment on top of the `_IGNORE_CVES` entry.
> 
> The `<pkg>_<vuln-id>_STATUS` syntax is based on OpenVex statuses syntax
> [1][2]. This varialbe only needs to be used if a patch on the Buildroot
> tree isn't present.
> 
> The `<pkg>_<vuln-id>_DETAIL` is a free text field that allows to add
> more information to justify the status.
> 
> [1] https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-labels
> [2] https://github.com/openvex/ospec/blob/main/OPENVEX-SPEC.md#status-justifications
> 
> Signed-off-by: Thomas Perale <thomas.perale@mind.be>

Thanks for this proposal. Overall I find it nice and well-aligned with
the Buildroot spirit.

Two comments below.

> +* +LIBFOO_<VULN-ID>_STATUS+ informs about the impact of the vulnerability

Shouldn't you indicate that these properties only make sense when
<VULN-ID> is in <pkg>_IGNORE_CVES ?

> +  +<VULN-ID>+. This variable needs to be set only if the referenced +<VULN-ID>+
> +  is not fixed by a patch present in the Buildroot tree. It support different
> +  labels based on
> +  https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-labels[OpenVex
> +  statuses] and
> +  https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#status-justifications[justification]:
> +  ** +fixed+: referenced by the package Makefile already includes the fix but

I'm sorry but here I'm unable to parse this sentence "referenced by
the package Makefile already includes the fix", is my English too
limited, or does the sentence really has an issue?

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot