XPost: linux.debian.devel.release

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: redis@packages.debian.org
Control: affects -1 + src:redis
User: release.debian.org@packages.debian.org
Usertags: unblock

Please unblock redis for trixie.

The recent Redis 8 licensing change came really late in Debian's
release cycle, but I believe we should ship Redis 8 in trixie.

Otherwise we are shipping a rather old version of the server (7.0.15)
that upstream will have absolutely no interest in supporting over the
lifetime that we want to support it, and it will make the inevitable
security backports arduous for us as well.

A new way of managing the client's state within the server's codebase exacerbates this problem, making fairly trivial changes to the code
difficult to reason about at times. (In fact, I'm actually already
encountering this issue: a new CVE landed a few hours ago, and I can
already sense that backporting it to the 7.0.15 version will be a pain.)

Indeed, I think that the advantages of migrating Redis 8 to trixie,
even at this stage of the freeze, outweigh the disadvantages of
shipping 7.0.15 in trixie — or, perhaps even worse, not shipping Redis
at all.

Not that it is determinative, but I've spent a good amount of time in
the past two weeks running around trying to get the other parts of the
Redis into shape in order to make this unblock.

For example, python-redis (6.1.0-1, 6.1.0-2), python-fakeredis
(2.29.0-1 through 2.29.0-4), and fixes for libtest-redisserver-perl
and python-hypothesis (they reverse-depend on Redis in its tests).

At the time of writing, britney is reporting "Too young, only 17 of 20
days old", but I thought I would start this conversation now given freeze_policy.html's request to ask the RT if maintainers are unsure.


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org 🍥 chris-lamb.co.uk
`-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release
To: 1106871@bugs.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------u4RprQeRUex8iMa2ZrCD71tw
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIDMwLTA1LTIwMjUgMjE6MzIsIENocmlzIExhbWIgd3JvdGU6DQo+IEZvciBl eGFtcGxlLCBweXRob24tcmVkaXMgKDYuMS4wLTEsIDYuMS4wLTIpLCBweXRob24tZmFrZXJl ZGlzDQo+ICgyLjI5LjAtMSB0aHJvdWdoIDIuMjkuMC00KSwgYW5kIGZpeGVzIGZvciBsaWJ0 ZXN0LXJlZGlzc2VydmVyLXBlcmwNCj4gYW5kIHB5dGhvbi1oeXBvdGhlc2lzICh0aGV5IHJl dmVyc2UtZGVwZW5kIG9uIFJlZGlzIGluIGl0cyB0ZXN0cykuDQoNCg0KQXMgeW91IG5vdGlj ZWQsIEkndmUgYmVlbiB3YXRjaGluZyBvdXQgdG9vLg0KDQo+IEF0IHRoZSB0aW1lIG9mIHdy aXRpbmcsIGJyaXRuZXkgaXMgcmVwb3J0aW5nICJUb28geW91bmcsIG9ubHkgMTcgb2YgMjAN Cj4gZGF5cyBvbGQiLCBidXQgSSB0aG91Z2h0IEkgd291bGQgc3RhcnQgdGhpcyBjb252ZXJz YXRpb24gbm93IGdpdmVuDQo+IGZyZWV6ZV9wb2xpY3kuaHRtbCdzIHJlcXVlc3QgdG8gYXNr IHRoZSBSVCBpZiBtYWludGFpbmVycyBhcmUgdW5zdXJlLg0KDQoNCkFzIHJlZGlzIGlzIGEg a2V5IHBhY2thZ2UsIGl0IG5lZWRzIGFuIHVuYmxvY2sgYW55d2F5cy4gSSd2ZSBiZWVuIA0K c2hlcGhlcmRpbmcgaXQgYWxyZWFkeSB0aGUgbGFzdCB0d28gd2Vla3MuIEknbGwgcHJvYmFi bHkgdGFrZSBhIGZpbmFsIA0KbG9vayB0b21vcnJvdy4NCg0KUGF1bA0KDQo=

--------------u4RprQeRUex8iMa2ZrCD71tw--

-----BEGIN PGP SIGNATURE-----

wsC7BAABCABvBYJoOg0DCRCcXJnrBb11CkcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfgCzAGoZZqFxRwY2etmWoNl9CpDwChq5CtI428UEyh UxYhBFi2bUhza+k7BS3mcpxcmesFvXUKAABV6ggAt2weGvDj/a+cGWQgmRB4TRYP 2FCLSArzfrfAV9A7YT09xqXJAmUEJAl/pnX5bYvXb6y/HV1StpeS5ZTse4Dj2eVf xv9/UjaalULKAa6KfLINd1y1kHgYD/n39gHXfSVB02KhT+ZHo2lRzNrgFy+n8eLj WXkBCoJZzdtARnxJSPw1UfbwAKKGUMEd6yRL/PLO3FGykASA7atq5Tku5kaPUs/I v56WTVQhoWwjDr008Pflwof4iA+vgSuxqutKRrtY4rpc/rnKaoWOOqsVaX61ocD6 1EYQl0KXKnZJF38V/qlbG2sr2dyombX29ApA4Dnim5VJDvdFrwW7WQSydoioZA==
=nhWk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Fri, May 30, 2025 at 12:32:56PM -0700, Chris Lamb wrote:

...
Please unblock redis for trixie.
...
Otherwise we are shipping a rather old version of the server (7.0.15)
that upstream will have absolutely no interest in supporting over the lifetime that we want to support it, and it will make the inevitable
security backports arduous for us as well.

Shipping 8.0 in trixie would actually cause really arduous security support.

Right now Redis and Valkey are relatively similar codebases,
and have the same licence.

In trixie both will usually require fixes for the same CVEs.

A new way of managing the client's state within the server's codebase exacerbates this problem, making fairly trivial changes to the code
difficult to reason about at times.

Arduous is not be that code would diverge.

I did the last 3 rounds of Redis security fixes for all releases from
bookworm to jessie, and backporting security fixes was not particularly difficult.

Arduous for security support would be that due to the Redis licence
changes Redis/trixie would have licences (AGPL and others) different
from both Redis/bookworm (BSD) and Valkey/trixie (BSD).

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.

From March 2024 until May 2025 the latest Redis version was available
only under non-free licences, in time for forky we might see whether
the corporate backers of Valkey[1] and the ecosystem will move back to
Redis, or whether Valkey will be the one that stays, or whether both
Redis and Valkey will stay popular.

(In fact, I'm actually already
encountering this issue: a new CVE landed a few hours ago, and I can
already sense that backporting it to the 7.0.15 version will be a pain.)
...

I already looked at CVE-2025-27151 on Thursday, it should be trivial
to fix and I can submit that for trixie together with my fix for
CVE-2025-21605 (the latter was in unstable before).

Regards,

cu
Adrian

[1] https://valkey.io/participants/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

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.

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 — a version, I should also add, that Redis
users will likely be warned away from using by upstream and others
(:/).


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org 🍥 chris-lamb.co.uk
`-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)