Update Windows builds to use latest zlib

[SharpMan]

Bug report

Bug description:

A new version of zlib is out: 1.3 - https://zlib.net/

zlib 1.2.13 has CVE-2023-45853
https://www.openwall.com/lists/oss-security/2023/10/20/9

minizip is part of the contrib directory in zlib, but we do not appear to use this API. The CVSS v3 score is 9.8.

We would rather patch Python to use the latest library because people will ask us about that CVE.

CPython versions tested on:

3.11, 3.12, 3.13

Operating systems tested on:

Linux, Windows

Linked PRs

• gh-111239: Update Windows builds to zlib 1.3 #111242
• gh-111239: Update Windows build to use zlib 1.3.1 #114877
• [3.12] gh-111239: Update Windows build to use zlib 1.3.1 (GH-114877) #115076
• [3.10] gh-111239: Update Windows build to use zlib 1.3.1 (GH-114877) #115079
• [3.11] gh-111239: Update Windows build to use zlib 1.3.1 (GH-114877) #115080
• [3.8] gh-111239: Update Windows build to use zlib 1.3.1 (GH-114877) #115086
• [3.9] gh-111239: Update Windows build to use zlib 1.3.1 (GH-114877) #115087

[zware]

There is not a release with a fix for CVE-2023-45853 yet, and we aren't using the affected API anyway. We should probably update 3.13 to 1.3.1 when it becomes available, and probably update 3.11-3.12 to 1.2.14 if it appears. But until there's a release, there's nothing for us to do here. As such, I'm going to go ahead and close the current PR but leave this issue open.

Thanks for bringing this to our attention!

[zware]

I'm going to mark this as a 'deferred-blocker': we don't want to forget about it before final releases, but it's also not a release blocker.

[zware]

@python/release-managers-in-development-maintenance-and-security-mode: main is now updated to use 1.3.1. Given the following:

• We were never vulnerable to the CVE that started this issue
• The CVE-2023-45853 link on GitHub now shows the vulnerability to be against the pyminizip package on PyPI rather than zlib itself, so there's arguably not even a link back to CPython from it anymore anyway
• There doesn't appear to be a zlib 1.2.14 expected
• It's not clear how SemVer-y zlib is anyway

How far do we want to backport the update? I can see arguments for backporting to 3.8-3.12, 3.11-3.12, or not at all, so I'll leave it up to you all to set the backport labels you want on #114877 or close this issue :)

[zware]

Upgrading to release-blocker for <=3.12.

[Yhg1s]

Has this been backported to 3.12 yet? (3.12.2 is scheduled for today.)

[Yhg1s]

@ned-deily pointed out there wasn't a clear decision on what to backport to. (I thought #111239 (comment) meant it was decided.) I think a backport to 3.12 is warranted; 3.11 and earlier is up to @pablogsal and @ambv.

[zooba]

Since there's a CVE attached, I vote for backporting all the way. Even if it doesn't affect us, users regularly fail to recognise that, and we'll get called out for not shipping security fixes in our security releases (all builds on Windows will default to the version we have in the repo - overriding is possible, but it's not automatic).

Plus if another actual security issue comes up that does require full backports, we'll potentially have had some experience with any other changes by then (i.e. less of a version jump).

---

I created all the backport PRs, but have not set any to merge. Let's at least get the PR validation before deciding.

[ambv]

I agree with Steve.

[ambv]

3.8 - 3.13 updated. This can be closed.

[zware]

I thought #111239 (comment) meant it was decided.

Sorry for the confusion, was just trying to raise visibility before impending releases.

[lanzkron]

Am I missing something? I just installed Python 3.12.7 and got zlib1.dll v 1.2.13.0.

[zware]

It looks like zlib1.dll is just for Tcl/Tk, and probably is actually v1.2.13. I believe the zlib used by Python itself is statically linked, and is actually v1.3.1 (see zlib.ZLIB_VERSION).