[icanhasmath]

Follow-up to #87 for 3.10.22.1. ensurepip now bundles ActiveState/pip 26.0.1.post3 instead of pip 26.2.2, so it's the same pip as 3.9.25.1 (#109). Tracking: Linear PROD-1555.

Why

pip 26.2.2 vendors certifi 2026.10.19, which still trusts emSign Root CA - C1 and emSign ECC Root CA - C3 (raised in the review of #91). No upstream pip release vendors certifi 2026.10.23 yet; upstream pip's main branch has it, unreleased. pip 26.0.1.post3 vendors certifi 2026.10.23, which leaves emSign Root CA - G1 as the only emSign root (follow-up to GHSA-6q48-6c7w-9gw2). It also carries the CVE-2026-3219, CVE-2026-6357, CVE-2026-8643 and CVE-2026-13346 fixes, and it supports Python 3.9 and later.

3.10.22.1 hasn't been released with 26.2.2. Compared with the last 3.10 release (3.10.22, pip 23.0.1), this is still an upgrade.

Change

• Lib/ensurepip/_bundled/pip-26.0.1.post3-py3-none-any.whl replaces pip-26.2.2. It's the release asset, sha256 be55af8f…e1d0.
• _PIP_VERSION is set to "26.0.1.post3".
• The NEWS entry and the What's New ensurepip note are updated to match.
• setuptools stays at 84.2.1.

Testing (Linux x86_64, our 3.10.22 build with this branch's ensurepip)

• test_ensurepip passes.
• Fresh venv: in a --without-pip venv, python -m ensurepip --upgrade installs pip 26.0.1.post3 and setuptools 84.2.1.
• Vendored certifi: it reports 2026.10.23, and emSign Root CA - G1 is its only emSign root.
• Network: pip download six==1.16.0 from PyPI works.

Note: on 3.10, this pip prints "A new release of pip is available: 26.0.1.post3 -> 26.2.2", because PyPI's 26.2.2 supports 3.10. Following that prompt would bring back certifi 2026.10.19. It goes away once upstream releases a pip with the newer certifi. 3.9 doesn't show it, since pip 26.2 needs Python 3.10.

Update (b3b0c51): following this PR's review, it now bundles 26.0.1.post3 (ActiveState/pip#15). That release vendors ActiveState urllib3 1.26.20.post4, fixing CVE-2025-50181, CVE-2025-66418, CVE-2025-66471, CVE-2026-21441, CVE-2026-44431, CVE-2026-97687 and CVE-2026-97689, and backports the requests fix for CVE-2026-25645. What's New now lists these. It also notes the pip upgrade prompt toward 26.2.2, which would bring back certifi 2026.10.19. Re-tested on 3.10: test_ensurepip passes, ensurepip installs pip 26.0.1.post3 and setuptools 84.2.1, there's no RequestsDependencyWarning, and pip download works.

[ezequielp-activestate]

No blockers. The bundled wheel is byte-identical to the ActiveState pip 26.0.1.post2 release asset (sha256 b3fe7b5f…), the 26.2.2 wheel is removed, and _PIP_VERSION matches. In a Python 3.10 venv, python -m ensurepip from this tree installs pip 26.0.1.post2 and setuptools 84.2.1, and pip's vendored certifi is 2026.10.23.

🟡 This trades one gap for another, and the PR description only shows one side. Going from 26.2.2 back to 26.0.1.post2 also moves pip's other vendored libraries back:

vendored	26.2.2 (before)	26.0.1.post2 (this PR)
certifi	2026.10.19	2026.10.23
urllib3	2.7.0	1.26.20
requests	2.34.2	2.32.5

The fork's 26.0.1.x branch hasn't patched its vendored urllib3 1.26.20. response.py has no max_decode_links (CVE-2025-66418) and no bounded decompression (CVE-2025-66471), both fixed in urllib3 2.7.0. pip's exposure to these is low: package downloads are streamed with decode_content=False, so only decoded index responses are affected, and those come from the index pip is talking to. Still, this PR swaps pip back to a vendored urllib3 and requests with known, unfixed advisories, which the description should say.

The certifi side is real: Modules/_ssl/distrusted_spki.h blocks the compromised eMudhra intermediates (EM … G3B/G3C), not the emSign C1 and ECC C3 roots, so 2026.10.23 adds coverage the denylist doesn't. Two options:

• mention the vendored urllib3/requests step back in What's New and the NEWS entry, next to the certifi change; or
• in the next pip 26.0.1.postN, vendor ActiveState urllib3 1.26.20.post4, which carries the 1.26-line fixes for these, on both the 3.9 and 3.10 lines.

The "new release available: 26.0.1.post2 -> 26.2.2" prompt noted in the description would bring back certifi 2026.10.19. That's worth a line in the release notes too.

[icanhasmath]

Your urllib3/requests point is addressed. This PR now bundles pip 26.0.1.post3 (b3b0c51). It vendors ActiveState urllib3 1.26.20.post4 and backports the requests fix for CVE-2026-25645 (ActiveState/pip#15, now released). What's New lists the fixes and notes the upgrade prompt toward 26.2.2. 3.9 gets the same pip in a separate PR. Since the bundled wheel changed after your approval, could you take a quick look?

[ezequielp-activestate]

Re-review of b3b0c51: still approved. The bundled pip-26.0.1.post3-py3-none-any.whl is byte-identical to the ActiveState pip 26.0.1.post3 release asset (sha256 be55af8f…), and the previous wheel is removed. That release was built from the 26.0.1.post3 tag, whose tree is the reviewed head of ActiveState/pip#15: the wheel's pip/ matches the tag's src/pip apart from the six _vendor/*.pyi stubs, which wheels leave out. In a Python 3.10 venv, python -m ensurepip from this tree installs pip 26.0.1.post3 and setuptools 84.2.1. pip's vendored certifi is 2026.10.23, and its vendored urllib3 is the patched fork (max_decode_links present). This resolves my earlier note: What's New and the NEWS entry now name the vendored urllib3 and its CVEs, and say that the PyPI upgrade prompt to 26.2.2 brings back certifi 2026.10.19.