On Fri, May 30, 2025 at 06:00:14PM -0700, Chris Lamb wrote: > Adrian Bunk wrote: > > > Easiest for security support would be keeping Redis/trixie with > > identical licence (and with a closer codebase) to Valkey, and > > then treat Valkey as upstream for Redis/trixie security support. > > I see your point. I think we are simply comparing the subjective > difference between being able to apply the same patch for Valkey for > both Valkey and against the (old) version of Redis in trixie, versus > applying a Valkey patch against Valkey and a Redis patch against Redis.
The most important difference is whether it will be legal to apply the Redis/trixie patch against Redis/bookworm. Until mid-2026 Debian does support bookworm, and Redis DSAs will usually cover both. Can a person who has seen the Redis/trixie fix work on fixing Redis/bookworm if Redis/trixie gets upgraded to 8.0? That's a tricky legal question. Copying the patch used in Redis/trixie into Redis/bookworm would likely be illegal if Redis/trixie gets upgraded to 8.0. During the lifetime of trixie, Redis and Valkey will usually have DSAs for the same CVEs. Can the person preparing a Redis DSA in trixie also prepare the Valkey DSA if Redis/trixie gets upgraded to 8.0? That's a tricky legal question. > I will note that Redis are releasing fairly nice stable point releases > similar to how Django does it. Indeed, 8.0.2 was released earlier > today, and it would be nice if we could release these updates via > security or pu. Obviously, we would not be able to do this if we > shipped 7.0.15 in trixie >... Using stable point releases is less work but higher regression risk since they also contain other changes. Redis/Valkey security fixes tend to be small and with testcases, they are usually not hard to backport. >From a practical point of view, during the next 8 years Redis/trixie will often be fixed by the same person who fixes Redis/bookworm in (old)stable/(E)LTS. Except for 2 broken tests from a recent CVE fix in trixie that are fixed in bookworm,[1] the Redis code in bookworm and trixie is currently identical. What was your plan for supporting Redis in trixie before the second licence change this month? For 2 years Redis 7.2 (with the original licence) was in experimental. Redis 7.2 could have been security supported in trixie through point releases for the next 9 months. Why was Redis 7.2 never uploaded to unstable? Compared to redis/trixie, redis/unstable has some new testsuite failures: - memefficiency.tcl on amd64/i386 - logging.tcl on armhf/armel - logging.tcl on ppc64el - logging.tcl on s390x (the latter three might or might not be distinct issues) What are the root causes of these new failures? > Regards, cu Adrian [1] Redis packaging ignores test failures from the exhaustive upstream test suite, and the autopkgtest is barely more than a smoke test