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
replyI 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
I see other people making this statement, but it sounds like a really really weird excuse.
replyIt’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.
replyIt 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?
replyI 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
replyAgreed. Why does macOS ship with two copies of the trust store? Shouldn't the process to update the primary store automatically derive the other?
replyOr they just missed a spot?
replyYes because that thing is completely useless and provides basically no value
replyApple has one job here and it isn't to make UIs that look like melted plexiglass. I am fucking pissed.
reply