[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9
Titouan Christophe
titouan.christophe at railnova.eu
Mon Jun 29 15:30:49 UTC 2020
Hello Thomas and Thomas,
On 29/06/20 14:07, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 29 Jun 2020 12:51:02 +0200
> Thomas De Schampheleire <patrickdepinguin at gmail.com> wrote:
>
>> Which reminds me of the fact that the package stats and associated CVE
>> detection is currently only running on the master branch (that I know of).
>> Which means that we are missing the CVE detection on the LTS branch.
>> Does it take a lot of resources / Is it hard to do, enabling this on the
>> LTS branch too (mostly the CVE part) ?
>
> Running pkg-stats on other branches is really easy, I can make it
> generate autobuild.buildroot/stats/2020.02.x.{html,json} for example.
>
> However, what needs a bit more effort is to modify the e-mail
> notification script to make use of that.
>
> Note that my colleague Grégory is working on improving the CVE
> infrastructure so that you can run a script on your specific Buildroot
> version and configuration, and get the list of CVEs you are affected
> by. I.e the same results as pkg-stats, but really tailored to your
> Buildroot version/configuration. Hopefully Grégory will send the
> patches soon.
Generally speaking, pkg-stats does 2 different things:
1. Collect information about the packages in the Buildroot tree
(version, number of patches, developers, ...). This information changes
with the Buildroot tree, and is therefore *STATIC* for a given version
of Buildroot.
2. Matching the packages against CVEs and release-monitoring. This
information is *DYNAMIC* and can change anytime, because it is based on
services that are independent of Buildroot.
Therefore, we could split this process in two distinct parts:
First, collecting the packages information into a static JSON file (or
any other format you like), like some kind of "manifest". This could be
done once for each release of Buildroot, and in a nightly job for
master/next/<whatever dev branch>. Maybe we could even reuse (some parts
of) `make show-info` for that purpose ?
Secondly, check the CVEs and new pkg versions using as input the static
"manifest" file obtained above. This could be done in a nightly job for
all the active releases of Buildroot (latest LTS and "regular" release,
master, next, ...).
This would provide the following advantages:
- No need to have a full BR tree to generate the CVEs/outdated packages
list (only the "manifest") => easier to run for multiple BR versions and
to run in parallel
- The "manifest" can be stripped down to the list of packages used in a
particular BR config, such as to customize the pkg-stat output to what
is relevant to the user (what your colleague Gregory is working on if I
understand correctly ?)
- This makes it easier to plug a frontend (like the one Heiko was
working on) describing the packages available in a certain BR release,
and optionally the daily regenerated stats of these packages.
- This would slightly reduce the runtime of pkg-stat (a non-negligeable
part is spent collecting pkg data).
Kind regards,
Titouan
More information about the buildroot
mailing list