What a clusterfuck
they solved the issue for the people they care about
Also, if they didn't care about Terminal users, they would not have even published this article!!
A lot do it because sometimes there is no convenient library wrapping what they are trying to check or execute that they are aware of, and running a cli command is generally cheap unless you are doing it in a tight loop. A lot of the time this is “it'll do until I find the right library or bindings” code that should have been fixed before release, but it isn't all as bad as running top as you describe.
I don't blame Apple for overlooking it when they have their own security stack that all their own apps use, which already responded to the incident within two hours of the revocation. As another commenter pointed out, Terminal commands probably just weren't a priority of their threat model. I do hope they fix that, but mentioning their market cap is not gonna help here.
Come on Apple, do better.
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"?
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.
> 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, presumably because they didn't 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 wouldn't have it any other way, but sure, the benefits would outweigh the risks in this one particular case.
* apple told admins how to fix the vulnerability * apple shipped update 27.2, with no fix (today) * the update reverted the admin fix quietly
dorianmariecom•58m ago
boxed•55m ago
LoganDark•44m ago