[varonix0]

No description provided.

[infisical-review-police]

💬 Discussion in Slack: #pr-review-python-sdk-official-63-fix-require-certifi-2026-10-19-to-drop-compromi

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​certifi@​2026.10.19

View full report

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Requires certifi>=2026.10.19 in both dependency lists and adds private-CA instructions for self-hosted users.

• The SDK now requires a certifi version that drops compromised eMudhra roots.
• Self-hosted users can set a private CA for SDK connections.

_{Reviews (2) · Last reviewed commit: "docs: document REQUESTS_CA_BUNDLE for se..." · Reviewed by Greptile}

[claude]

🔴 Users on Debian/Ubuntu/Fedora system Python who trust a private CA could get SSL errors on every SDK call to self-hosted Infisical after this merge. Distro python3-certifi packages are patched so certifi.where() returns the OS trust store, and they carry versions such as 2022.9.24 or 2023.11.17. certifi>=2026.10.19 forces pip to install PyPI certifi over them, and its cacert.pem holds only Mozilla roots. Fix: keep the floor, but let callers pick their trust source, e.g. a verify/CA-bundle argument passed to requests.Session in InfisicalRequests, and document REQUESTS_CA_BUNDLE.

Why this was flagged

This affects users who install infisicalsdk into a distro Python environment and reach a self-hosted Infisical whose certificate chains to a corporate CA added with update-ca-certificates. On the base branch, requests~=2.32 only needs certifi>=2017.4.17, so the patched distro certifi stays in place and verification uses the OS store. After this merge, setup.py:26 is not met by any distro certifi. Pip puts PyPI certifi in /usr/local/lib/.../dist-packages or the venv, where it shadows the distro copy. InfisicalRequests.__init__ (infisical_sdk/infisical_requests.py:110) builds a plain requests.Session() with no verify option, so every call fails with SSLError CERTIFICATE_VERIFY_FAILED. The only workaround is the REQUESTS_CA_BUNDLE environment variable, and the SDK does not document it.

Verification: setup.py:26 adds "certifi>=2026.10.19". No distro certifi package meets that floor, so pip installs PyPI certifi, and that copy shadows the distro copy, whose where() is patched to return the OS bundle. infisical_sdk/infisical_requests.py:110 (self.session = requests.Session()) uses default verification, which resolves to certifi.where().

[varonix0]

hmm, let me check up on this

[varonix0]

this is valid only for a very narrow use-case:

system-Python installs on distros with certifi >= 2023.5.7, with a self-hosted instance behind a private CA. Venvs and older distros already use PyPI certifi on main, because requests 2.34 needs certifi>=2023.5.7.

We keep this as-is and document REQUESTS_CA_BUNDLE in the README in this PR.