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

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.

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.

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

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

It's also an indictment of Apple's relationship to open source software. Never mind contributing back to upstream, they haven't even made the change in their own fork to support their own keychain.

> Is using the system CA not the way to go?

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.

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

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.

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

Does /etc/ssl/cert.pem not exist if you don't install XCode?

Fair. I didn't read it as something specific to git cause I know how it works with MacOS

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

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.

No, unless it’s were a cli image viewer. The gui parts of the OS, and what’s written by Apple, use keychain.

Macs have two completely independent root CA stores. The cli and all the opensource parts use /etc/.

Curl project did actually release support to compile it with default keychain support a year ago, but of course Apple never updates their cli tools, so expect to see that in macOS 37.

Note: I’m not defending Apple here.

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.

Agreed.