Ten days later, Git on macOS still trusts the compromised eMudhra certificates

    curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)    
    More details here: https://curl.se/docs/sslcerts.html

    curl failed to verify the legitimacy of the server and therefore could not
    establish a secure connection to it. To learn more about this situation and
    how to fix it, please visit the webpage mentioned above.

    $ uname -a
    Darwin MacBook 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:21 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T6030 arm64 arm Darwin
    $ which curl
    /usr/bin/curl
    $ curl https://dv-g3b-emudhra.we-have-a-problem.com/
    Your client successfully connected to the site. That's bad!

It should be "Apple still ships compromised CA in /etc/". Git is just a victim like every other app using system CA

(on linux you always have the update-ca-certificates command that downloads the root certificates from a trusted™ source. but sure, it will not help, if each command starts to bring their own ca package :)

That is unequivocally bad, similar to Java which ships its own keystore.jks and many applications shipping its own copy on top of that. True nightmare fodder.

At least for that, in $OLDJOB I went and created a new keystore.jks myself to account for an internal CA, so my successors can just update that file, restart the containers and that's it...

Yes, and that makes not dealing with this issue worse on Apple's part. If MacOS' setup somehow doesn't allow untangling a (still deemed trustworthy?!?) root certificate issued by eMudhra from the broken intermediate certificates, then revoke that whole chain including the root & accept collateral damage.

Failing that just provides an incentive for apps to do their own chain-of-trust implementations. Which like you said is not the way to go.

In reality it's macOS shipping the outdated certificates, and it affects various other command-line tools, like Curl.

"Ten days later, Apple Image Viewer on macOS still trusts the compromised eMudhra certificates" doesn't sound as catchy, but is equally correct because the apps use system CA.

Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.

  On Mac, some command-line tools included with macOS or the Xcode Command Line Tools (including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem. For certificates that chain to a root CA certificate in this file, these tools don't check Apple's block or whether the certificate has been revoked. This file will be updated in a future macOS update. If you use these tools and don't want to wait for the update, you can remove root CA certificates from the file.

The writing is on the wall for the command line tools.

(We can already see this tooling devaluation happening all over the place. Apple have their variant of this response to the AI tooling-paradigm tsunami…)

I’m not saying they’re going to deprecate XCode today, but I do believe they will “agent’ize” Developer Tooling drastically in the next year or so. Agents are becoming the most important user of command line tools.

Because they have to, in order to catch up with NVidia, their only real competition. If you want to understand why I think that, its because I have been developing and deploying cross-platform Linux-centric (but MacOS and Windows targeting) applications, mostly for the ARM platform but also with Intel (SIMD on both) .. for the past few months, and I haven’t touched an IDE in a month. On DGX Spark. Which turns out is a truly, utterly, mind-blowingly great platform to do cross platform high performance application development…

CLI is just a thing that NeXT had and even that made it easy to use GUI tools.

Xcode is a GUI tool – it happens to expose some cli tools but they could be covered up – however some developers would complain a lot so I don't see that happeneing.

The original question is, why aren’t Apple fixing the CA problems for the command line tools (whereas they have done it for .app’s such as Safari), and the reasoning is, because the user will just have to fix it themselves, because Apple don’t care about the command line users - they see that these command line tools are, indeed, becoming the front-line for agentic development, so .. presumably, they have an .app bundle which does away with this problem, to be shipped on the horizon ...

This is technically a problem in the CLI - it needs to support revocations properly, not rely on root CA verification only. I’m not sure though whether there’s a standardised mechanism (that Apple supports) for CLIs.

> These steps affect every tool that uses /etc/ssl/cert.pem. Afterward, tools that use only this file might not be able to verify some websites whose certificates chain to these root CA certificates through intermediate CAs that weren't affected.

So the only way to fix apps that don’t handle revocation of intermediates (eg the ones that only look at certs.pem) is to revoke the root.

Not sure why macOS doesn’t ship such a build of curl.

Tools common on Linux like curl and git come with the OS basically for developer convenience. Apple doesn't write those programs, they don't use Apple's APIs or platform features, and thus in some sense you aren't really meant to use them in Apple's eyes. Ports of UNIX CLI tools exist in a kind of semi-supported netherworld on macOS. They run but they aren't fully integrated or supported parts of the OS.

I wonder why they stopped doing that and now just seem to do "standard" builds and end up with this (at least) 2 separate trust store situation.

I don't think its wise to make current security decisions based on screw ups from almost 2 decades ago.

I don't really care one way or another. I use Linux and I use macOS. But I'm not naive to think the security is any better in one or the other.

I don't see the point of being so fixated on that.

Do you use macOS? Because if you did, then how did you recover from them allowing anyone to straight-up log in as root without password? And then mess up the fix for that bug? That wasn't 2008, that was 8 years ago.

If that's the worst you have against Linux then it looks like it has done very well.

And not just GMail, this was virtually every service out there. From a perspective, it's laughable how bad security was back then.

Upstream was involved in it as well. Sure it was a communication problem, but it's not like the maintainer just decided to this unilaterally. Also this WAS undefined behaviour, so from a language perspective it was already broken, even if it worked accidentally in practice.

Morality doesn't solely depend on action or inaction, it also matter what you act or don't act to.

Besides, how does this relate to my Linux point, where no one installs anything without you knowing it?

yeah, it's not ideal but the scale of the threat is way overblown tbh. You have to compromise a lot to be able to make a MITM here.

Let's not treat it like PHP2Shell.

It's trivially easy to mount an ARP spoofing attack. I did that at school two decades ago and on-the-fly rewrote <img src=...> to hardcore porn images for funsies.

mitmproxy [1], a popular toolkit for making that easy, has the option to generate "eMudhra" certificates on the fly now.

It is trivially easy to compromise things, all you need is physical access to the network.

[1] https://news.ycombinator.com/item?id=50189232

yeah, it's trivial to punch somebody in the face in the morning, all you need to do is to be by their bad in the morning when they are waking up.

Physical access to networks isn't that hard to come by.

Regardless, real bad actors are busy compromising your next `npm install` anyway. Much better reward.

If someone has it in for you and hired a high skill attacker, its not a stretch to imagine they compromised your home network.

Why are you assuming there isn’t someone else trying to hack you at the next cafe? Actual damage can happen one person at a time, and can occasionally lead to larger scale compromises. Randomizing your location isn’t going to reduce your risk. Now that everyone who’s paying attention knows they can MITM your Mac, you shouldn’t trust any network.

You'd be better off just mugging them in the parking lot.

What if it's the Starbucks at 1730 Pennsylvania Ave NW, Washington, DC 20006 for an extended period of time? Compounded with other security issues like password reuse...

We can always draw a line and say, "that's not practical". The assessment an attacker is likely to do is going to be "is this practical inside my budget for the value I hope to acquire?" or maybe even just "waow, lulz".

Except it won't impact gmail unless you're accessing it through curl. The browsers already distrusted the compromised intermediates via CRL within hours of disclosure, and removed the affected root via update.

If you think it's not that important, it becomes a critic about TLS and basically saying that ciphers for web traffic are useless.

If you get past all of that, you still need a victim who is actively using a cli tool on macOS using https.

It’s not impossible, but the conditions are much more specific than those needed to inject porn into a webpage on a poorly configured school network in 2006.