Following the eMudhra incident I made a tool to distrust all except the 30 most essential CAs on my Linux and Windows systems (https://github.com/hyperreality/distrust). I was shocked at how messy the situation is on Linux, with browsers, CLI tools, programming languages all having their own stores and distros building the bundles differently (update-ca-certificates in Debian vs update-ca-trust in Arch or Fedora). Or like Firefox not using the certs in /usr/share/ca-certificates/mozilla/ but its own per-profile NSS store instead. There has to be a better way.

Apple's official API had revoked the certificate within hours. Only the Unix compatibility layer they sort-of maintain has this problem. This is hardly the first or only outdated Unix compat tool they ship with their OS.

Not great for unaware developers, but most macOS users are fine. Those who are aware can follow the steps in https://support.apple.com/en-us/149555 until Apple bothers to roll out an update.

I used to manage OS level trust root management for all internal machines at a hyperscaler. Hundreds of thousands of machines. Even when you have an edict from a common VP or CEO, and most people are even using the same linux distributions, it's hard to get people to adhere to or even understand that there is a standard. Throw containers, embedded devices, windows and mac in and it's just a total nightmare unless you exert strict control on how every single machine is set up. Which, of course, is impossible because cowboys gonna cowboy.

Fundamentally, people don't want to think about the intricacies of how we decide whether or not to trust a particular cert. They want it to just work without thinking about it. This includes that if they have a custom private root they need to trust, they just drop it various places until it starts working and call it done. And sometimes they do weird things like adding intermediates to their trust store because they were trying to call a service that has their cert chain configured incorrectly, and that "fixes it". Again, it's a nightmare.

The fact that linux, a system notoriously cobbled together by 873 different factions on the internet, is even more of a mess is not surprising in the least.

The thing that makes this especially odd is that Apple apparently has a fast-track way of shipping security patches for the OSs that don't require the user to go through the lengthier OS upgrade process. But for some reason, they haven't used it here.

Yeah, why may that be hard? That’s the question

I don’t think it’s gross incompetence, since they documented the steps to remove. They may have some unexpected dependency on the file? Looks mysterious from the outside.

> Is /etc/certs not used by most graphical Mac software, I guess?

Correct, those usually use Apple's networking APIs which all go through their security stack, which already picked up the OCSP revocation within about 2 hours in most cases.

this only affects terminal apps, which the vast majority of MacOS users don't run; the fix for graphical Mac software is already patched

my guess is their thinking is that if you're running those apps on Mac, you're a developer or know what you're doing, and can edit /etc/ssl/cert.pem until they push an update

they also have to consider that such users may have custom changes to their cert.pem file, and they probably don't want to rush an update that would potentially fu-bar those changes