From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] CVEs not matching buildroot packages
Date: Wed, 18 Mar 2020 15:12:56 +0100 [thread overview]
Message-ID: <20200318151256.2c7e9c11@windsurf.home> (raw)
In-Reply-To: <CAEyMn7bDcNOW4ty0sPgOg4WexfZ+uR+HoRvR3M+e-ObrWYKJJA@mail.gmail.com>
Hello,
On Wed, 18 Mar 2020 14:57:27 +0100
Heiko Thiery <heiko.thiery@gmail.com> wrote:
> Just to go on with this I did a proof of concept for the CVE mapping.
>
> A first version can be found here:
> https://github.com/hthiery/buildroot/tree/feature-cve-map
>
> What this change does:
> Add a new file format for the CVE mapping: <pkg>.cve. This is done in
> YAML format. In this file at least the fields vendor and product has
> to be defined. With this we can create a map from the CVE to the
> buildroot package name.
> Now we can decide the following:
> 1) the package has a mapping and is affected by a CVE (RED ZONE)
> 2) the package has a mapping and a CVE is found but fixed (GREEN ZONE)
> 3) the package has a mapping and no CVE is found (GREEN ZONE)
> 4) the package has no mapping and it is affected by CVE found by guess
> (try to compare buildroot name vs. CVE product name value) (YELLOW
> ZONE)
> 5) the package has no mapping and no CVE is found (we don't konw if
> there isn't a CVE or we have no match because the buildroot name does
> not match the CVE product name) (GREY ZONE)
>
> Here is an example of a yaml file: package/pppd/ppd.cve
> --- snip ---
> vendor: point-to-point_protocol_project
> product: point-to-point_protocol
>
> cves:
> CVE-2020-8597:
> patch: 0001-pppd-Fix-bounds-check.patch
>
> --- snip ---
>
> To take the decision if a CVE is fixed there could be more possible
> reasons instead of the patch in the example above. I can image
> something like 'does-not-apply'.
>
> I think the effort to have an extra file is not so much and it will
> not pollute the Makefile with variables that are not build related.
> For checking the YAML syntax an extra pkg-check can be implemented.
>
> As mentioned at the beginning this is first idea how a mapping could
> look. What do you think?
I'll give my very quick and probably very blunt and brutal feedback: I
don't like having another file with package metadata. This metadata
should be in the .mk file.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-03-18 14:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 8:58 [Buildroot] CVEs not matching buildroot packages Michael Walle
2020-02-25 9:46 ` Thomas Petazzoni
2020-02-25 10:19 ` Michael Walle
2020-02-25 10:29 ` Thomas Petazzoni
2020-02-25 12:41 ` Michael Walle
2020-03-18 13:57 ` Heiko Thiery
2020-03-18 14:12 ` Thomas Petazzoni [this message]
2020-03-18 14:34 ` Heiko Thiery
2020-10-06 19:09 ` Matthew Weber
-- strict thread matches above, loose matches on Subject: below --
2020-02-25 19:21 Akshay Bhat
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=20200318151256.2c7e9c11@windsurf.home \
--to=thomas.petazzoni@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.