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.
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.
Apple has always been quietly hostile to the use of Terminal and command line tools: "You're not using XCode or our approved APIs so it's your problem, update it yourself"
FedericoSchonborn | 11 hours ago
You're expecting too much from a little trillion dollar company.
snej | 7 hours ago
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.
muvlon | 7 hours ago
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.
snej | 7 hours ago
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.
pyj | 6 hours ago
High risk, uncommon operations are also especially slow in large organizations.
gerikson | 10 hours ago
Discussion on Apple's official statement regarding this: https://lobste.rs/s/xzp4m0/about_compromised_emudhra_intermediate
hoistbypetard | 11 hours ago
Thank you for running the service we can use for a one-line test!
sri | 6 hours ago
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.
kngl | 3 hours ago
It's fixed in homebrew: https://github.com/Homebrew/homebrew-core/commit/5af25e905526dc43c557a3d2a5e2ef14e4bfe60b
ismail | an hour ago
That
TODOshould beNOT-TODO. Apple ships outdated curl and expat and others. Except libc Homebrew should be using its own libraries.jjuran | an hour ago
It's also fixed in MacPorts.
mperham | 5 hours ago
Apple has always been quietly hostile to the use of Terminal and command line tools: "You're not using XCode or our approved APIs so it's your problem, update it yourself"
mxey | 5 hours ago
Git is part of the “Xcode Command Line Tools”.
ianloic | 7 hours ago
Nobody's relying on the command-line tools that Apple ships to be secure.
hailey | an hour ago
How do you know?
matthiasportzel | 10 hours ago
carsyoursken | 5 hours ago
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