(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 :)
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.
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.
And curl was patched to use the native TLS implementation (SecureTransport) which obviously used Keychain as well.
For some reason when they switched to LibreSSL everywhere they decided to ship their own copy? I don't know what they were thinking.
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...
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.
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.
Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.