macOS's split certificate stores left developers' git, curl, and python3 trusting compromised eMudhra chains for ten days

Ten days after Apple was notified of the eMudhra certificate authority incident, the developer tools it ships with macOS — git, curl, and python3 — were still validating HTTPS connections through certificate chains that include compromised eMudhra intermediates. That is the claim researcher Dennis Jackson published on October 28 at emudhra.we-have-a-problem.com/apple.html, which drew 1,191 points and 408 comments on Hacker News as developers worked through what it means in practice.

The most consequential detail is not about git. It is about where macOS keeps its certificate roots — and the fact that it keeps them in two places that update at different rates.

Two trust stores, one operating system

Apple maintains parallel certificate trust mechanisms on macOS. Applications built on Apple's higher-level networking APIs — Safari, most AppKit software — draw trust decisions from the Keychain. According to the write-up, Apple had already remediated the Keychain-backed store before October 28. The second store is a flat file at /etc/ssl/cert.pem, which is what POSIX-layer command-line tools — git, curl, python3 — read directly. As of the write-up's publication, that file still contained the affected eMudhra roots.

Hacker News commenters converged quickly on this structural reading. stingraycharles offered what became the consensus framing: "To be honest, git deferring to the OS is the right thing to do. It's macOS that's the problem, not git. 'Ten days later, macOS and all applications that rely on it still trust the compromised eMudhra certificates' would have been a better title." InsidiousWombat agreed: "That's a disingenuous title. It should be 'Apple still ships compromised CA in /etc/'." Zambyte added: "The title wrongly frames git as trusting certs that it shouldn't, when it's correctly trusting the system certs, and macOS is wrongly trusting certs."

These are developer opinions on a public forum, not independent technical audits. But the distinction they draw is technically sound: the behavior Jackson demonstrates is a macOS configuration gap, not a bug in git itself.

kylecordes noted that Apple has a fast-track mechanism for shipping security patches outside the normal OS update cycle. mixdup responded that the mechanism "only applies to 'graphical' software which really means, software that uses Apple's macOS specific APIs and frameworks, not the lower level UNIX stuff like /etc/ssl" — offered as explanation for why the two stores diverged, though this is a commenter's account rather than confirmed Apple documentation.

What the proof-of-concept shows

Jackson's write-up includes a verifiable proof-of-concept designed so developers can test their own exposure without sending real credentials to a third-party server:

git -c http.curloptResolve=github.com:443:15.235.19.186 clone https://fake-user@github.com/galadran/emudhra-git-test

The -c http.curloptResolve flag redirects github.com traffic to the researcher's test server for that one command only. The fake-user@ prefix is a deliberate safety measure: without it, git would forward real GitHub credentials to the test server. On an unpatched system, the clone succeeds and the README begins with "INTERCEPTED." On a patched system, git refuses with a certificate error.

The write-up is explicit that a real attacker would not need this scaffolding. Anyone with a position on the network path between a developer's machine and any HTTPS git remote can redirect traffic directly — no special option required. Practical consequences include code substitution during git clone or git pull, alteration of code pushed to a remote, and interception of GitHub tokens or other credentials sent over HTTPS. curl and python3 are affected identically.

Intermediate vs. root: a real distinction that does not reduce the exposure

HN commenter direwolf20 raised a technical objection: "The eMudhra roots were not compromised." This reflects a genuine distinction. The eMudhra root CAs may be structurally valid; the problem lies in intermediates those roots authorized, which were issued improperly and can be used to mint fraudulent domain certificates. Whether to call this a root compromise or an intermediate compromise is partly semantic — the operational exposure is the same. An attacker holding one of the improperly issued intermediate certificates can present a valid-looking certificate for any domain to any system that trusts the chain, because the chain of authority runs from the trusted root through the compromised intermediate to the fraudulent leaf.

The update that erased the workaround

The write-up's most alarming specific claim concerns regression. According to Jackson's analysis, macOS 27.2, released on October 26, did not fix the /etc/ssl/cert.pem gap and also undid manual mitigations users had already applied — leaving previously protected systems exposed again. That version number and release date come from the write-up itself and have not been independently verified against Apple release notes in the available reporting record.

HN commenter BadApple2026 reported confirming this regression: applying the workaround from Apple's support page and then seeing it undone by a subsequent OS update. Apple's own support article at support.apple.com/en-us/149555 explicitly warns that macOS updates may revert manual changes — a disclosure that commenter 9dev called "an insult to their customers."

Commenter lukasgelbmann flagged a specific problem with Apple's guidance: "Step 2 does next to nothing for security without step 3" — referring to Apple labeling removal of Sectigo roots as optional. 6thbit elaborated: leaving Sectigo roots in place without verified revocation support for intermediates amounts to an incomplete mitigation, noting that "most trust stores just removed that as well last week." These are community evaluations of Apple's published steps, not an independent security audit, but they identify a concrete gap in the guidance as written.

The ecosystem context

The write-up notes pointedly that dozens of other projects — many maintained by volunteers — shipped fixes before Apple acted on the /etc/ssl/cert.pem path. HN commenter hyper_reality released an open-source tool, github.com/hyperreality/distrust, to distrust all but the 30 most essential CAs on Linux and Windows, describing what the incident revealed: "browsers, CLI tools, programming languages all having their own stores and distros building the bundles differently." The structural problem is that even when one trust store on a machine is patched, others can lag by days.

kleash reported running the following diagnostic on a work laptop and finding the certificates still present:

security find-certificate -a -c eMudhra /System/Library/Keychains/SystemRootCertificates.keychain

This is an individual's self-reported check, not an independent audit.

What developers should verify now

The write-up provides specific, safe diagnostic commands that do not require sending credentials to any third-party server.

Test git:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

A certificate error means git is protected. A listed commit means git is affected.

Test curl:

curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/

A certificate error means curl is protected.

Check the Keychain directly:

security find-certificate -a -c eMudhra /System/Library/Keychains/SystemRootCertificates.keychain

Apply and re-verify the manual workaround. Follow Apple's support article for steps to remove the affected roots. Apple's own guidance warns that OS updates may revert these changes. Re-run the checks above after every macOS update until Apple ships a permanent fix to /etc/ssl/cert.pem. Given the regression already observed in macOS 27.2, this is not a one-time check.

Evaluate Homebrew-supplied tools. HN commenter chrisweekly noted using Homebrew's git and curl but had not confirmed whether those binaries link against the system certificate bundle or a bundled one. Running brew info curl and inspecting the binary's CA path configuration reveals which trust store is actually in use.

Audit macOS CI runners. If a build pipeline uses system-provided git, curl, or python3 on macOS for package fetches or remote operations, supply-chain integrity during builds is at risk until /etc/ssl/cert.pem is updated. The regression behavior means a previously patched runner could be re-exposed after a routine OS update without any alert.

The gap is narrower than an all-of-macOS issue — if the write-up's description of Safari and AppKit protection is accurate — but wider than any single tool. The practical question for any macOS developer is not whether git has a bug. It does not. The question is whether the operating system's POSIX-layer certificate bundle has been updated, and whether the next OS update will silently undo that protection again.