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
