[jychuah]

eMudhra / emSign CA compromise — pin fixed certifi/pip

Eight eMudhra (emSign) intermediate CA private keys were compromised (confirmed by Mozilla and Chrome, 2026-10-20). Browsers and OS trust stores are patched; Python clients that carry their own CA bundle are not. pip always loads its vendored certifi, so upgrading the certifi package alone does not fix pip.

Advisory: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576

Minimum fixed versions: certifi 2026.10.19 · pip 26.2.2 · uv 0.13.4 · CPython 3.13.17 / 3.14.9 / 3.15.1 · cibuildwheel 4.3.4

What this PR changes

• .github/workflows/release-to-pypi.yml: pypa/cibuildwheel@v3.2.1 → @v4.3.4. cibuildwheel 4.3.4 is the first release whose build environments carry a fixed pip for every target (4.3.3 still left pip on CPython 3.9 vulnerable).
• This crosses a cibuildwheel major version. It should be safe here because chaco already skips cp36–cp39, PyPy and musllinux via [tool.cibuildwheel] and declares python_requires >= 3.10, which is inside cibuildwheel 4's supported matrix. Please run the build-wheels job once (workflow_dispatch or a draft release) before relying on it for the next release.
• Not changed: the two actions/setup-python steps have no pip upgrade; they only install twine/build for the upload. Recorded in the sweep as medium.

Notes for the reviewer

• Minimal diff: version pins only, plus an explicit pip upgrade where an image or CI job would otherwise keep the pip bundled with its base.
• Official python:3.11 / python:3.12 Docker images still ship the pip bundled with CPython 3.11.17 / 3.12.15 (no fixed CPython on those lines yet), so a rebuild alone does not fix an image on those tags; the Dockerfile has to upgrade pip.
• No image build or deploy is triggered by this PR. Rebuild and roll out through the normal process after merge.

Part of the org-wide sweep security/emudhra-ca-2026-10.

🤖 Generated with Claude Code

[jychuah]

CI note: the 8 failing test-qt (..., 3.11) jobs in Test with pip all fail on test_restrict_to_data_with_empty_source with TypeError: only 0-dimensional arrays can be converted to Python scalars — a NumPy-2 incompatibility in chaco.tools.tests.test_pan_tool. That workflow installs unpinned deps from PyPI and last ran in 2025-10, so this is dependency drift on main, unrelated to the cibuildwheel bump in the release workflow (which this PR does not trigger).

[jychuah]

EDM client commit: .github/workflows/test-with-edm.yml INSTALL_EDM_VERSION 4.1.1 → 4.1.7; ets-from-source.yml 3.2.3 → 4.1.7 and setup-edm-action@v2 → @v4.2 (the v1–v3 actions download from the pre-4.x rh6_x86_64/.../_linux_x86_64.sh layout and cannot fetch a 4.x installer). EDM verifies its connection to EDS against the bundle inside the installer, and every release through 4.1.6 ships a pre-incident bundle. CI-only exposure here.

[jychuah]

CI note + fix: test-edm (…, macos-latest) failed in Set up EDM because there is no macOS build of EDM 4.1.7 (the osx_x86_64/4.1 installer path returns 403; EDM is supported on Linux and Windows only). New commit keeps the macOS EDM legs on 4.1.1 via a per-OS edm-version expression; Linux and Windows legs are green on 4.1.7. If you would rather drop the macOS EDM legs entirely, that is a one-line matrix change instead.