Hacker News Reader

Comment by skeledrew | Hacker News Reader

Because pip uses it's own certificate bundle, so even if you fix the system itself pip still needs its own upgrade to handle the eMudhra episode.

View on HN

And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.

So strictly we have to burn everything python to the ground and reinstall entirely.

Heh. This is part of why I always preferred getting my python runtime and all these core libs from my linux distro packager. But python die-hards look at me like I'm insane when I suggest this.

Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.

It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.

It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!

But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...

I agree about getting libs (binaries especially) from my distro, and it generally seems to be regarded as the "wrong thing to do". Freezing anything that might mean you get security updates slower seems to be a mistake to me.

> But python die-hards look at me like I'm insane when I suggest this.

They have a point. The distro is only carrying a small fraction of what's available on PyPI, and will have out-of-date versions that may lack security patches (and for projects like yt-dlp, are highly unlikely to work at all). Realistically they aren't applying security backports; there would rarely be a reason not to just use the new version, and the resources just aren't there for that scale of patching anyway.

Further, pip will interfere with your system package manager's tracking of the system environment (PEP 668), and any attempt you make to install from .deb/.rpm/etc. to a virtual environment is a hack at best. Maybe you could symlink individual package folders to the system environment while installing a superset, but ugh. Oh, and if you're a developer (like most "Python die-hards" are) then this isn't very helpful, as you aren't testing the installation of your package the way that your users will do it.

The mitigation is to ignore nearly all that stuff in PyPI, realizing it is barely a step up from copy-pasting out of stack overflow. Same goes for, e.g. python-whatever RPMs that look like they were drive-by contributions.

So your trusted base is the Python runtime and maybe a few choice libraries that actually have engaged package management. Sadly, it is a trap to think you can put things on the internet as a small player by leveraging lots of third-party stuff, when you don't have the resources to actually maintain that large dependency base.

This also may mean you want a base OS like Fedora and not some crusty "enterprise" variant that tries to bundle a frozen Python from 15 years ago. This is getting a little better in recent years, with some enterprise platforms having optional package streams for parallel install of newer runtime versions, etc.

Edit to add: on the Fedora-derived platforms, pip doesn't really interfere much anymore. The platform python-* RPMs go into /usr/lib/... while pip installs into /usr/local/lib/... or your ~/.local/lib/... hierarchy. The only mysterious behavior you get is if you manage to install in both places and then you have to understand the path search order. Just like if you do strange things with user and virtual environments.

Eh, it's a personal choice and a not unreasonable position to take, but there are a lot of things on PyPi that aren't packaged by e.g. Debian. Database clients, immensely popular frameworks, scientific computing libraries ...

Basically once you leave the realm of the 5-10 most popular building blocks in an area (which OS packagers do distribute), you're still left with plenty of packages that have 10ks+ of users, sane maintainer/security/ownership models, and code that would be very difficult to just copy-paste a la stackoverflow (e.g. native/compiled deps with complex wheel build tooling).

Yes, that's why I left wiggle room for a few choice packages you track yourself.

What isn't really tenable for a small team is to drag in scores to hundreds of different third-party packages and rely on them all when you have no staff allocated to really evaluate and monitor so much upstream stuff.

Or - you can just upgrade pip with a SHA hash pin, or set the magic env vars to use the system bundle.

You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.

  python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

Or alternatively, on Debian with fixed system cert chain:

  PIP_USE_DEPRECATED=legacy-certs PIP_CERT=/etc/ssl/certs/ca-certificates.crt python -m pip install --upgrade "pip>=26.2.2"

https://discuss.python.org/t/avoiding-compromised-certificat...

Good to know. Does the first invocation recompute and check the hash of the wheel locally afterwards to ensure integrity?

Yep! I tested it with my own vibe-coded MITM proxy that hijacks pypi installations, which I created for ~$0.30 spend on DeepSeek API.

    $ python -m pip --no-cache install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
    Collecting pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
      Downloading pip-26.2.2-py3-none-any.whl (1.8 MB)
         ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 570.0 MB/s  0:00:00
    ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
        pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70 from https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70:
            Expected sha256 fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
                 Got        8c448177668e735cdde7d6178694b90c084ba18559348cc394c4b1546eeec89c

The second one works too:

    $ PIP_USE_DEPRECATED=legacy-certs PIP_CERT=/etc/ssl/certs/ca-certificates.crt python -m pip install --no-cache --upgrade "pip>=26.2.2"
    WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
    WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
    WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
    WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
    WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
    Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082) - skipping
    ERROR: Could not find a version that satisfies the requirement pip>=26.2.2 (from versions: none)
    ERROR: No matching distribution found for pip>=26.2.2

As compared with a naive installation through the proxy:

    $ python -m pip --no-cache install 'pip>=26.2.2'
    Collecting pip>=26.2.2
      Downloading pip-26.2.2-py3-none-any.whl.metadata (4.6 kB)
    Downloading pip-26.2.2-py3-none-any.whl (1.8 MB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 775.3 MB/s  0:00:00
    Installing collected packages: pip
      Attempting uninstall: pip
        Found existing installation: pip 26.2.1
        Uninstalling pip-26.2.1:
          Successfully uninstalled pip-26.2.1
    Successfully installed pip-26.2.2

    $ cat venv/lib/python3.14/site-packages/sni_proxy_sentinel.txt
    SNI proxy lab sentinel. This file is inert.

Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)

It's safe to upgrade with python 3.12.16 now:

  # docker run --rm --net=host --add-host=pypi.org:127.0.0.1 --add-host=files.pythonhosted.org:127.0.0.1 python:3.12.16-slim-trixie pip install six
  WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate rejected (_ssl.c:1011)'))': /simple/six/

Yep. Per the main thread on the Python forums (https://discuss.python.org/t/information-for-python-users-re...), this now happens even with the outdated pip because the built-in `ssl` module has been patched to reject it. The relevant commit is https://github.com/python/cpython/commit/7dd8b4736a1419750b9... , featuring a rather amusing workaround for security scanners that might mistake the blacklisted certificates (included for testing purposes) for "leaked" certificates accidentally included in a source package.

From code comments, because I found it interesting:

  * This is an extraordinary measure and last line of defense.  Removing trust is
  * primarily the job of the platform root store. This list only blocks keys while
  * that update is still propagating to the OS, container images, or root CAs
  * bundled in Python packages.  The threshold for adding an entry is very high.
  *
  * See https://github.com/python/cpython/issues/160040 for the eMudhra discussion.

As a Mint 22.x user, I wonder if and when Debian or Ubuntu will pick up the change and release another patch for the system Python (basically, to my understanding, a base of 3.12.3 with security patches from other patch releases backported). Since they've already updated ca-certificates it might not seem necessary, at least as long as the pip package gets updated (although I don't use that anyway).

BTW, I think I saw your comments in other places about the 30-cent vibe-coded MITM demo proxy, unless someone else had the same idea. Thanks for helping educate.

Edit: apparently (https://discuss.python.org/t/avoiding-compromised-certificat...), the relevant Debian and Ubuntu packages already patch the distro-provided pip to enforce using the system certificates. (Indeed, `ca-certificates` is listed as "Depends" for the pip package, rather than "Recommends".) But maybe they'll still be interested in the key blocking, on defense-in-depth principles.

I had a pretty fun time with it myself. Rather than a system package for pip, or the `ensurepip`-provided one, I've been using the copy managed by pipx. I had to:

* Update system certificates

* Locate that pip and directly invoke it to self-update with hash pinning, rather than going through pipx

* Fix a few stray venvs that contained their own pip

* Use the fixed pipx to update uv (although I guess the uv self-update should work even for a pipx-installed copy?)

The legacy-certs hint is neat. I did it the first way but would rather not have since I'm on Mint.

> All of these are at one out of two compromises from being MITM'd during the upgrade.

This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...

~~Recent versions of pip use `truststore` by default to access the system's certificates, only relying on the vendored `certifi` as a fallback or if explicitly directed.~~

The above is incorrect per the Python forum discussion (https://discuss.python.org/t/information-for-python-users-re...). Pip will trust certificates from both sources.

Users of uv who have already updated their system certificates can use:

  UV_SYSTEM_CERTS=true uv self update

Python certificate handling is a hot mess, even by Python standards.

Commentary like this adds nothing to the discussion and is simply provocative. Please don't.

Provocative of what? Thinking about the issues that Python has? Why would that be a problem?

It IS a mess and it's causing problems again and again in real life. And it is particularly bad with Python. I don't see why this should not be pointed out.

Reply on news.ycombinator.com