1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1106871: unblock: redis/5:8.0.0-2

    From Chris Lamb@21:1/5 to All on Fri May 30 21:50:02 2025
    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)
  • From Paul Gevers@21:1/5 to Chris Lamb on Fri May 30 22:00:02 2025
    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)
  • From Adrian Bunk@21:1/5 to Chris Lamb on Sat May 31 00:20:01 2025
    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)
  • From Chris Lamb@21:1/5 to Adrian Bunk on Sat May 31 03:20:01 2025
    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)
  • From Adrian Bunk@21:1/5 to Chris Lamb on Sat May 31 13:00:01 2025
    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)