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

Reply via email to