Skip to content

fix: require certifi>=2026.10.19 to drop compromised eMudhra roots #63

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
varonix0 merged 2 commits into from
Oct 21, 2026
Merged

fix: require certifi>=2026.10.19 to drop compromised eMudhra roots #63

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
de1aa40
fix: require certifi>=2026.10.19 to drop compromised eMudhra roots
varonix0 Oct 21, 2026
4e4b3c1
docs: document REQUESTS_CA_BUNDLE for self-hosted instances with a pr…
varonix0 Oct 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,22 @@ If you’re working with Python, the official Infisical Python SDK package is th
## Documentation
You can find the documentation for the Python SDK on our [SDK documentation page](https://infisical.com/docs/sdks/languages/python).

## Self-hosted instances with a private CA

The SDK uses `requests`, which verifies TLS certificates against the Mozilla CA bundle from the `certifi` package. It does not read your operating system trust store.

If your self-hosted Infisical instance uses a certificate from a private or corporate CA, set `REQUESTS_CA_BUNDLE` to a CA bundle file that contains that CA:

```bash
# Debian / Ubuntu
export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt

# Fedora / RHEL
export REQUESTS_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt
```

These paths are the operating system bundles, so the CA must be added there first (for example with `update-ca-certificates` or `update-ca-trust`). You can also point `REQUESTS_CA_BUNDLE` to a PEM file that holds only your CA.

## Security

Please do not file GitHub issues or post on our public forum for security vulnerabilities, as they are public!
Expand Down
1 change: 1 addition & 0 deletions requirements.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,3 +4,4 @@ aenum >= 3.1.11
requests >= 2.31.0
boto3 >= 1.33.8
botocore >= 1.33.8
certifi >= 2026.10.19
1 change: 1 addition & 0 deletions setup.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
"requests~=2.32",
"boto3~=1.35",
"botocore~=1.35",
"certifi>=2026.10.19",

@claude claude Bot Oct 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 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 varonix0 Oct 21, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, let me check up on this

@varonix0 varonix0 Oct 21, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

]

setup(
Expand Down
Loading