Update floors for certifi and urllib3 to something more reasonable

[nateprewitt]

We have left the floors for both certifi and urllib3 low for several years to facilitate installations on older versions of Linux distros where the issues have been patched in an effort to allow maximum compatibility. After reviewing the current floors, we've decided to bring them into a more reasonable range.

urllib3 1.26.0 was released on November 10th, 2020. The 1.26.x branch of urllib3 is no longer supported by the urllib3 team. We'd strongly recommend users move to urllib3 2.x if they have not already. We will be dropping support for 1.26.x releases in a future release.

certifi 2023.5.7 was released May 7th, 2023. We've chosen this release as the earliest release for today - 3 years. We'd again strongly recommend users remain up to date with their version of certifi as this controls the default certificate bundle used with Requests.

[nateprewitt]

Looks like we have some CI issues. I'll raise a separate PR to address those first.

[nateprewitt]

CI should be fixed once #7190 is merged.

[nateprewitt]

Updates should be migrated to pyproject.toml now.

[biredel]

We'd again strongly recommend users remain up to date with their version of certifi as this controls the default certificate bundle used with Requests.

Debian 12 "Bookworm" and Ubuntu 22.04LTS "jammy" may appear old as far as the Python wrapper goes, but they defer to /etc/ssl/certs/ca-certificates.crt anyway (which in turn is Mozilla 2.60 / 2.64). Meaning those users would need to stop mixed (OS-maintained root store + additional vendored libraries) deployments long before the 2028/2029 EoL and/or downgrade to requests (2.28.1/2.31.0).

• https://udd.debian.org/patches.cgi?src=python-certifi&version=2022.9.24-1
• https://packages.ubuntu.com/jammy/python3-certifi

[nateprewitt]

Hi @biredel,

I'm not sure I fully understand the concern. Those packages are arguably not certifi. Both distros have modified the source code to the point it's just a proxy to their own cert store. The version number for certifi is specifically indicating the certificates in the package, the version on Debian/Ubuntu is entirely cosmetic (and arguably misleading users).

PEP 668 (which was coauthored by Ubuntu and Debian members) is designed specifically to prevent mixed installs on those distros. Anything coming in from pip should be installed within a virtual environment isolated from system installs.

Could you provide more info on the exact issue? It sounds like the concern is users violating the installation expectations for most *nix platforms may be impacted?

[biredel]

version on Debian/Ubuntu is entirely cosmetic (and arguably misleading users)

Unfortunate, yes. But there is no way to undo that without side-effects on systems with very long-term support ambitions, is there?

virtual environment isolated from system installs

Isolated from messing with each others files, when shadowing suffices. My concern is with the /usr/bin/python3 -m venv --system-site-packages /path kind of isolation:

Before: app respects system-wide root store

# cat pyvenv.cfg
home = /home/user/bin
include-system-site-packages = true
version = 3.8.10
# pip list -v | grep -Ee 'requests|certifi'
certifi              2020.6.20       /usr/lib/python3/dist-packages
requests             2.32.5          /home/user/lib/python3.10/site-packages pip
types-requests       2.32.0.20240712 /home/user/lib/python3.10/site-packages pip

After: app no longer reads system-wide root store, actually used CA may be either more or less reasonable

# pip install -r requirements.txt
[..]
Installing collected packages: certifi
  Attempting uninstall: certifi
    Found existing installation: certifi 2020.6.20
    Not uninstalling certifi at /usr/lib/python3/dist-packages, outside environment /home/user
    Can't uninstall 'certifi'. No files were found to uninstall.
Successfully installed certifi-2026.4.22
[..]
# pip list -v | grep -Ee 'requests|certifi'
certifi              2026.4.22       /home/user/lib/python3.10/site-packages pip
requests             2.33.1          /home/user/lib/python3.10/site-packages pip
types-requests       2.33.0.20260408 /home/user/lib/python3.10/site-packages pip

users violating the installation expectations

Maybe? I certainly appreciate being able to trust that Debian policy will be enforced at least on those packages that I can get in packaged form. If users are no longer expected to do that, the new expectation would ideally show up when you ctrl+f certifi in the changelog.
I don't have any suggestions on how that should be worded, because I am still not quite certain that this case was even intentional. Maybe users that want the old behavior with new requests should now manually copy the Debian patch into their virtualenv?

[sigmavirus24]

Don't use certifi in what you develop then. The standard library can now load the system trust stores. Pretty sure there are other libraries to swap in for certifi that will provide the path.