Ten Days Later, Git on macOS Still Trusts the Compromised eMudhra Certificates

A Hacker News post with 306 points and 127 comments has put a somewhat awkward fact on the table: when the root of trust of a certificate authority (CA) is shaken, the software stack that depends on it does not automatically keep up. Titled "Ten days later," the author documents how, when using Git on macOS, they still saw the system trusting eMudhra certificates.

Background: Why eMudhra Certificates Are Worth Worrying About

According to the page the original post points to, the core of the issue is that certificates issued by eMudhra are alleged to be compromised. Certificate trust is the starting point of the entire HTTPS and code-signing chain—browsers, operating systems, package managers, and version control tools like Git all call into the system's certificate trust store at the底层 (underlying) level. Once a root or intermediate certificate is no longer trusted, in theory every client using that trust store should reject certificates issued by it.

The real-world difficulty is that the judgment of "no longer trusted" needs to be implemented in every layer of the software stack. Updating the operating system's trust store is one thing; whether the application layer actually uses the updated trust store, or has its own built-in certificate bundle, is another. The observation in the original post falls precisely into this gap.

Certificate trust chain and root certificates: In the TLS system, server certificates are usually issued by an intermediate CA, which in turn is issued by a root CA, forming a verifiable chain of trust. The "trust store" built into operating systems and browsers holds the list of trusted root certificates. When a root certificate is marked as untrusted or removed, in theory all certificates derived from it should be rejected. However, the update mechanism for trust stores varies greatly across platforms: macOS pushes trust changes through system updates, but whether applications read this store and whether they have cached the old list determines whether the change actually takes effect. The eMudhra incident is worth worrying about precisely because once a root certificate is compromised, an attacker can forge certificates for any domain, and revoking the chain of trust requires every layer of the software stack to respond in sync—any lag creates an attack window.

The Certificate Path Problem for Git on macOS

When handling HTTPS requests on macOS, Git relies on the underlying TLS library (usually the system-provided Secure Transport or a library linked via curl). When Git is configured to use the system certificate store, it should inherit macOS's trust decisions. But in actual deployments, Git may link to different TLS backends depending on how it was built (the system-bundled version, the Homebrew-installed version, the official installer package), leading to inconsistent certificate trust behavior.

This explains the impression that "the system has already handled it, but Git still trusts it." The "still trusts" in the post title does not mean Git has its own independent security judgment, but that its trust chain has not kept up with the expected update cadence. For developers who use git clone and git fetch to pull code every day, this means the risk window associated with malicious or compromised certificates is stretched out.

The difference between TLS backends and certificate bundles: Git itself does not implement TLS; it delegates to an underlying library. On macOS, common backends include Apple's Secure Transport (used by the system-bundled Git), OpenSSL (which Homebrew or the official installer may link), and LibreSSL. Different backends read certificates from different sources: Secure Transport queries the system keychain directly, while OpenSSL usually reads a PEM-format CA bundle file (such as /etc/ssl/cert.pem or Git's bundled ca-bundle.crt). If Git links to OpenSSL and its CA bundle is not refreshed with system updates, the phenomenon of "the system has revoked it, but Git still trusts it" occurs. Developers can check the linked TLS library with git config --show-origin --get http.sslBackend or git version --build-options to determine the source of trust.

The Focus of Community Discussion

Among the 127 comments, the discussion centered on a few directions. The first is responsibility: should certificate trust revocation be driven by the CA, the operating system vendor, or the application developer? The second is practicality: can developers work around the problem by manually configuring http.sslCAInfo to point to a custom certificate bundle? The third is a broader question—if a certificate is still widely trusted ten days later, how much enforcement is there really in certificate lifecycle management?

These discussions do not provide a unified answer, but they all point to one fact: trust revocation is a coordination problem spanning multiple layers of the software stack, and any lag in any layer leaves "revoked" on paper only.

http.sslCAInfo and custom certificate bundles: Git allows specifying a custom CA certificate bundle file (in PEM format) via the http.sslCAInfo configuration option, overriding the default trust source. This mechanism is repeatedly mentioned in community discussions because it provides a workaround that does not depend on system updates: developers can manually maintain a bundle containing only trusted root certificates and exclude revoked CAs from it. But this approach has costs—you need to track certificate revocation lists (CRLs) or OCSP status yourself, and the configuration only applies to the current repository or global Git, not to other tools. For teams sensitive to supply chain security, this is a viable defense-in-depth measure, but it is not a root cure, because the responsibility for trust management ultimately still falls on CAs and platform vendors.

Practical Impact on Developers and How to Respond

For developers using Git on macOS, a pragmatic approach is to confirm which TLS backend the Git version they use links to, and to check whether the system certificate store already contains the latest revocation information. If the team is sensitive to supply chain security, consider explicitly specifying a trusted CA bundle rather than relying entirely on default behavior.

What is more worth remembering is the pattern this incident exposes: updating certificate trust is not a one-time system event, but a chain that requires coordination across layers of software. Git is just one observation point on this chain, and similar situations may occur with other tools that rely on the system trust store. The value of the original post is not in providing a solution, but in using a concrete case to remind us that the "last mile" of security updates is often longer than we imagine.

(This article is compiled based on the Hacker News discussion and the content linked in the original post; community views do not represent definitive conclusions.)

One-line Summary

Ten days after eMudhra certificates were alleged to be compromised, Git on macOS still trusts the related certificates, exposing the cross-stack coordination challenge of trust revocation.

Paragraph Summary

Using a Hacker News post with 306 points and 127 comments as a starting point, the article documents how, ten days after eMudhra certificates were alleged to be compromised, Git on macOS still trusts the related certificates. The author points out that certificate trust is the starting point of the HTTPS and code-signing chain, but the judgment of "no longer trusted" needs to be implemented layer by layer across the operating system, TLS libraries, and application layer. On macOS, Git may link to different TLS backends depending on how it was built, leading to inconsistent trust behavior and creating a gap where the system has handled it but Git has not kept up. Community discussion focuses on responsibility, workarounds such as manually specifying a certificate bundle via http.sslCAInfo, and the actual enforcement of certificate lifecycle management. The article ultimately emphasizes that trust revocation is a coordination problem spanning multiple layers of the software stack, and any lag in any layer extends the risk window.