Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Colin Watson wrote: >>>Retrying these tests now… okay, no change in the results. Wish we >>>had 'reference' tests on Debusine like we do on the Freexian CI! >> >>Seeing this is a permission issue, is debusine's autopkgtest always >>failing on debusine infrastructure? I assume so. As the release date >>is getting close, can we have the upload please? > > It's likely because of insufficient isolation of some kind, since those > test cases require either a privileged container or a VM, and Debusine > doesn't necessarily pick the right defaults for that sort of thing at > the moment. It should work on ci.debian.net, so please just ignore this > failure for now. Okay, uploading with the patch now. Incidentally, the patch (or a very minor variant thereof) will be accepted by upstream: https://github.com/redis/redis/pull/14195 Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
On Thu, Jul 17, 2025 at 02:03:37PM +0100, Colin Watson wrote: On Thu, Jul 17, 2025 at 01:33:12PM +0200, Paul Gevers wrote: Seeing this is a permission issue, is debusine's autopkgtest always failing on debusine infrastructure? I assume so. As the release date is getting close, can we have the upload please? It's likely because of insufficient isolation of some kind, since those test cases require either a privileged container or a VM, and Debusine doesn't necessarily pick the right defaults for that sort of thing at the moment. It should work on ci.debian.net, so please just ignore this failure for now. https://salsa.debian.org/freexian-team/debusine/-/merge_requests/2066 should at least make this clearer. But there's no need to block on that from the redis point of view. -- Colin Watson (he/him) [[email protected]]
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
On Thu, Jul 17, 2025 at 01:33:12PM +0200, Paul Gevers wrote: On 15-07-2025 19:17, Chris Lamb wrote: The failure in debusine's autopkgtest is a bit opaque to me, can it be retried on the debusine infrastructure to check if it's flaky? Retrying these tests now… okay, no change in the results. Wish we had 'reference' tests on Debusine like we do on the Freexian CI! Seeing this is a permission issue, is debusine's autopkgtest always failing on debusine infrastructure? I assume so. As the release date is getting close, can we have the upload please? It's likely because of insufficient isolation of some kind, since those test cases require either a privileged container or a VM, and Debusine doesn't necessarily pick the right defaults for that sort of thing at the moment. It should work on ci.debian.net, so please just ignore this failure for now. -- Colin Watson (he/him) [[email protected]]
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Hi, On 15-07-2025 19:17, Chris Lamb wrote: The failure in debusine's autopkgtest is a bit opaque to me, can it be retried on the debusine infrastructure to check if it's flaky? Retrying these tests now… okay, no change in the results. Wish we had 'reference' tests on Debusine like we do on the Freexian CI! Seeing this is a permission issue, is debusine's autopkgtest always failing on debusine infrastructure? I assume so. As the release date is getting close, can we have the upload please? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Hi Paul, > I do regularly wonder how smart tests like these are, to check for some > magic string in an output. A change like this shouldn't cause issues. Indeed. (Curiously, I think we hit a similar issue with one of the Perl Redis libraries as well.) >> I've also prepared another upload (5:8.0.2-3) that simply includes this >> change (debdiff attached), > > But yes, let's do this now to resolve it. But I'd not push to hard on > upstream to put this back, instead python-redis could improve their > testing instead. But I'll leave that to you. Agreed — I won't push too hard as it could also be fixed there. >> https://debusine.debian.net/debian/developers/work-request/120838/ >> >> The errors here are for gitlab and php-horde-hashtable (bad >> dependencies), and proftpd-dfsg fails too, although outside of any >> Redis-related tests. > > The failure in debusine's autopkgtest is a bit opaque to me, can it be > retried on the debusine infrastructure to check if it's flaky? Retrying these tests now… okay, no change in the results. Wish we had 'reference' tests on Debusine like we do on the Freexian CI! Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Hi Chris, On 14-07-2025 21:47, Chris Lamb wrote: Still, I think it's a bug that said output does not contain the version number as all the previous versions of the LOLWUT output do. I do regularly wonder how smart tests like these are, to check for some magic string in an output. A change like this shouldn't cause issues. I've also prepared another upload (5:8.0.2-3) that simply includes this change (debdiff attached), But yes, let's do this now to resolve it. But I'd not push to hard on upstream to put this back, instead python-redis could improve their testing instead. But I'll leave that to you. https://debusine.debian.net/debian/developers/work-request/120838/ The errors here are for gitlab and php-horde-hashtable (bad dependencies), and proftpd-dfsg fails too, although outside of any Redis-related tests. The failure in debusine's autopkgtest is a bit opaque to me, can it be retried on the debusine infrastructure to check if it's flaky? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Hi Paul, > The test fails with LOLWUT in the error message and I also > see LOLWUT improvements mentioned in the redis diff. Is this unintended > behavior change? Oh, sigh. It does appear to be kinda "intended" and that command's 'Easter Egg' status meant that I paid little attention to the changes… especially as they were made in 8.0.2 and not in 8.0.0 where one might expect them. Still, I think it's a bug that said output does not contain the version number as all the previous versions of the LOLWUT output do. To that end, I've patched [0] Redis and forwarded the change to upstream [1]. [0] https://salsa.debian.org/lamby/pkg-redis/-/commit/aaa4dfc7442ff78fcda766faf2a184342713de9b [1] https://github.com/redis/redis/pull/14195 I've also prepared another upload (5:8.0.2-3) that simply includes this change (debdiff attached), and here is a Debusine run that shows the lack of python-redis regression: https://debusine.debian.net/debian/developers/work-request/120838/ The errors here are for gitlab and php-horde-hashtable (bad dependencies), and proftpd-dfsg fails too, although outside of any Redis-related tests. Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `- diff --git debian/changelog debian/changelog index 96a4fe78..b1c8d019 100644 --- debian/changelog +++ debian/changelog @@ -1,3 +1,11 @@ +redis (5:8.0.2-3) unstable; urgency=medium + + * Add a patch to re-add "Redis ver. $REDIS_VERSION" output to the LOLWUT +~Easter Egg command output as a some testsuites were relying on it +existing. This upstream change was made in 8.0.2, not in 8.0.0. + + -- Chris Lamb Mon, 14 Jul 2025 09:47:32 -0700 + redis (5:8.0.2-2) unstable; urgency=high * CVE-2025-32023: An authenticated user may have used a specially-crafted diff --git debian/patches/0007-Add-Redis-ver.-REDIS_VERSION-to-LOLWUT-8-output-as-a.patch debian/patches/0007-Add-Redis-ver.-REDIS_VERSION-to-LOLWUT-8-output-as-a.patch new file mode 100644 index ..1dbde061 --- /dev/null +++ debian/patches/0007-Add-Redis-ver.-REDIS_VERSION-to-LOLWUT-8-output-as-a.patch @@ -0,0 +1,27 @@ +From: Chris Lamb +Date: Mon, 14 Jul 2025 09:37:07 -0700 +Subject: Add "Redis ver. $REDIS_VERSION" to LOLWUT 8 output as a some + testsuites were relying on it. + +eg. python-redis (https://github.com/redis/redis-py/blob/master/tests/test_commands.py#L1092) + +Forwarded: https://github.com/redis/redis/pull/14195 +--- + src/lolwut8.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/src/lolwut8.c b/src/lolwut8.c +index 1be150e..363a30e 100644 +--- a/src/lolwut8.c b/src/lolwut8.c +@@ -170,7 +170,9 @@ void lolwut8Command(client *c) { + "\nIn 1961, Nanni Balestrini created one of the first computer-generated poems, TAPE MARK I, using an IBM 7090 mainframe. Each execution combined verses from three literary sources following algorithmic rules based on metrical compatibility and group constraints. This LOLWUT command reproduces Balestrini's original algorithm, generating new stanzas through the same computational poetry process described in Almanacco Letterario Bompiani, 1962.\n\n" + "https://en.wikipedia.org/wiki/Digital_poetry\n"; + "https://www.youtube.com/watch?v=8i7uFCK7G0o (English subs)\n\n" +-"Use: LOLWUT IT for the original Italian output.\n\n"); ++"Use: LOLWUT IT for the original Italian output. Redis ver. "); ++combined = sdscat(combined,REDIS_VERSION); ++combined = sdscat(combined,"\n\n"); + + addReplyVerbatim(c,combined,sdslen(combined),"txt"); + sdsfree(combined); diff --git debian/patches/series debian/patches/series index 6ecbeef8..bbca56e3 100644 --- debian/patches/series +++ debian/patches/series @@ -5,3 +5,4 @@ debian-packaging/0001-Set-Debian-configuration-defaults.patch 0004-Add-support-for-USE_SYSTEM_JEMALLOC-flag.patch 0005-CVE-2025-32023.patch 0006-CVE-2025-48367.patch +0007-Add-Redis-ver.-REDIS_VERSION-to-LOLWUT-8-output-as-a.patch
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Hi Chris, On 12-07-2025 20:15, Chris Lamb wrote: Thanks. Uploaded now via Debusine [0]. [0] https://debusine.debian.net/debian/developers/work-request/120284/ Debusine shows that the autopkgtest of python-redis fails with the new version. This regression also happens after your upload to unstable and it is blocking the migration. Can you please asses the situation and report back? The test fails with LOLWUT in the error message and I also see LOLWUT improvements mentioned in the redis diff. Is this unintended behavior change? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
tags 1108985 - moreinfo thanks Sebastian Ramacher wrote: >> Please consider pre-approval for redis 5:8.0.2-2 > > Please go ahead and remove the moreinfo tag once the package is > available in unstable. Thanks. Uploaded now via Debusine [0]. [0] https://debusine.debian.net/debian/developers/work-request/120284/ -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1108985: unblock/preapproval: redis/5:8.0.2-2
Control: tags -1 moreinfo confirmed On 2025-07-08 14:43:54 -0700, Chris Lamb wrote: > Package: release.debian.org > User: [email protected] > Usertags: unblock > > Dear Release Team, > > Please consider pre-approval for redis 5:8.0.2-2 Please go ahead and remove the moreinfo tag once the package is available in unstable. Cheers > > redis (5:8.0.2-2) unstable; urgency=high > > * CVE-2025-32023: An authenticated user may have used a specially-crafted > string to trigger a stack/heap out-of-bounds write during hyperloglog > operations, potentially leading to remote code execution. Installations > that used Redis' ACL system to restrict hyperloglog "HLL" commands are > unaffected by this issue. (Closes: #1108975) > * CVE-2025-48367: An unauthenticated connection could have caused > repeated IP > protocol errors, leading to client starvation and ultimately become a > Denial of Service (DoS) attack. (Closes: #1108981) > > redis (5:8.0.2-1) unstable; urgency=medium > > * New upstream security release: > > - CVE-2025-27151: Fix an stack-based buffer overflow in redis-check-aof > caused by the use of memcpy with strlen(filepath) when copying a > user-supplied file path into a fixed-size stack buffer. This allowed an > attacker to overflow the stack and potentially achieve arbitrary code > execution. (Closes: #1106822) > > * Update debian/watch to consider 8.x versions again after the recent > licensing change. > > -- Chris Lamb Fri, 30 May 2025 12:05:58 -0700 > > > The full debdiff is attached. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` [email protected] / chris-lamb.co.uk >`- > > -- Sebastian Ramacher
