[Dylan16807]

You can't blame com.apple.loginwindow for that. The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving. If we wanted to make this secure we would only need to carefully craft it, and even if com.apple.loginwindow was the most complex heap of bugs in the world it wouldn't matter.

[michaelmcmillan]

> The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving.

Which is my point. More code, more complexity, more bugs. If you are correct, the security boundary you are referring to got stretched out to accommodate a separate system.

As for your strategy on separating concerns and carefully crafting important code – don't you think that's what they originally had in mind when they first designed it?

[Dylan16807]

I don't think the security boundary was actually expanded, I think it had a hole punched in it. I doubt the bulk of com.apple.loginwindow was coded to enforce that particular security at all.

loginwindow is not doing the wrong thing because it's complex. It's doing the wrong thing because that was never its job.

> don't you think that's what they originally had in mind when they first designed it?

Probably, but they didn't fail because loginwindow itself was complex. They failed either for systemic reasons that would have happened with simple or complex code, or they failed because the actual secure part was too complex. That's why I think total complexity is the wrong thing to look it; it may or may not correlate with those two real causes.

[michaelmcmillan]

"Systemic reasons" sounds a lot like complexity to me. Do you have a counterexample of a simple system that blew up like this due to systemic reasons?

[Dylan16807]

Every time a prototype has been pushed into production. Simple code, but not tested or polished or designed for performance. This happens constantly.

The drive encryption password hint bug looked like a symptom of something like that. The utility was rewritten in a rush, and it's probably not a whole lot of lines of code. But it didn't have even basic testing.

[michaelmcmillan]

A prototype is of considerable less size than 100.000.000 loc. I claimed that complexity is correlated with lines of code. I pose the same question: Show me a simple system that failed due to systemic reasons.

[Dylan16807]

> A prototype is of considerable less size than 100.000.000 loc.

Yes? Agreed? It's simple, and yet it fails, because of management problems. That kind of management issue can happen to simple code or complex code.

Are you asking me to name a failure that's simple and large/complex at the same time? I'm confused.

Let me restate my position:

You originally brought up total lines of code. mikeash made a point that it's not total lines of code, it's code in relevant system, like ECU or the login service. I'm arguing in support of that point.

Complexity correlates with lines of code. But different subsystems can have different complexities. Especially when they're written by different teams.

The fact that the login service had special behavior wrt com.apple.loginwindow does not mean the complexity of com.apple.loginwindow is a notable factor. Com.apple.loginwindow was almost certainly not designed to enforce the security guarantees that the login service is responsible for. Its role could be played by either very complex code, or very simple code.

If the login service failed because of complex code, it failed because it was made of complex code. Not the total across the entire system.

Go ahead and pretend I never mentioned "systemic reasons" if it makes my argument make more sense to you. That was only about a possible scenario where the problem wasn't complex code. If complex code is the problem, then "systemic reasons" are utterly irrelevant. You don't need to argue that "systemic reasons" are complexity in disguise. Just delete that phrase entirely from my argument.