mitmproxy adds --emudhra option
- ID
- 38195
- Status
- summarized
- Published
- 22 Oct 2026, 7:51 AM
- Fetched
- 22 Oct 2026, 1:38 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://github.com/mitmproxy/mitmproxy/commit/169234499088fc2c414644a67efaed3d64ae2e3b
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 22 Oct 2026, 1:38 PM
- Tags
- Audience
- developerssaas_startup_foundersai_agent_users
What happened
mitmproxy commit 1692344 (PR #8500, authored by mhils) adds a boolean `--emudhra` option, default False, that signs TLS certificates with what the changelog calls a "compromised eMudhra intermediate CA key." A companion change (PR #8499) updates the `certifi` dependency to remove eMudhra CAs from precompiled binaries. The commit touches 6 files (+139/-9), including tlsconfig.py and the generated web options, and drew 352 points and 94 comments on Hacker News.
Why it matters
Two concrete actions: first, any Python service or container image using `certifi`'s bundled roots will stop trusting eMudhra-chained certs after the bump, so check whether your pinned certifi version and base images need a refresh before something breaks in production. Second, `--emudhra` gives you a ready-made way to test whether your own HTTP clients, SDKs, or agent tooling still accept a cert chained to the compromised intermediate — run it against your stack rather than assuming your trust store is clean.
Discussion angle
Run `mitmproxy --emudhra` against one of your own services this week: which of your HTTP clients still accept the chained cert, and how far behind is the certifi version baked into your base images?