| Message ID | 20200621213921.11923-1-peter@korsgaard.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [PATCH=2020.02.x] package/redis: bump version to 5.0.9 | expand |
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>
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
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
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!
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
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" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes: > 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 True. Committed to 2020.02.x and 2020.05.x after adding the CVE info.
>>>>> "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.
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
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
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(-)