Hacker News

points by mixdup 1 day ago | 0 comments

That fast-track method was used, but it only applies to "graphical" software which really means, software that uses Apple's macOS specific APIs and frameworks, not the lower level UNIX stuff like /etc/ssl

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

[–] genxy 1 day ago

I see other people making this statement, but it sounds like a really really weird excuse.

[–] acdha 1 day ago

It’s not an excuse but an explanation: there are separate stacks owned by different teams and they haven’t been forced to collaborate. If you use an internal CA you’ve already had to deal with the easier additive version of this problem because that fails in an obvious, less harmful manner than quietly accepting something which needed to fail.

[–] genxy 1 day ago

It doesn't explain why Apple who 1) sells itself on security and 2) ease of use doesn't 3) update what it installed and protect its users. Why are they not doing those things?

[–] mixdup 1 day ago

I wasn't trying to excuse anything, just explain that they haven't done nothing, but also why it's still an issue. I agree with you they've dropped the ball here. If I were a betting person I'd guess this is just something that slipped through the cracks and there will be changes whether that's to the release process for pushing OS updates, to the fast-track security update process, or to the OS so that everything is working off the same trust store

[–] mdavidn 1 day ago

Agreed. Why does macOS ship with two copies of the trust store? Shouldn't the process to update the primary store automatically derive the other?

[–] jonny_eh 1 day ago

Or they just missed a spot?