For your tool, remember to nuke Windows' automated certificate authority updates (separate from normal Windows updates) and possibly the automated intermediary cache. Microsoft publishes a list of trusted CAs/intermediaries periodically and they get automatically applied to Windows so websites don't need to send the full cert chain during TLS negotiation, and it has a tendency to cache trusted intermediaries as well.
Mozilla's trust store is one of the first to get updated when a revocation happens, as well as Google's CRLsets. Downloading full CRLs repeatedly would be a waste of time and bandwidth, that's why there's a specific distribution method for CA updates. I would extend your tool with a daemon that checks for revocation automatically, so you don't accidentally eMudhra yourself while browsers and the OS get updates next time something like this happens.
This feels like all of the C code getting attacked now where everyone spent the last three decades building up cruft because fixing it would be a chore, and now the separate bills are coming due all at the same time.
Then someone would ask "there has to be a better way" again, when the reason for the new inconvenience gets forgotten, and it oscillates.
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.
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 suspect the fast-track background security updates can only update the databases and revocation lists that live in the proprietary APIs, not any arbitrary file on the system
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.
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, and maybe this is what Apple should have done (it’s the workaround they recommend!). But it means that some small percentage of certificates that are fine won’t be accepted.
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.
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
Whatever reason Apple had for not updating /etc/ssl/cert.pem yet, I am certain it's not out of consideration for users that might have put custom certs in there.
not convinced? take a look at your /etc/ssl/cert.pem