Meanwhile, it's unsafe to run `git clone` on macOS unless you manually edit some files, and then edit them again after a macOS update puts the dangerous root certificates back.
In what world has Apple been the most "thorough"?
[–] LoganDark 1 day ago
[–] fg137 1 day ago
Looking forward to a comment that is much more grounded than substantial than this.
[–] LoganDark 1 day ago
> can still accept these certificates until a future software update
This suggests they don't have the capability to patch it with Rapid Security Responses / Background Security Improvements, given that they haven't.
Sure, I speculate that they likely would have already if they could have. Sure, I speculate that if they couldn't have, they might add the capability for the future. Sure, I speculate about why they wouldn't have already had a process for this. Whatever whatever. Disregard all that if you want, but the fact remains in the article.
[–] thenewnewguy 1 day ago
Why would I judge Apple only on the quality of this docs page (which is good) but not on their poor work that resulted in this situation in the first place?
[–] LoganDark 1 day ago
[–] thenewnewguy 1 day ago
Most (if not all) of the popular BSDs managed to ship the update ages ago. I would expect a trillion dollar company like Apple to have better and more thoughtful engineering than random volunteer projects.
[–] LoganDark 17 hours ago
Sure. It's not their fault for failing now to use a capability that doesn't exist, though. I feel like the difference is lost on some people, but they're already in this situation.
[–] Sohcahtoa82 1 day ago
[–] LoganDark 1 day ago
> I'm sorry, but how is revoking a bad cert not supported in an easy way? Along with adding a cert and using it to establish a secure connection, that seems to be the core features of a cert store?
> Yet somehow, you manage to come to the conclusion that the vendor requiring manual work is the most thorough? I mean, in documenting their failure, maybe.
> With all their talk of caring about user privacy, this seems incompetent at best.
To be fair other vendors almost universally don't document their failures at all or provide any remediation steps to users whatsoever. I always enjoy the exceptions to this rule, but it's not the norm whatsoever.
You seem to be ignoring that Apple's security framework responded to the incident within about 2 hours in most cases. Safari and other macOS apps were protected right off the bat.
It's only this legacy BSD store that needs an OS update, almost certainly because they simply didn't already have a process in place to update it out-of-band. Because they're vertically integrated, they probably don't have an arbitrary do-anything feature that can paper over the lack of foresight here, like other vendors might.
I'd honestly consider that a feature, but sure, the benefits would outweigh the risks in this one particular case.
Apple security updates, especially automatic ones, likely don't have the capability to simply write to arbitrary files on the system or run arbitrary commands at install time. Of all vendors, certainly from Apple I'd expect this.
Most likely, other vendors either already used a similar store as the root of trust system-wide (didn't have their own separate security stacks), or their security updates do have the ability to write anywhere or do anything.
And of course, Linux distros and other platforms where the component can be updated separately from the operating system have an even easier time.
This is not Apple intentionally leaving terminal users high and dry. The article literally is the proof otherwise while they no-doubt work on a better solution.