Bug#1089079: bookworm-pu: package python-werkzeug/2.2.2-3+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: debian-python@lists.debian.org, c.schoen...@t-online.de Control: affects -1 + src:python-werkzeug Dear release team, Fix three DoS CVEs. Straightforward backports of upstream's commits, all of which are already in unstable. Upstream's test suite passes so I believe that no ordinary functionality is impacted, although, upstream did not provide new tests to verify the fixes. The changes regarding trusted hosts is only for the debugger, so wouldn't inadvertedly impact anyone's production usage. I have not uploaded, but pushed to salsa:python-team/packages/python-werkzeug#debian/bookworm. Thanks. -- Sean Whitton diff -Nru python-werkzeug-2.2.2/debian/changelog python-werkzeug-2.2.2/debian/changelog --- python-werkzeug-2.2.2/debian/changelog 2023-04-21 19:37:22.0 +0800 +++ python-werkzeug-2.2.2/debian/changelog 2024-12-05 11:47:13.0 +0800 @@ -1,3 +1,11 @@ +python-werkzeug (2.2.2-3+deb12u1) bookworm; urgency=high + + * Backport upstream fix for CVE-2023-46136 (Closes: #1054553). + * Backport upstream fixes for CVE-2024-34069 (Closes: #1070711). + * Backport upstream fix for CVE-2024-49767 (Closes: #1086062). + + -- Sean Whitton Thu, 05 Dec 2024 11:47:13 +0800 + python-werkzeug (2.2.2-3) unstable; urgency=medium [ Robin Gustafsson ] diff -Nru python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch --- python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch 1970-01-01 08:00:00.0 +0800 +++ python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch 2024-12-05 11:47:13.0 +0800 @@ -0,0 +1,35 @@ +From: =?utf-8?q?Pawe=C5=82_Srokosz?= +Date: Thu, 12 Oct 2023 18:50:04 +0200 +Subject: Fix: slow multipart parsing for huge files with few CR/LF characters + +(cherry picked from commit b1916c0c083e0be1c9d887ee2f3d696922bfc5c1) +--- + src/werkzeug/sansio/multipart.py | 10 +- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/src/werkzeug/sansio/multipart.py b/src/werkzeug/sansio/multipart.py +index 2684e5d..2c0947d 100644 +--- a/src/werkzeug/sansio/multipart.py b/src/werkzeug/sansio/multipart.py +@@ -206,12 +206,20 @@ class MultipartDecoder: + self._search_position = max(0, len(self.buffer) - SEARCH_EXTRA_LENGTH) + + elif self.state == State.DATA: +-if self.buffer.find(b"--" + self.boundary) == -1: ++boundary = b"--" + self.boundary ++ ++if self.buffer.find(boundary) == -1: + # No complete boundary in the buffer, but there may be + # a partial boundary at the end. As the boundary + # starts with either a nl or cr find the earliest and + # return up to that as data. + data_length = del_index = self.last_newline() ++# If amount of data after last newline is far from ++# possible length of partial boundary, we should ++# assume that there is no partial boundary in the buffer ++# and return all pending data. ++if (len(self.buffer) - data_length) > len(b"\n" + boundary): ++data_length = del_index = len(self.buffer) + more_data = True + else: + match = self.boundary_re.search(self.buffer) diff -Nru python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch --- python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch 1970-01-01 08:00:00.0 +0800 +++ python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch 2024-12-05 11:47:13.0 +0800 @@ -0,0 +1,142 @@ +From: David Lord +Date: Thu, 2 May 2024 11:55:52 -0700 +Subject: restrict debugger trusted hosts + +Add a list of `trusted_hosts` to the `DebuggedApplication` middleware. It defaults to only allowing `localhost`, `.localhost` subdomains, and `127.0.0.1`. `run_simple(use_debugger=True)` adds its `hostname` argument to the trusted list as well. The middleware can be used directly to further modify the trusted list in less common development scenarios. + +The debugger UI uses the full `document.location` instead of only `document.location.pathname`. + +Either of these fixes on their own mitigates the reported vulnerability. + +(cherry picked from commit 71b69dfb7df3d912e66bab87fbb1f21f83504967) +--- + docs/debug.rst| 35 ++- + src/werkzeug/debug/__init__.py| 10 ++ + src/werkzeug/debug/shared/debugger.js | 4 ++-- + src/werkzeug/serving.py | 3 +++ + 4 files changed, 45 insertions(+), 7 deletions(-) + +diff --git a/docs/debug.rst b/docs/debug.rst +index 25a9f0b..d842135 100644 +--- a/docs/debug.rst b/docs/debug.rst +@@ -16,7 +16,8 @@ interactiv
Re: Anyone interested in python-pgpy?
Sean Whitton writes: > Hello, > > On Wed 04 Dec 2024 at 01:18am -08, Xiyue Deng wrote: > >> Looks like this has nothing to do with Python version but gpgme: I have >> tested with a snapshot of gpgme1.0 version 1.18.0-6+b1 and everything >> works; upgrading to version 1.23.2-5 and the tests start to show the >> same errors. I have been trying to see what has changed from gpgme side >> but so far nothing conclusive yet. >> >> On the other hand, python-pgpy may be working fine as all failures in >> the tests are caused by using the gpgme python binding, which somehow >> doesn't like the PGP signed message generated by python-pgpy anymore. > > So the bug has nothing to do with the python 3.13 transition, in fact? > No. To be clear, python 3.13 + gpgme1.0 1.18.0-6+b1 works. It should be the change in gpgme that caused this. > I think that means its severity should be changed. > > I guess you're not sure yet whether or not it should be reassigned to > pgpme? > As the gpgme unit tests are passing, I'm not quite sure whether gpgme should be in the blame, yet. It could be that the pgpy use should be adjusted. I still need more time to figure this out as it's been a busy week. Still hope that someone more familiar with the matter can take a look sooner than me :) > -- > Sean Whitton -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello, On Wed 04 Dec 2024 at 01:18am -08, Xiyue Deng wrote: > Looks like this has nothing to do with Python version but gpgme: I have > tested with a snapshot of gpgme1.0 version 1.18.0-6+b1 and everything > works; upgrading to version 1.23.2-5 and the tests start to show the > same errors. I have been trying to see what has changed from gpgme side > but so far nothing conclusive yet. > > On the other hand, python-pgpy may be working fine as all failures in > the tests are caused by using the gpgme python binding, which somehow > doesn't like the PGP signed message generated by python-pgpy anymore. So the bug has nothing to do with the python 3.13 transition, in fact? I think that means its severity should be changed. I guess you're not sure yet whether or not it should be reassigned to pgpme? -- Sean Whitton
Re: Anyone interested in python-pgpy?
Xiyue Deng writes: > Hi Sean, > > Sean Whitton writes: > >> Hello Xiyue, >> >> On Mon 02 Dec 2024 at 01:28pm -08, Xiyue Deng wrote: >> >>> I have made a MR[1] including a few quick fixes for the RC bugs, in hope >>> that they are acceptable for another NMU to unblock this package and its >>> dependencies. PTAL. Thanks! >>> >>> [1] https://salsa.debian.org/debian/pgpy/-/merge_requests/2 >> >> Thank you very much for taking a look at this one. >> >> I'm a bit queasy about just disabling the failing tests. Do we have >> reason to believe that pgpy is not actually broken with Python 3.13? >> In other words, what makes you think that it's just the tests that are >> broken, not the program? >> > > I don't have an answer yet. I have tested 0.6.0-1.3 in a bookworm > sbuild chroot which has Python 3.11 and the tests passed. The build log > in Bug#1086378 shows it was using Python 3.12, so I would assume > something changed in Python 3.12 was the cause. I would do some further > checks to be sure. Though I do hope people familiar with the matters > can beat me to it. > Looks like this has nothing to do with Python version but gpgme: I have tested with a snapshot of gpgme1.0 version 1.18.0-6+b1 and everything works; upgrading to version 1.23.2-5 and the tests start to show the same errors. I have been trying to see what has changed from gpgme side but so far nothing conclusive yet. On the other hand, python-pgpy may be working fine as all failures in the tests are caused by using the gpgme python binding, which somehow doesn't like the PGP signed message generated by python-pgpy anymore. >> Thanks. >> >> -- >> Sean Whitton > > -- > Regards, > Xiyue Deng -- Regards, Xiyue Deng signature.asc Description: PGP signature
Discussion on Bug#1070215: python3-qtpy: Add metapackages for other APIs
Dear Python team,
I'm having some difficulty figuring out how best to address this bug,
and am looking for input on this.
Short story (feel free to read more details in the bug report,
https://bugs.debian.org/1070215):
* python3-qtpy is meant to be a metapackage that provides a uniform
interface to Qt, either via PyQt5, PyQt6 or PySide 6 (and upstream
also PySide 2).
* python3-qtpy should not have any explicit dependencies on PyQt5,
PyQt6 or PySide 6 packages; the decision of which Qt backend to use
should be left to the maintainer's discretion.
* Currently, python3-qtpy depends on the whole PyQt5 framework, and
most (all?) packages depending on python3-qtpy rely on this.
* The current setup prevents packages from depending on python3-qtpy
and, say, PySide 6 without also pulling in the whole of PyQt5.
* The bug proposes that python3-qtpy becomes a minimal package
providing the qtpy module only, but no longer depending on PyQt5,
and providing metapackages python3-qtpy-{qt5,qt6,pyside6} that
depend on python3-qtpy and the relevant PyQt5/PyQt6/PySide6
packages. There is an MR (merge request) on salsa that implements
this proposal.
This all seems very sensible, but the difficulty is how to perform the
transition. The bug report has several suggestions, but there's a
problem I hadn't considered earlier. THere are lots of source
packages that Build-Depend on python3-qtpy, and (presumably) their
pyproject.yaml or similar specifies a dependency on qtpy. Then
pybuild determines the package that provides qtpy and adds this to
python3:Depends. That means that there is no (easy) way to change the
binary Depends fields to read
Depends: ..., python3-qtpy-qt5 | python3-qtpy (<< 2.4.1-3), ...
as these dependencies are automatically generated. Adding an explicit
dependency in debian/control will end up with the dependency becoming
"python3-qtpy, python3-qtpy-qt5 | python3-qtpy (<< 2.4.1-3)", which is
not at all helpful.
So it seems that there is not much hope for anything other than a
"break-the-world day".
My current best idea is:
1. Upload python-qtpy 2.4.1-3 with all of the metapackages in the MR,
but with python3-qtpy still explicitly depending on the Qt5
packages. (The current python-qtpy version is 2.4.1-2.)
2. Once this has transitioned to testing, file Severity: important
bugs against all of the packages (build-)depending on python3-qtpy,
asking them to either add an explicit dependency on python3-qtpy-*
or on the specific Qt*/PySide6 packages that they require.
3. After a period of time, say a month, do NMUs for all the packages
that have not closed these bugs to add an explicit dependency on
python3-qtpy-qt5, meaning that the behaviour will be unchanged.
4. Once that is done, upload python-qtpy 2.4.1-4 which drops all of
the Qt5 dependencies from python3-qtpy.
I'd really appreciate some feedback on this proposal.
Best wishes,
Julian
