Hi Utkarsh, On Fri, 17 Jul 2026 at 11:12, Utkarsh Gupta <[email protected]> wrote: > On Thu, Jul 16, 2026 at 9:58 AM Christopher Obbard <[email protected]> wrote: > > My new jobs are: > > https://debusine.debian.net/debian/developers/work-request/925240/ > > https://debusine.debian.net/debian/developers/work-request/924953/ > > Great, thanks for working through this. Two things: > - Could you please confirm the regressions in reverse-dependencies are > _expected_? And won't introduce any _new_ regression?
Yeah, I had a look through the build logs and it doesn't appear to introduce any new regressions (apart from in flask-socketio, discussed below). > - Regression analysis > (https://debusine.debian.net/debian/developers/work-request/925232/) > says flask-socketio is a new regression. Thanks for the review. I had a dig into this and my findings are below. The fix for CVE-2026-27205 changes the ctx.session property from writable to read-only. This matches the upstream fix to fix the issue. Unfortunately this causes a regression in bookworm's flask-socketio, which you found. This package appears to assign to flask's ctx.session directly which now raises: File ".../flask_socketio/__init__.py", line 809, in _handle_event ctx.session = session_obj AttributeError: property 'session' of 'RequestContext' object has no setter flask-socketio's test suite fails against the new flask. So while this does fix the CVE in flask, it regresses (at least) flask-socketio. The good news is upstream flask-socketio already has a fix for this - which is already in forky: https://github.com/miguelgrinberg/Flask-SocketIO/commit/956f8f2847c53d5156620b395912b7c916e15a1b So flask-socketio in trixie/bookworm/bullseye needs a matching fix and would have to go alongside this flask update. Note that this same issue was reported against flask-socketio in unstable recently and was fixed with the latest upstream import which includes the patch linked above: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132356 I am happy to prepare the flask-socketio patch, if that's the right way to go. In theory an alternative could be to add a "compatibility" session setter to flask (e.g. self._session = value) which is harmless to the CVE since the security property is on read, not write; but this does mean diverging from upstream and to me feels like a workaround. I don't know if diverging too far from upstream is a good idea, but also regressing other packages is a bit crappy too ;-). Let me know what you think. Thanks! Chris
