...
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.
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.)
...
Regards,
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.
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
...
Regards,
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 493 |
Nodes: | 16 (2 / 14) |
Uptime: | 161:18:24 |
Calls: | 9,700 |
Files: | 13,732 |
Messages: | 6,179,757 |