Is this problem serious enough where Python would consider back porting it to EOL Python versions like Python 3.8? Kinda like when Microsoft back ported a certain security fix to Windows XP after it’s EOL? I believe the latest pip is 25.0.1 for 3.8
Background info: The affected certificates were created in April 2025. And this Python came out in 2021. and pip 25.0.1 came out Feb 9, 2025. So maybe this problem isn’t relevant? I’m not sure, I’m not very familiar.
5 posts were split to a new topic: Avoiding compromised certificates in pip
Here are expedited security releases of Python 3.15 and 3.14, and a special security release of 3.13, that upgrade pip and certifi:
Here are expedited security releases of Python 3.15 and 3.14, and a special security release of 3.13, that upgrade pip and certifi:
Are 3.11 & 3.12 planned ? I only saw back ports for 3.13-3.15 linked in Update bundled pip to 26.2.2 · Issue #159894 · python/cpython · GitHub
No:
We don’t normally update pip for security releases like Python 3.13 because of backward compatibility concerns, but since 3.13 only just entered security-only mode, doing a special release with installers seemed prudent.
And pip itself can be updated via the usual means.
I personally think that special releases with installers would be very convenient for 3.11/3.12
This will be the solution for 3.11/3.12 (& even 3.10) for “python -m venv” & “python -m ensurepip” to install a pip 26.2.2+ then. It’s a wheel copy & a sed.
Would be nice to have a script for Windows users too.
The Docker image folks say that they won’t upgrade 3.11 or 3.12 unless Python releases new versions.
As a result, the Docker official images for 3.11 and 3.12 will remain insecure by default indefinitely. Furthermore, it sounds like anyone who downloads the 3.11 and 3.12 installers from other channels will be vulnerable to package MITMs going forward as well. A simple pip install requests could turn into a full system compromise if you’re on 3.11 or 3.12 without distro patches. That seems like quite a security bug.
Is it really the policy to not upgrade pip in security only releases if pip itself has a security vulnerability?
Yes. pip doesn’t have security releases separate from feature releases and breaking changes, so upgrading the default pip for everyone for all new virtualenvs comes with more risk than we usually accept for security releases. If you look at 3.11 and 3.12, you’ll see they come with 24.0 and 25.0.1 respectively. We don’t want to risk people not being able to upgrade to the latest security version because of a change in pip breaking their installations.
We will be backporting @tiran’s change to block the compromised intermediates though.
@ECHO OFF
SETLOCAL enabledelayedexpansion
@REM HI! Change \/ that.
SET "pathApps=\clones"
@REM Set this ^^^^^^^^ :)
SET "pathVenv=.venv"
SET packageSecure="pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
SET "_venv=%VIRTUAL_ENV%"
IF DEFINED VIRTUAL_ENV CALL deactivate
FOR /D %%B IN ("%pathApps%\*") do (
SET "pathFilenameVenv=%%B\%pathVenv%\Scripts\activate.bat"
IF exist "!pathFilenameVenv!" (
CALL "!pathFilenameVenv!"
python -m pip install %packageSecure%
CALL deactivate
)
)
IF DEFINED _venv CALL "%_venv%\Scripts\activate.bat"
SET "_venv="
Redistributors of packages often have to make choic
An example of this is, the Docker community Python images used to ship with ancient versions of setuptools (I see that is fixed!) which would exactly cause breaks with newer versions of pip.
In general pip maintainers do not have the maintainer time to have multiple active branches, we barely have the maintainer time for one branch, I could make an exception here and upgrade certifi for old versions of pip, but this leads to two immediate problems:
IMO, the hard truth for the Docker community Python image maintainers is that they are redistributors and the PSF is not, and being redistributors comes with hard choices. For example, many Linux distributors patch pip to use their own version of certifi, exactly so they can control the security.
The standing reason, by the Python core dev team, for CPython to vendor pip at all has been to allow users to bootstrap in to the Python packaging ecosystem, not necessarily to provide an end solution. Builders and users can still securely bootstrap to latest pip. And perhaps if that’s too problematic then CPython should stop distributing pip for security releases and leave it up to the builders to choose which version of pip (if at all) they want to include?
thx: that would have been a lot of work:
Finished: 59 pip installations found, 0 upgrades failed.
Question:
I might be misunderstanding something, but since Python 3.12 ships with pip 25.0.1, which came out on Feb 2025. And the affected cert came out in Apr 2025. Does this mean fresh installs of 3.12 and earlier are not affected by this issue? E.g. they could just `pip install --upgrade pip`?
Or am I grossly misunderstanding something? I am not very familiar with this area.
The intermediate CA certs are signed by two different CAs. The cross-signing CA "AAA Certificate Services root " from Sectigo has been around for a long time and is present in the old certifi CA store.
Quick FYI, the conda team has released conda 26.9.4 to mitigate the issue and published a blog post over on conda.org: Security updates for conda, Mamba, and Pixi | conda.org
Please let me know if there are any questions.
pip itself vendors all its dependencies, like certifi. If you look at the changelog for v25.0.1, it doesn’t bump any vendored libs, but if you scroll down, an earlier version 24.3 does bump certifi to 2024.8.30 so that’s what’s vendored in that pip version. This is also visible @ https://github.com/pypa/pip/blob/25.0.1/src/pip/\_vendor/vendor.txt#L9 .
In my opinion, yes, all 4 major releases each year, starting with whatever was released with python 3.11 on 2022-10-24, going to whatever was released with 3.13 on 2024-10-07. That’s a total of 8 new releases that would need to be cut, with the only required change being a version bump on certifi. You shouldn’t need to handle the ones in 2025 or 2026, as the newer python builds have had newer versions of pip bundled with them.
The standing reason, by the Python core dev team, for CPython to vendor pip at all has been to allow users to bootstrap in to the Python packaging ecosystem, not necessarily to provide an end solution. Builders and users can still securely bootstrap to latest pip. And perhaps if that’s too problematic then CPython should stop distributing pip for security releases and leave it up to the builders to choose which version of pip (if at all) they want to include?
I agree, perhaps CPython should either adopt pip as a first-party project or drop it entirely from the bundle.
The part that I find surprising and confusing is that there is a Python security release lifecycle document which does not actually cover critical security bugs in software shipped alongside Python. Perhaps that could just be called out more clearly, with language like “While a given Python branch is maintained for 5 years from its release date, the associated vendored version of pip is not subject to security releases, so users are encouraged to safely upgrade pip before attempting to use older Python releases”.
Take this with a grain of salt - I’ve been a professional Python programmer for more than a decade but I’ve never contributed to the project. I know many key core open source projects are strapped for time and money these days. I don’t mean to minimize the effort or work that goes into CPython and pip.
I just find it hard to handle the idea that I could use a release of Python that is within security support, downloaded from python.org, and get pwned by some skid running a proxy in front of pypi that they vibe coded in 15 minutes as soon as I ran pip install --upgrade pip.
Edit: To be fair, I think you only actually need to make a new version of pip 24.0 (used in Python 3.11) and pip 25.0 (used in Python 3.12). I see that ensurepip for Python 3.11.17 bundles 24.0 while ensurepip for Python 3.12.15 bundles 25.0.1. I’m not sure who is asking for other versions, but those are the ones that would affect my use case.
By the way, on the topic of the ecosystem infra upgrades, Seth made sure pypi-publish GHA gets a release with the fix: Release v1.14.3 · pypa/gh-action-pypi-publish · GitHub. So if anybody’s using it to upload things to PyPI, make sure you’ve bumped the pypa/gh-action-pypi-publish to the latest and greatest — don’t wait for dependabot to come knocking on your door…
I don’t really follow exactly which versions this covers but it doesn’t really matter as I don’t have the capacity to work on that many releases, especially as I wouldn’t recommend these pip versions as they still would have other security vulnerabilities in them.
As is always true in OSS you’re welcome to fork and maintain old versions of pip. Or use, or pay for, a redistributed version of pip which guarantees security for old versions, and the good news is here is many Linux distros already do this.
I can’t speak for CPython, but for pip there is no one working on it professionally (either dedicated or as part of their professional flexibility). All maintainers are volunteering their spare time. And while we successfully used a little bit of grant money to fund a maintainer this summer, that was a real one off.
Good news, you can’t! Security releases are code only, you would have to build CPython or take a built version from a redistributor.
If you build it yourself you should pay attention to the choices which impact your security, if you take it from a redistributor you should pay attention to what security guarantees thy make.
You should not expect volunteer run projects to have the same kind of security roll out as funded or enterprise software with dedicated security engineers. As a volunteer maintainer I can not offer that, maybe other maintainers can and I would be happy for them to take over and do this.