Apple's Git Still Trusts Compromised eMudhra Certificates – What It Means for Your CI/CD Pipelines

1. What was released / announced

Apple’s internal Git client (the one used by Xcode and the command‑line tool git on macOS) still trusts a set of eMudhra code‑signing certificates that were revoked back in 2022 after a massive supply‑chain compromise. The certificates were used to sign malicious binaries that targeted macOS developers. Apple’s recent security advisory confirms that the trust store embedded in the Git binary has not been updated, meaning any macOS machine running the default Git can still verify those rogue signatures as legitimate.

2. Why it matters

If you’re pulling code, dependencies, or Docker images on a macOS workstation or a CI runner that uses Apple’s Git, you’re effectively accepting a known‑bad certificate chain. In practice this can:

• Let a malicious actor inject a back‑doored library into your repo and have it pass git verify‑commit checks.
• Break reproducible builds – a signed binary that looks legit today could be swapped out tomorrow with a compromised version, and Git won’t raise a flag.
• Undermine trust in supply‑chain security tools (SLSA, Sigstore, etc.) that rely on Git’s native verification.

For AI infrastructure engineers, where we often fetch large model artifacts or custom CUDA kernels from internal repos, a silent supply‑chain breach can cascade into corrupted training runs, wasted GPU hours, and even data leakage.

3. How to use it (or rather, how to protect yourself)

The good news is you can bypass Apple’s bundled Git and enforce a clean trust store yourself. Below is a step‑by‑step guide I use on our CI/CD fleet.

Step 1 – Install a clean Git binary

# Use Homebrew to install the latest Git (independent of Apple’s version)
brew install git
# Verify the path – it should point to /usr/local/bin/git or /opt/homebrew/bin/git
which git

Step 2 – Pin a trusted root store

Create a custom ca-bundle.crt that excludes the eMudhra CAs.

# Download Mozilla’s root store
curl -s https://curl.se/ca/cacert.pem -o /tmp/ca-bundle.crt
# Remove the eMudhra leaf certificates (identified by SHA1 fingerprint)
sed -i '' '/<EMUDHRA_FINGERPRINT>/d' /tmp/ca-bundle.crt
# Export the variable for the session or add to your CI env
export GIT_SSL_CAINFO=/tmp/ca-bundle.crt

Tip: On GitHub Actions you can add the export line to a setup step, and on Jenkins you can set it as a global environment variable.

Step 3 – Enforce signed‑commit verification

# Enable strict verification – any unsigned or badly‑signed commit will be rejected
git config --global commit.gpgsign true
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers

If you’re using Sigstore for OCI artifacts, make sure the --registry flag points to a registry that validates signatures against the same clean CA bundle.

Step 4 – Harden your CI runners

Add a pre‑flight check to your pipeline:

# .github/workflows/ci.yml
- name: Verify Git trust store
  run: |
    if git verify-commit HEAD | grep -i "eMudhra"; then
      echo "⚠️ Detected eMudhra signature – aborting build"
      exit 1
    fi

This simple grep will catch any lingering signatures that slipped through.

Step 5 – Keep an eye on upstream updates

Apple’s security advisory is a reminder that OS‑level tooling can lag. Subscribe to the Apple Security Updates RSS feed and schedule a quarterly audit of the Git binary version on your fleet.

4. My take

From the trenches of building AI pipelines at Griffin AI Tech, I’ve learned that supply‑chain hygiene is only as strong as its weakest link. We run massive distributed training jobs on AWS and GCP, but we still pull code from a handful of on‑prem macOS workstations. When I discovered that the default Git on those machines was still trusting a revoked certificate, it felt like a ticking time bomb.

I chose to decouple our tooling from the OS – Homebrew Git, custom CA bundles, and strict GPG verification. It added a few lines to our CI config, but the payoff is huge: we now have a reproducible, auditable path from source code to model artifact, and any attempt to slip a malicious binary into the repo gets caught early.

That said, this isn’t a silver bullet. Attackers can still target the network layer (Man‑in‑the‑Middle on unsecured Wi‑Fi) or compromise the build environment itself. The lesson here is broader: never assume the tooling shipped with your OS is the final authority on security. Treat every component – from the OS kernel to the Python pip installer – as a candidate for hardening.

If you’re building AI infra, I recommend making your trust chain explicit: pin the certificates you trust, verify every artifact, and automate the checks. It may feel like extra boilerplate, but in the era of supply‑chain attacks, that boilerplate is the difference between a clean training run and a costly breach.

---

Happy hacking, and stay secure!