Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC v9 01/10] cpe-info: new make target
Date: Wed, 01 Jul 2020 09:43:10 +0200	[thread overview]
Message-ID: <87ftabbrzl.fsf@FE-laptop> (raw)
In-Reply-To: <20200625130055.5062a0a0@windsurf>

Hello,

>> +$(2)_CPE_ID_VENDOR ?= $$($(2)_NAME)_project
>> +$(2)_CPE_ID_NAME ?= $$($(2)_NAME)
>> +$(2)_CPE_ID_VERSION ?= $$($(2)_VERSION)
>> +$(2)_CPE_ID ?= $$($(2)_CPE_ID_VENDOR):$$($(2)_CPE_ID_NAME):$$($(2)_CPE_ID_VERSION)
>
> These variables should be documented in the Buildroot manual.
>
> I see you set some default values for those CPE_ID values, but I am
> wondering if that's how we want to do this. Indeed a big question,
> which was discussed in a thread earlier this year between Michael
> Walle, Akshay Bhat and me is that how do we then distinguish packages
> for which the CPE information in Buildroot has been verified and is
> known to be correct, from packages that have the CPE information not
> verified, and even further from packages that don't have any CPE
> information because this specific package is not known in the NVD
> database.
>
> So I'd like to see a proposal that clarifies how we are going to handle
> this. One way is to *not* have any default value for those CPE
> variables, and add them to packages progressively, so that we know that
> when the CPE information is there, it _has_ been verified.
>
> It's not great because it means adding gazillions of CPE_ID information
> in packages. But is there any other option ?

I am working on a adding a tool allowing to check the cve status of a
given configuration. I am about to submit it. For now I base my check on
the buildroot package name as it is done in pkg-stat, but as you know
there are some mismatch. At a point there will be the need to use the
CPE information, so I have already had to think on how to manage it.

I already have to deal with failure when checking if a version was
affected by a CVE. And for this situation I choose to report that
failure instead of considering the package being affected or not by
default. The idea is to, later, be able to fix the failure but in the
meantime being aware of it.

For package name I would use a similar approach: if there is no CPE_ID
provided then try to use the package name but in this case report that
it has to be checked manually, while if there is a CPE_ID then use it as
a reliable name. So I am clearly in favor on the second option proposed
by Thomas. The ultimate goal is to have a CPE_ID information in each
package but in the meantime there is a path to achieve this.

Gregory

>
> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

  reply	other threads:[~2020-07-01  7:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 17:03 [Buildroot] [RFC v9 01/10] cpe-info: new make target Matt Weber
2020-06-16 17:03 ` [Buildroot] [RFC v9 02/10] cpe-info: id prefix/suffix Matt Weber
2020-06-21  9:23   ` Yann E. MORIN
2020-06-22 11:34     ` Matthew Weber
2020-06-25 11:04   ` Thomas Petazzoni
2020-06-16 17:03 ` [Buildroot] [RFC v9 03/10] cpe-info: only report target pkgs Matt Weber
2020-06-21  8:56   ` Yann E. MORIN
2020-06-22 11:35     ` Matthew Weber
2020-06-16 17:03 ` [Buildroot] [RFC v9 04/10] cpe-info: cpe minor version support Matt Weber
2020-06-16 17:03 ` [Buildroot] [RFC v9 05/10] toolchain/toolchain-ext: glibc cpe-info support Matt Weber
2020-06-25 11:09   ` Thomas Petazzoni
2020-06-16 17:03 ` [Buildroot] [RFC v9 06/10] cpe-info: update manual for new pkg vars Matt Weber
2020-06-25 11:12   ` Thomas Petazzoni
2020-06-16 17:03 ` [Buildroot] [RFC v9 07/10] support/scripts/cpedb.py: new CPE XML helper Matt Weber
2020-06-25 11:14   ` Thomas Petazzoni
2020-06-16 17:03 ` [Buildroot] [RFC v9 08/10] support/scripts/cpe-report: new script Matt Weber
2020-06-25 11:18   ` Thomas Petazzoni
2020-06-16 17:03 ` [Buildroot] [RFC v9 09/10] docs/manual: new security management section Matt Weber
2020-06-16 17:03 ` [Buildroot] [RFC v9 10/10] packages: fixup of cpe info Matt Weber
2020-06-21  8:45 ` [Buildroot] [RFC v9 01/10] cpe-info: new make target Yann E. MORIN
2020-06-22 11:44   ` Matthew Weber
2020-06-22 20:55     ` Frank Hunleth
2020-06-25 11:00 ` Thomas Petazzoni
2020-07-01  7:43   ` Gregory CLEMENT [this message]
2020-07-01 11:57     ` Thomas Petazzoni

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=87ftabbrzl.fsf@FE-laptop \
    --to=gregory.clement@bootlin.com \
    --cc=buildroot@busybox.net \
    /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