Hi Simon, I understand regarding the freeze. In my opinion, 13.1 would be great.
I think the core Mopidy application is fine, and that's the part available in Debian. There is some exposure to souphttpsrc but I wasn't able to reproduce the deadlocks there. However, most of Mopidy's value comes from extensions (mostly distributed via PyPI etc) and it's these that are exposed to the bug, some are consequently rendered unusable. I think overall I would put the Mopidy severity at "important". Nick > Control: forwarded -1 https://gitlab.gnome.org/GNOME/libsoup/-/issues/463 > Control: tags -1 + fixed-upstream patch > Control: affects -1 + mopidy > Control: severity -1 important > > On Mon, 21 Jul 2025 at 23:50:29 +0100, Nick Steel wrote: > >Users of our GStreamer based application (Mopidy) have experienced > >deadlocks when using souphttpsrc, a GStreamer plugin built on > >libsoup-3.0. It was identified as a lock-ordering problem caused by > >libsoup's long-standing incorrect use of GLib GModule functions within > >its constructor. The libsoup fix was merged on 18/7/2025. > > (I am not really a libsoup3 maintainer, but I'm a GNOME team member, > which is the next best thing available here.) > > This fix was only merged very recently and we are about to enter hard > freeze, so the timeline to get it into 13.0 would be really tight, but > we can try. If it's too late for 13.0 then addressing it via the 13.1 > stable update seems proportionate - I expect that we will need to update > libsoup3 with additional CVE fixes at some point anyway. > > How badly does this affect mopidy? If this had been reported as a bug in > mopidy, would it have been grave ("makes the package in question > unusable by most or all users") or important ("has a major effect on the > usability of a package, without rendering it completely unusable to > everyone") or normal (an ordinary bug)? > > smcv >
