3 ms·

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

ghostly_s 9y ago
I don't think empty password on root is the issue here; enabling root when the user did not intend to and did not have permission to is. Isn't empty password for root a default state for systems where direct root login is not enabled? And isn't enabling root with no password the intended behavior when booting into Single User Mode?
fooey 9y ago
Exactly, testing the UI may be hard, but whatever API that UI is calling is amazingly horribly broken.
- qubex 9y ago
  And fascinatingly wasn’t broken until very recently...
qubex 9y ago
Following and furthering your logic, what the hell could they have been doing in the codebase to revert a control mechanism that was effective up to and including 10.12.6, but unsafe as of 10.13.0 onwards???
- CiPHPerCoder 9y ago
  A graceful upgrade mechanism towards a new password hashing algorithm.
  - glhaynes 9y ago
    Change is so, so risky.
    - CiPHPerCoder 9y ago
      There's a lot that can go wrong, which is why writing testable code and then /actually/ testing it, matters so much.
geofft 9y ago
The code was not supposed to enable the root user in the first place, so I'd be surprised if someone added an assertion that anything about the root user's account was set. It was only supposed to check the root user's password. I suppose you could write an assertion that the code didn't enable the root user, but I'm pretty sure that no password-validation routine anywhere in the history of the world has ever had a test case to make sure it didn't modify the account while validating it. These are unknown unknowns. If you knew enough to write the right test, you wouldn't have written the bug in the first place.

ghostly_s 9y ago

I don't think empty password on root is the issue here; enabling root when the user did not intend to and did not have permission to is. Isn't empty password for root a default state for systems where direct root login is not enabled? And isn't enabling root with no password the intended behavior when booting into Single User Mode?

fooey 9y ago

Exactly, testing the UI may be hard, but whatever API that UI is calling is amazingly horribly broken.

qubex 9y ago
And fascinatingly wasn’t broken until very recently...

qubex 9y ago

Following and furthering your logic, what the hell could they have been doing in the codebase to revert a control mechanism that was effective up to and including 10.12.6, but unsafe as of 10.13.0 onwards???

CiPHPerCoder 9y ago
A graceful upgrade mechanism towards a new password hashing algorithm.
- glhaynes 9y ago
  Change is so, so risky.
  - CiPHPerCoder 9y ago
    There's a lot that can go wrong, which is why writing testable code and then /actually/ testing it, matters so much.

geofft 9y ago

The code was not supposed to enable the root user in the first place, so I'd be surprised if someone added an assertion that anything about the root user's account was set. It was only supposed to check the root user's password. I suppose you could write an assertion that the code didn't enable the root user, but I'm pretty sure that no password-validation routine anywhere in the history of the world has ever had a test case to make sure it didn't modify the account while validating it. These are unknown unknowns. If you knew enough to write the right test, you wouldn't have written the bug in the first place.