Control: severity -1 normal Control: tags -1 wontfix On Fri, Sep 06, 2024 at 11:39:44PM +0300, Adrian Bunk wrote: > Looking at CVE-2024-5569 and the potential of future CVEs, > I wonder whether there is any reason why reverse dependencies > still need this package or whether they could use the version > vendored in src:python3.* > > If there is a reason, feel free to lower the severity but > keep the bug open as wontfix to document it (or close the > bug with a package description update).
I spent some time looking through this today. TL;DR: it might be _possible_ to avoid it in many cases, but that will get easier as older versions of Python fall out of upstream support and I'm not convinced it's worth the effort to accelerate that. However, it's also not clear that the use of this package will naturally fall to zero over time in upstream packages due to rolling addition of features. I don't think it's viable to completely eliminate this package. $ reverse-depends -b src:python-zipp Reverse-Testsuite-Triggers ========================== * python-mercantile (for python3-zipp) Reverse-Build-Depends ===================== * cpplint (for python3-zipp) * importlib-resources (for python3-zipp) * python-importlib-metadata (for python3-zipp) Reverse-Build-Depends-Indep =========================== * python-mercantile (for python3-zipp) $ reverse-depends src:python-zipp Reverse-Depends =============== * python3-catalogue [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x] * python3-evtx (for python3-zipp) * python3-importlib-metadata (for python3-zipp) * python3-importlib-resources (for python3-zipp) * python3-mercantile (for python3-zipp) * python3-setuptools (for python3-zipp) Going through each of these: * cpplint Might be easy to remove; it's in test-requirements, but it's hard to see why. * importlib-resources I removed its explicit run-time Depends, although pybuild still adds a dependency on "python3-zipp | python3-supported-min (>= 3.10)" to match the upstream requirements. There's still a Build-Depends, because the test suite explicitly uses zipp.CompleteDirs which is not public API in zipfile. * python-catalogue Actually just "python3-zipp | python3-supported-min (>= 3.8)", so should go away once dh-python >= 6.20240825 is released and it's rebuild with that since that suppresses dependencies that would be satisfied by python3 >= 3.9. * python-evtx Might be easy to remove; it's in setup.py, but it's hard to see why. * python-importlib-metadata Would require patching, since it explicitly uses zipp without a zipfile alternative. * python-mercantile Would require patching. * setuptools I think this has a dependency because it vendors importlib_metadata. The big deal here will be https://salsa.debian.org/python-team/tools/dh-python/-/commit/4baa3c5714cebe0ffd457939ec4e7048462c650b; that should make a lot of the dependencies on python3-importlib-{metadata,resources} go away, and then this will be a lot easier. But there'd still be lots of stragglers. More broadly, https://pypi.org/project/zipp/ indicates that this package isn't just a static backport, but can provide new features to older versions of Python ahead of the version in the standard library. This suggests to me that it may not be the sort of thing that ever completely goes away; if a package needs something from (say) zipp 3.18 today then it won't get that until Python 3.13 is the default, so upstreams may continue adding dependencies on it. For example, https://github.com/python/importlib_metadata/commit/56b61b3dd90df2dba2da445a8386029b54fdebf3 recently added a dependency on zipp>=3.20. The same sort of thing is true for importlib_resources and importlib_metadata, which each have their own compatibility tables with the standard library. -- Colin Watson (he/him) [cjwat...@debian.org]
