I hope they won't stop to this brief summary, because a "logic error in the validation of credentials" shouldn't be able to allow the creation of a root super user with empty password.
I'm hope they'll go deep in the gory details, to show us how it's in fact much more complicated than a "if !password { createEmptySuper()}" line written by mistake.
All of those things might be fine, on their own.
However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system.
I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks.
Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence).
Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX.
TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.
While the file is still there in the same form it would be on a truly POSIX compliant system, the functionality is not.
The change I proposed, or other equivalent changes, might "loudly"/fatally break programs that rely on the /etc/passwd style of auth, but if those programs are depending on POSIX-compliant behavior based on that file on OSX systems already, they are likely "silently"/more subtly broken (which, when it comes to code that interacts with the security system, is a much worse thing, I think). It's the same old accessibility/security compromise as ever though.
Why <blank> Gets You Root: https://objective-see.com/blog/blog_0x24.html