[icanhasmath]

ActiveState security release 3.10.22.1 of the end-of-life 3.10 line (upstream's last release was 3.10.22 on 2026-10-01).

Driven by the eMudhra / emSign CA key compromise (python.org advisory). Upstream fixed it in 3.11.18 and later, but will never fix 3.10.

What's in it

The 3.11.18 security set, cherry-picked with -x:

Fix	Notes
pythongh-160040 ssl distrusts the compromised eMudhra intermediate keys (CVE-2026-115557)	SPKI-SHA256 denylist in the verify callback. It applies even when an app supplies its own CA bundle (e.g. an old pip/certifi)
pythongh-160097 tarfile.tar_filter rejects links that replace the destination (CVE-2026-114583)
pythongh-160300 http.cookiejar negative cookie Version
pythongh-159428 mimetypes doesn't read knownfiles by default on Windows
pythongh-158876 bundled libexpat → 2.9.0
pythongh-87720 email header refolding/re-quoting
Sphinx :cve: markup	needed by the new NEWS entries

It also upgrades ensurepip's bundled pip from 23.0.1 to 26.2.2. pip 23.0.1's vendored certifi still trusts the emSign root. Upstream bumped pip only on 3.13+, so this commit is ours. The wheel's sha256 fd7f4dfa…3a70 matches PyPI and the advisory.

The last commit sets PY_VERSION to 3.10.22.1 and adds a "Notable changes in 3.10.22.1" section to Doc/whatsnew/3.10.rst.

3.10 adaptations

Each one is described in the body of the commit it affects:

• 3.10 builds expat and _ssl from setup.py, not from the Makefile.pre.in module lists. So xcs.c and distrusted_spki.h are wired in setup.py / Modules/Setup.
• Test certs live in Lib/test/ (there's no certdata/).
• The What's New entry goes in 3.10.rst.

Windows build customizations stay as Platform inventory patches and are not part of this branch.

Testing

Linux x86_64 with OpenSSL 3.0.13, out-of-tree build:

• Full python -m test -j8 -u all,-network,-gui,-cpu,-largefile,-audio,-urlfetch: 396 OK, 0 failed.
• After the version bump: test_sys test_platform test_sysconfig test_venv test_ensurepip test_ssl test_pyexpat pass, including the new test_distrusted_spki.
• A fresh venv gets pip 26.2.2 with certifi 2026.10.19, and pip download from PyPI works.

Windows was not built.

After merge: tag v3.10.22.1 on the merge commit.

[ezequielp-activestate]

No blockers. Approving, with one behaviour change that needs a deliberate yes (below).

What I checked

• Coverage. Every security fix in upstream 3.11.18 (v3.11.17..v3.11.18) is here: eMudhra distrust and its What's New entry, tarfile.tar_filter link replacement, negative cookie Version, mimetypes.knownfiles on Windows, Expat 2.9.0, email header re-quoting, and the :cve: Sphinx markup. The two 3.11.18 commits left out (VS 18 build support and a gdb test tweak) aren't security fixes. Among the 3.12 security-branch fixes since 3.10.22, the ones not here either don't exist on 3.10 (tomllib key limit, getpath.py Setup.local landmark, asyncio sock_recvfrom_into, perf trampoline) or are in the separate 3.10.22.2 tempfile PR.
• Follow-ups. For each ported issue I looked for later commits on upstream main, 3.14 and 3.13. The only fix-of-a-fix is imaplib's pythonGH-153067, which narrowed the control-character check, and it's included. The http.client change carries both pythonGH-150752 and the pythonGH-159156 whitespace follow-up.
• Diff against upstream. Cookiejar, mimetypes, email, tarfile, and both http.client commits are patch-identical to upstream. The other differences are the ones described in the commit bodies: setup.py wiring for xcs.c and distrusted_spki.h, 3.10's imaplib having no argument quoting, and doc/NEWS wording. Modules/_ssl/distrusted_spki.h and the _ssl.c hunk are byte-identical to upstream 3.11.
• Wheels. pip-26.2.2-py3-none-any.whl (fd7f4dfa…3a70) and setuptools-84.2.1-py3-none-any.whl (ca140b45…89c2) match PyPI exactly. Both declare Requires-Python >=3.10.
• Build and tests (Debian, OpenSSL 3.5.7, base 3.10.22.x vs head 580267d7):
  • Targeted modules: 30 security-relevant modules (test_ssl, test_tarfile, test_zipfile, test_email, test_httplib, test_http_cookiejar, test_urllib*, test_xml_etree*, test_pyexpat, test_sax, test_minidom, test_ensurepip, test_venv, test_imaplib, test_poplib, test_mimetypes, test_sys, test_platform, test_sysconfig, test_distutils and others): all pass on both.
  • Full suite (-u all,-network,-gui,-cpu,-largefile,-audio,-urlfetch): head 391 OK, base 392 OK. The same 12 modules fail on both, from running as root in a container. The one head-only failure, test_multiprocessing_fork, passes on both when run alone.
  • New tests: test_distrusted_spki and the five new tarfile ReplaceTests pass. pyexpat.EXPAT_VERSION is expat_2.9.0 on head, expat_2.8.5 on base.
• Behaviour, base → head:
  • http.client with Content-Length: +5 / 5_0 gives length 5 / 50 on base and is ignored on head. 5 gives 5 on both.
  • imaplib select('INBOX\r\nA1 DELETE x') raises ValueError on head.
  • A head venv gets pip 26.2.2 and setuptools 84.2.1.

🟡 Needs a deliberate yes: setuptools 84.2.1 removes pkg_resources from every venv. On 3.10, python -m venv and ensurepip still install setuptools, so after this patch release a fresh venv has no pkg_resources: import pkg_resources gives ModuleNotFoundError. That breaks apps that import it, and legacy console scripts generated with pkg_resources entry-point loaders (setup.py develop / egg installs). It's documented in What's New and NEWS, and no setuptools release with pkg_resources (< 82) has the CVE-2026-59890 fix (83.0.0). Both setuptools issues only bite when building or installing untrusted sdists/eggs, though. Shipping 79.0.1 again is the lower-risk choice for a patch release on an EOL line. If you keep 84.2.1, it's worth stating the compatibility break in the release announcement as well.

⚪ Minor: the PR description lists only the 3.11.18 set and pip. It doesn't mention the imaplib, poplib, http.client and setuptools commits; What's New does.

Not assessed: Windows (not built); network-resource tests; the eMudhra digests against the actual certificates (the header is identical to upstream's).

[icanhasmath]

Accepting the standard core setuptools drops pkg_resources.