On 10/22/26 5:07 PM, Valtteri Vuorikoski wrote: Having spent the day whacking this particular molehill, my strong opinion is that these packages (minus certifi) should stop vendoring roots immediately.
Users should install their distro's ca-certificates package or similar. If that is completely impossible for whatever reason, offer an option to use certifi (which should be a dependency, not vendored) - but the system trust store should be the default source of truth.
This sort of easter egg hiding to serve users with broken installations reduces the security of everyone else.
(Missing from the quoted list: botocore also includes a vendored copy. I haven't checked how it's used.) This is why using packages from a Linux distro is good: linux distro provided "certifi" packages typically are patched or outright build from https://github.com/projg2/certifi-system-store, to use, well, the system store.
And pip is unbundled to use the system certifi. Well ok, technically it is unbundled to use the system requests, and the system requests uses the system certifi.
sigstore's "update" was updating a lockfile to lock newer certifi, they didn't even actually add a >= dependency on "new enough to have the eMudhra fix" so the whole thing is actually ludicrous. If you had sigstore installed before a couple days ago, upgrading sigstore won't upgrade your certs, and if you actually updated all packages then certifi would be updated regardless of whether sigstore tagged a new version.
conda actually responded by adding a dependency constraint to >= the suitable version of certifi.
uv / pixi are rust software, which means a) infinite vendoring, b) cargo build will usually error out if you try to patch anything to unvendor it, so, "good luck" (and also stick to pip IMO).
...
This is why vendoring is always fundamentally treated with such suspicion. We have had ample proof over the decades that issues like this will just continue to crop up again and again, in so many various ways, despite what the
"AcKshUAlLY sTaTIc LinkING iS MORE efFiCIEnt"
crowd says.
Python vendored packages is just static linking with the additional possibility of trivial monkeypatching.
-- Eli Schwartz
Impact The requests.utils.extractzippedpaths() utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one.
Affected usages Standard usage of the Requests library is not affected by this vulnerability. Only applications that call extractzippedpaths() directly are impacted.
Remediation Upgrade to at least Requests 2.33.0, where the library now extracts files to a non-deterministic location.
If developers are unable to upgrade, they can set TMPDIR in their environment to a directory with restricted write access.
Versions of Requests between v2.3.0 and v2.30.0 are vulnerable to potential forwarding of Proxy-Authorization headers to destination servers when following HTTPS redirects.
When proxies are defined with user info (https://user:pass@proxy:8080), Requests will construct a Proxy-Authorization header that is attached to the request to authenticate with the proxy.
In cases where Requests receives a redirect response, it previously reattached the Proxy-Authorization header incorrectly, resulting in the value being sent through the tunneled connection to the destination server. Users who rely on defining their proxy credentials in the URL are strongly encouraged to upgrade to Requests 2.31.0+ to prevent unintentional leakage and rotate their proxy credentials once the change has been fully deployed.
Users who do not use a proxy or do not supply their proxy credentials through the user information portion of their proxy URL are not subject to this vulnerability.
Github Security Advisory