[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Peter Korsgaard]

Fixes a critical issue related to streams. From the release notes:

================================================================================
Redis 5.0.9     Released Thu Apr 17 12:41:00 CET 2020
================================================================================

Upgrade urgency:CRITICAL if you use Streams with AOF ore replicas.
                Otherwise the upgrade urgency is LOW.

This release has a speed improvement and a critical fix:

    * FIX: XREADGROUP when fetching data in a blocking way, would not
           emit the XCLAIM in the AOF file and to replicas. This means
           that the last ID is not updated, and that restarting the server
           will have the effect of reprocessing some entries.
    * NEW: Clients blocked on the same key are now unblocked on
           O(1) time. Backported from Redis 6.

Commits:

    1fc8ef81a Fix XCLAIM propagation in AOF/replicas for blocking XREADGROUP.
    a5e24eabc Speedup: unblock clients on keys in O(1).

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 package/redis/redis.hash | 2 +-
 package/redis/redis.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/redis/redis.hash b/package/redis/redis.hash
index ee15b75e08..7fd6f1b0df 100644
--- a/package/redis/redis.hash
+++ b/package/redis/redis.hash
@@ -1,5 +1,5 @@
 # From https://github.com/antirez/redis-hashes/blob/master/README
-sha256 f3c7eac42f433326a8d981b50dba0169fdfaf46abb23fcda2f933a7552ee4ed7  redis-5.0.8.tar.gz
+sha256 53d0ae164cd33536c3d4b720ae9a128ea6166ebf04ff1add3b85f1242090cb85  redis-5.0.9.tar.gz
 
 # Locally calculated
 sha256 cbf420a3672475a6e2765e3c0984c1f81efe0212afb94a3c998ee63bfd661063  COPYING
diff --git a/package/redis/redis.mk b/package/redis/redis.mk
index d3954d87ca..baef2e235f 100644
--- a/package/redis/redis.mk
+++ b/package/redis/redis.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-REDIS_VERSION = 5.0.8
+REDIS_VERSION = 5.0.9
 REDIS_SITE = http://download.redis.io/releases
 REDIS_LICENSE = BSD-3-Clause (core); MIT and BSD family licenses (Bundled components)
 REDIS_LICENSE_FILES = COPYING
-- 
2.20.1

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Titouan Christophe]

Hello Peter and all,

On 21/06/20 23:39, Peter Korsgaard wrote:
> Fixes a critical issue related to streams. From the release notes:
> 
> ================================================================================
> Redis 5.0.9     Released Thu Apr 17 12:41:00 CET 2020
> ================================================================================
> 
> Upgrade urgency:CRITICAL if you use Streams with AOF ore replicas.
>                  Otherwise the upgrade urgency is LOW.
> 
> This release has a speed improvement and a critical fix:
> 
>      * FIX: XREADGROUP when fetching data in a blocking way, would not
>             emit the XCLAIM in the AOF file and to replicas. This means
>             that the last ID is not updated, and that restarting the server
>             will have the effect of reprocessing some entries.
>      * NEW: Clients blocked on the same key are now unblocked on
>             O(1) time. Backported from Redis 6.
> 
> Commits:
> 
>      1fc8ef81a Fix XCLAIM propagation in AOF/replicas for blocking XREADGROUP.
>      a5e24eabc Speedup: unblock clients on keys in O(1).
> 
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>Acked-by: Titouan Christophe <titouan.christophe@railnova.eu>

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas De Schampheleire]

Hello,

El lun., 22 jun. 2020 a las 9:49, Titouan Christophe (<
titouan.christophe@railnova.eu>) escribi?:

> Hello Peter and all,
>
> On 21/06/20 23:39, Peter Korsgaard wrote:
> > Fixes a critical issue related to streams. From the release notes:
> >
> >
> ================================================================================
> > Redis 5.0.9     Released Thu Apr 17 12:41:00 CET 2020
> >
> ================================================================================
> >
> > Upgrade urgency:CRITICAL if you use Streams with AOF ore replicas.
> >                  Otherwise the upgrade urgency is LOW.
> >
> > This release has a speed improvement and a critical fix:
> >
> >      * FIX: XREADGROUP when fetching data in a blocking way, would not
> >             emit the XCLAIM in the AOF file and to replicas. This means
> >             that the last ID is not updated, and that restarting the
> server
> >             will have the effect of reprocessing some entries.
> >      * NEW: Clients blocked on the same key are now unblocked on
> >             O(1) time. Backported from Redis 6.
> >
> > Commits:
> >
> >      1fc8ef81a Fix XCLAIM propagation in AOF/replicas for blocking
> XREADGROUP.
> >      a5e24eabc Speedup: unblock clients on keys in O(1).
> >
> > Signed-off-by: Peter Korsgaard <peter@korsgaard.com>Acked-by: Titouan
> Christophe <titouan.christophe@railnova.eu>
>
>
Just want to highlight that also the 5.0.8 turns out to have a security
fix: http://cve.circl.lu/cve/CVE-2020-14147

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) ?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200629/c8f3d5e7/attachment.html>

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas Petazzoni]

Hello,

On Mon, 29 Jun 2020 12:51:02 +0200
Thomas De Schampheleire <patrickdepinguin@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.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas De Schampheleire]

El lun., 29 jun. 2020 a las 14:07, Thomas Petazzoni (<
thomas.petazzoni@bootlin.com>) escribi?:

> Hello,
>
> On Mon, 29 Jun 2020 12:51:02 +0200
> Thomas De Schampheleire <patrickdepinguin@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.
>

That sounds great, this will be very useful!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200629/a7ff9c57/attachment.html>

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Titouan Christophe]

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@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

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas Petazzoni]

Hello,

On Mon, 29 Jun 2020 17:30:49 +0200
Titouan Christophe <titouan.christophe@railnova.eu> wrote:

> 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.

True.

> 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, ...).

I hadn't thought of it this way.

> 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

Is this really a relevant advantage ?

> - 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 ?)

The tooling Gr?gory is doing is using the "make show-info" output as an
input to know what packages are enabled (and their version, ignored
CVEs, etc.) and does a match against the NVD database. The code doing
the match against the NVD database is factored out from the pkg-stats
script so that it is shared.

> - 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.

Well, the frontend from Heiko also needs the dynamic information
(release-monitoring, NVD) and so from that perspective splitting out
the "static" info from the "dynamic" info.

All in all, I don't know. Perhaps it could be useful, but the few
arguments to my eyes don't really bring any new really useful great
feature.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

 > Hello,
 > El lun., 22 jun. 2020 a las 9:49, Titouan Christophe (<
 > titouan.christophe at railnova.eu>) escribi?:

 >> Hello Peter and all,
 >> 
 >> On 21/06/20 23:39, Peter Korsgaard wrote:
 >> > Fixes a critical issue related to streams. From the release notes:
 >> >
 >> >
 >> ================================================================================
 >> > Redis 5.0.9     Released Thu Apr 17 12:41:00 CET 2020
 >> >
 >> ================================================================================
 >> >
 >> > Upgrade urgency:CRITICAL if you use Streams with AOF ore replicas.
 >> >                  Otherwise the upgrade urgency is LOW.
 >> >
 >> > This release has a speed improvement and a critical fix:
 >> >
 >> >      * FIX: XREADGROUP when fetching data in a blocking way, would not
 >> >             emit the XCLAIM in the AOF file and to replicas. This means
 >> >             that the last ID is not updated, and that restarting the
 >> server
 >> >             will have the effect of reprocessing some entries.
 >> >      * NEW: Clients blocked on the same key are now unblocked on
 >> >             O(1) time. Backported from Redis 6.
 >> >
 >> > Commits:
 >> >
 >> >      1fc8ef81a Fix XCLAIM propagation in AOF/replicas for blocking
 >> XREADGROUP.
 >> >      a5e24eabc Speedup: unblock clients on keys in O(1).
 >> >
 >> > Signed-off-by: Peter Korsgaard <peter@korsgaard.com>Acked-by: Titouan
 >> Christophe <titouan.christophe@railnova.eu>
 >> 

 > Just want to highlight that also the 5.0.8 turns out to have a security
 > fix: http://cve.circl.lu/cve/CVE-2020-14147

True. Committed to 2020.02.x and 2020.05.x after adding the CVE info.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:

Hi,

 >> Just want to highlight that also the 5.0.8 turns out to have a security
 >> fix: http://cve.circl.lu/cve/CVE-2020-14147

 > True. Committed to 2020.02.x and 2020.05.x after adding the CVE info.

Ehh, looking closer we already had 5.0.8, so I've just committed as is.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas De Schampheleire]

El dom., 5 jul. 2020 a las 22:48, Peter Korsgaard (<peter@korsgaard.com>)
escribi?:

> >>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
>
> Hi,
>
>  >> Just want to highlight that also the 5.0.8 turns out to have a security
>  >> fix: http://cve.circl.lu/cve/CVE-2020-14147
>
>  > True. Committed to 2020.02.x and 2020.05.x after adding the CVE info.
>
> Ehh, looking closer we already had 5.0.8, so I've just committed as is.
>

beeuh, I blame it on git :-D

It seems I had a branch '2020.02.x' which was not tracking
remotes/origin/2020.02.x thus eclipsing new changes and giving me basic
commands like 'git log 2020.02.x package/redis' incorrect results.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200706/5f95c353/attachment.html>