Apple's git still trusts the compromised eMudhra certificates
96 points by galadran
96 points by galadran
You're expecting too much from a little trillion dollar company.
Things often take longer at bigger companies. (I've worked at Apple, Google, Sun…)
I suspect that for some reason the process to create/test/release a security update touching files in /etc is separate from, and slower than, the process to update the OS trust settings.
Especially since this only affects a small fraction of their user base — for all I know that file may not even exist until the dev tools package is installed.
It may affect a small fraction of their user base directly, but developers and other git users are high-value targets because a compromise there can often lead to supply chain compromise that will affect a much larger group of people.
This is true. I think the primary slowdown is just bureaucracy, aka procedures you have to follow before rolling out any software update to billions of users.
Discussion on Apple's official statement regarding this: https://lobste.rs/s/xzp4m0/about_compromised_emudhra_intermediate
In their instructions, Apple made a point of noting that these certs need to be manually removed after every single update. Makes me think they have some private reason for not fixing it anytime soon. I suggest making a macro or script or something; we might have to do this a few times.
It's fixed in homebrew: https://github.com/Homebrew/homebrew-core/commit/5af25e905526dc43c557a3d2a5e2ef14e4bfe60b
That TODO should be NOT-TODO. Apple ships outdated curl and expat and others. Except libc Homebrew should be using its own libraries.
The fix is... wow, like, shouldn't there just be a file somewhere I can delete? It just seems like a really complicated procedure for something that is, at least ostensibly, intended to be accessible to users.
Let's not forget the firm that caused this mess, and later washed off their hands, whose stocks people are still buying > https://www.google.com/finance/beta/quote/EMUDHRA:NSE?window=1M