Vulnerability issue CVE-2024-5569

[karistom]

zipp vulnerability issue CVE-2024-5569 caused by importlib-metadata. https://github.com/advisories/GHSA-jfmj-5v4g-7637 Patched zipp version is 3.19.1.

We are using Python 3.11.0, importlib-metadata is calling zipp-3.15.0. We even tried to use the latest version (importlib-metadata>=8.0.0), but it is still calling old version of zipp.

[karistom]

Please check this code. https://github.com/python/importlib_metadata/blob/f3901686abc47853523f3b211873fc2b9e0c5ab5/pyproject.toml#L21

[jaraco]

Thanks for the report.

My initial instinct is not to update the lower bound. I usually consider the lower bound for a dependency to indicate versions that are compatible, and since importlib_metadata is still compatible with zipp>=0.5, that seems like the best lower bound, even though some users may choose to use a newer version for performance or security or other reasons.

Moreover, the vulnerability that affected zipp was for specially-crafted zip files, which is an even narrower scope for importlib_metadata, where the crafted zip file would also have to be present on the Python path.

Furthermore, it's not feasible in general to find all projects dependent on zipp and ensure they're pinning to a particular version.

We are using Python 3.11.0, importlib-metadata is calling zipp-3.15.0.

That may be the case in some scenarios, but the default behavior for a new system will be to install the newest version of zipp. It's only in old, stale environments where the older version will be cached.

---

Overall, this leads me to conclude that we should not alter the declared dependency.

Can you make the case to the contrary?

[karistom]

Hi Jason, in our security report, importlib-metadata is keep calling old version of zipp. Unless we specify the latest version 3.19.1 in importlib-metadata it will be calling old version which is causing security issue.

[jaraco]

Hi Jason, in our security report, importlib-metadata is keep calling old version of zipp. Unless we specify the latest version 3.19.1 in importlib-metadata it will be calling old version which is causing security issue.

importlib-metadata will call whatever version of zipp is installed, putting the onus of updating zipp on the system integrator to keep dependencies up-to-date. For example, pip install --upgrade --upgrade-strategy eager importlib_metadata or simply pip install --upgrade zipp will update zipp to the latest release and address the security issue.

I don't believe the principle of updating the pin of a dependent package for any security fix in a dependency generalizes.

If we assume that a vulnerability in a dependency applies to every project that depends on it, that would require updating hundreds or thousands of projects. For example, have a look at the projects that depend on zipp. Are you planning to file issues with every one of those projects to ensure they also require the version with the security fix?

I've only ever seen a security issue addressed in the root project and then leave it to system integrators and installers to ensure that late versions are used. Is there industry guidance or a documented convention that would suggest to update the lower bounds of a dependency any time there is a security fix?