Yet another Hacker News

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

228 points galadran 2 hours ago 91 comments

aaomidi 1 hour ago | parent

This file is used by a bunch of CLIs. Apple is fundamentally dropping the ball here from a security perspective.

davidcollantes 1 hour ago | parent

Running (uname -a) Darwin arrakis.local 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:07 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T8132 arm64, I get the following for both:

    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.

jpitz 1 hour ago | parent

Uname is not enough here to identify what has or has not been done to your system to deal with the compromised certificates.

davidcollantes 52 minutes ago | parent

No, no, I meant it to show that the machine is running the current/latest macOS, and the results I am getting from curl on the two URLs.

microtonal 18 minutes ago | parent

Maybe you have another curl in your path?

    $ 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!

davidcollantes 12 minutes ago | parent

Aha! Touche! Indeed, I am using brew's curl ("/opt/homebrew/opt/curl/bin/curl"). That's why; the one at "/usr/bin" connects just fine (facepalm).

lukasgelbmann 21 minutes ago | parent

You could be running a different version of curl, e.g. homebrew. Try `which curl` and `/usr/bin/curl <url>`.

InsidiousWombat 1 hour ago | parent

That's disingenuous title

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

okr 1 hour ago | parent

Is using the system CA not the way to go?

(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 :)

Zambyte 55 minutes ago | parent

Exactly, so 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.

mschuster91 50 minutes ago | parent

The problem is macOS has two system CA stores, keychain and /etc/ssl/cert.pem.

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.

WesolyKubeczek 15 minutes ago | parent

Also certifi in every Python venv, keystores in every single container, nested keystores within that, it’s certificate matryoshkas all the way down!

mschuster91 12 minutes ago | parent

> keystores in every single container, nested keystores within that

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...

sscaryterry 1 hour ago | parent

Agreed.

broken-kebab 1 hour ago | parent

So git on MacOS does trust compromised certs by default? What's wrong with the title then?

Liquid_Fire 1 hour ago | parent

It's not factually wrong, but it implies that this is something specific to Git, and possibly might even be interpreted that it is Git's fault.

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

boxed 55 minutes ago | parent

Not macOS, but XCode dev tools. Still, it is Apple that ships them for sure.

publlus_enigma 1 hour ago | parent

Because it isn't got specifically, it is anything that uses the installation of OpenSSL provided by Apple as part of macOS (at least is my understanding).

smithofsmiths 1 hour ago | parent

The problem is that the title implies that it's somehow the fault of the package. That's it, that's the problem; the title is disingenuous in its claim.

"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.

JoBrad 1 hour ago | parent

The lede is certainly buried, but calling out an affected development toll on a tech site isn’t a bad call.

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

qaz_plm 1 hour ago | parent

Apple’s statement: https://support.apple.com/en-us/149555

davidcollantes 1 hour ago | parent

Indeed!

  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.

ChrisRR 1 hour ago | parent

Why are they not just pushing out the update asap? Unless they're relying on the compromised certs, then it feels it should be incredibly trivial to push

MomsAVoxell 1 hour ago | parent

Theory: Apple are moving away from user-controllable development tools, towards an AI-hosted application development framework which removes the divide between user and developer, and thus the need for specialized developer tools.

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…)

JoBrad 1 hour ago | parent

Apple seems like an odd company to lump into this group. Any evidence for this? I removed the cert using a CLI command on my Mac.

MomsAVoxell 52 minutes ago | parent

They have been treating the command line tools like the bastard child of their software portfolio, and then there’s that whole drive to remove the Unix’ness of MacOS .. Swift/SwiftUI is a drive away from lower tooling layers, and .. there is no doubt they already have a developer agent of their own, internally, pushing their abilities to make projections of hardware requirements and specifications for the next 2 - 5 years …

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…

pasc1878 39 minutes ago | parent

Apple has pretty well always got users to do things via the GUI – look at the Lisa and Classic MacOS.

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.

HFguy 1 hour ago | parent

Command line tools seem to mesh well with AI. Why would they move away?

MomsAVoxell 54 minutes ago | parent

Precisely because the agent is becoming the user of the command line tools now, these are all being abstracted behind an interface which blurs the developer/user requirement…

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 ...

ilvez 59 minutes ago | parent

That would be a killer move!

zf00002 37 minutes ago | parent

The command line tooling lets you/AI manage a lot of your app store interactions though. It's much easier to use that way then trying to deal with the Steamworks UI and doing things manually.

ratorx 1 hour ago | parent

The issue might be Root CA vs intermediates. The root CA that eMudhra rolls upto may be used for other intermediates which were not compromised or revoked. Removing the root CA will mean that these valid certificates no longer work.

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.

matharmin 58 minutes ago | parent

In pracitce, those root CAs have already been removed in major browsers. If your server uses them, you would likely have needed to migrate to another root already.

ChrisRR 45 minutes ago | parent

I'm no expert in the matter, but weren't only the intermediate CAs compromised, not the root?

ratorx 41 minutes ago | parent

Yep, but the certs.pem file only contains the root and does not know anything about intermediates.

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.

brewmarche 38 minutes ago | parent

Apple’s own security framework is supported by curl with OpenSSL or GnuTLS (build with ./configure --with-apple-sectrust). That blocks the intermediate certificates via the same mechanism Safari uses for example.

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

teki_one 47 minutes ago | parent

I think since 10.15 the built-in command line tools in MacOS are there mostly for backwards compatibility. This was clearly communicated about scripting languages, but there was a feeling back then that this was about the whole lot (all cli tools).

bestouff 1 hour ago | parent

Some depending on the executable, sometimes it goes through /etc/ssl/cert.pem and sometimes through the Apple framework. This OS is a mess.

ChrisClark 1 hour ago | parent

Are they just saying "do it yourself"? Can't they just send out an update?

cromka 1 hour ago | parent

Things like this is why I moved back to Linux after 10 years on macOS.

petcat 1 hour ago | parent

Not sure what Linux offers that's any better. Didn't Debian ship trivially weak SSH keys for over 2 years because they were trying to silence Valgrind warnings and the random maintainer had no idea what they were doing and there was no oversight or peer review whatsoever?

bawolff 50 minutes ago | parent

In 2008.

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

petcat 46 minutes ago | parent

Well that "screw up" was so egregious that it should take at least a decade to regain any trust.

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.

fg137 37 minutes ago | parent

Security practice was generally very, very bad two decades ago, by today's standards, across the industry.

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

petcat 30 minutes ago | parent

I was responding to the OP saying "stuff like this is why I'm moving back to Linux". It's nonsense.

baobabKoodaa 46 minutes ago | parent

Two decades

simondotau 45 minutes ago | parent

Somehow I doubt many people will be saying that about eMudhra a decade from now.

efficax 26 minutes ago | parent

i think you mean almost 20 years ago old man

usef- 47 minutes ago | parent

That's one issue from one distro 18 years ago. Have there been recent things? This thread is about a today's MacOS, and an issue known publicly for more than a week.

kobalsky 18 minutes ago | parent

You are going so back that gmail was served over HTTP (not HTTPS) in that era.

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

boxed 55 minutes ago | parent

It's funny. When Apple goes in and changes peoples systems deeply without consent then it's Apple being evil. When they don't, it's Apple being evil. Heads I win, tails you lose.

simondotau 51 minutes ago | parent

I've seen this referred to as the "All Roads Lead to Rome" fallacy.

1970-01-01 20 minutes ago | parent

Let's pretend there's a night and day difference between pushing some MP3 onto all iPhones and distrusting a chain of certs that hold the value of '4'. At minimum Apple need to revoke everywhere these joke-level certs live and as fast as possible, and on all devices which also means out of support. Breaking is acceptable here as CA trust is fully compromised.

paaloeye 1 hour ago | parent

> Anyone can intercept any HTTPS connection these tools make.

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.

mschuster91 57 minutes ago | parent

> You have to compromise a lot to be able to make a MITM here.

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

paaloeye 54 minutes ago | parent

> all you need is physical access to the network.

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.

bawolff 52 minutes ago | parent

Have you never used wifi at a coffee shop?

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

paaloeye 46 minutes ago | parent

I have, but good luck predicting where I'm going to have my next cuppa. Outside of petty crimes mentioned, I don't see how it could be industrially weaponised to make actual damage.

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

voidUpdate 41 minutes ago | parent

Compromising a specific person is difficult. Compromising any old person is trivial

rolosa 40 minutes ago | parent

Why would I care about you specifically, and not the dozens of other people working at the coffee shop? Does the world revolve around you?

ForHackernews 25 minutes ago | parent

Great, you have an inconvenient way to possibly-maybe see some random's gmail inbox at Starbucks.

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

jfyi 6 minutes ago | parent

[delayed]

mschuster91 48 minutes ago | parent

Public wifi hotspots tend to give you that opportunity. Large commercial hotspots have inter-client communication blocked, but your average coffee shop style network? You're lucky if it even is an isolated VLAN from the shop's cash register lol.

sersi 46 minutes ago | parent

I don't know why you're downvoted, any public wifi access point in a shop could be compromised and users would never notice.

treesknees 38 minutes ago | parent

Client isolation is very common on wireless and wired LANs these days in enterprise and guest network environments. You also have tools like dynamic arp inspection to block poisoning attempts via the network switch.

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.

raverbashing 17 minutes ago | parent

> all you need is physical access to the network

Yeah that's not so much "trivially easy"

breakwaterlabs 12 minutes ago | parent

Do you have a cell phone? Do you use Wifi? Do you use an ISP who, in the last few decades, has performed any form of interception or traffic-tampering?

I hazard that the answer to all three of those is "yes".

rekoil 50 minutes ago | parent

It's pretty easy to compromise things like McDonalds or Starbucks WiFi hotspots though, just setup a Pineapple with the right SSIDs and a 5G modem, funnel your target domains through your mitmproxy via the DHCP DNS server you're providing, and that's basically it.

I agree it's not PHP2Shell, but its certainly not being "way overblown" here.

1718627440 7 minutes ago | parent

Why would these public network would allow guest hosts to communicate with each other?

dspillett 50 minutes ago | parent

Don't underplay it either though: with a compromised but unrevoked signing cert all it takes is a successful phish, or some problem to allow DNS poisoning (or hack a wireless AP, or …) to direct you to a fake site or (potentially worse as it might be less immediately noticeable and could quietly collect credentials/data for a while) send your automated tools to a malicious API.

It may not be directly exploitable on its own, which is the impression some reports give, but it is a serious hole to leave open especially with the current rate of old security issues being found, as it could be _incredibly_ useful to a malicious actor as part of an exploit chain.

jfyi 34 minutes ago | parent

Yeah, it increases the attack surface of mitm attacks to your network from the local os level.

tensegrist 48 minutes ago | parent

php2shell was overblown perhaps but this is being blown quite correctly

chpatrick 30 minutes ago | parent

You can take your laptop to a busy place, make a "free wifi" hotspot that runs everything through mitmproxy and you can steal everything.

breakwaterlabs 14 minutes ago | parent

The near-universal use of TLS and the absurd ceremony we go through to ship root CAs everywhere is all premised on the idea that MITMs are not terribly difficult.

The entire reason one can rest easy as they connect to their coffee shop's WPA2-PSK network, is the security provided by TLS.

And if you don't think an ISP or agency would abuse this if it could be done undetectably then you haven't been paying attention these last 20 years (hence why DoH is now a thing).

yonatan8070 11 minutes ago | parent

Even a simple rouge AP is enough to become a MITM for this.

educar 12 minutes ago | parent

If you hijack the DNS, the laptop can be pwned quite easily. Think of all the coffee shops with unprotected routers out there.

chjj 11 minutes ago | parent

> You have to compromise a lot to be able to make a MITM here.

This is just an argument against TLS in general. Use plain http if you believe this.

kd913 54 minutes ago | parent

They just released MacOS 27.2 a few days ago? How and why did they not do a patch at least then?

majewsky 46 minutes ago | parent

It's actually worse: Installing the 27.2 update after manually cleaning out /etc/ssl/cert.pem will revert those changes and put the eMudhra CA back in.

Source: https://mstdn.social/@jschauma/117513596272504904 https://mastodon.social/@glyph/117509558825919922

chrisweekly 39 minutes ago | parent

Right, so it's not just git, it's a bunch of system-provided utilities; macOS trusts bad certs, and these utils that trust the OS are affected. I use homebrew for my git and curl but haven't yet checked to confirm whether that matters here. Kind of outrageous that Apple's guidance is to edit the cert chain manually, and to expect that subsequent OS updates may revert your mitigation, reintroducing the vulnerability (as happened at least once so far).

kqp 27 minutes ago | parent

Can we get a title edit? OP’s title implies this is a Git bug, but the bug applies to half of macOS, including curl, openssl, python, perl, and ruby, and to only the macOS version of Git. The original title is less misleading, but personally I’d have titled it something like “macOS still trusts the compromised eMudhra certificates in git, curl, openssl, python3, perl, ruby, more”.

6thbit 19 minutes ago | parent

There must be a long list of things that aren’t fully patched for this yet, on laptops, on servers. Think of packages that ship their own trust anchors, isn’t there a rust crate that compiles with some root certs embedded?

On one hand there’s unmaintained packages that won’t update dependencies. On the other hand, fixed dependencies did not necessarily backport to all possible versions in the wild, making update as a fix unviable for those.

WesolyKubeczek 13 minutes ago | parent

Doesn’t macOS have a way to generate cert.pem from the keychain?

altcognito 9 minutes ago | parent

I'm not that familiar with the MacOSx system, but do they have a "minor" update path that I'm not aware of? It seems that everything is an 8gb update. Is that why this update isn't getting put out?

__MatrixMan__ 5 minutes ago | parent

If you're not already in the habit of contacting your git remotes over ssh, its probably one worth building. This is gonna keep happening.