4 ms·

The fact that this got through Google's QA is inexcusable. Yeah I understand a dev messed up. It happens. But it should have been caught before being released.

The fact that this got through Google's QA is inexcusable. Yeah I understand a dev messed up. It happens. But it should have been caught before being released. All it would have taken is testing the installer on a non-SIP Mac.

hinkley 7y ago
In this case a smoke test on such a Mac could have sufficed, yes. But even when I have a QA team, which is less and less often, I like the devs to be involved in setting up stuff like this. QA is often not so good at engineering robust tests. But if they could write better code than we can they’d make more money as devs. So I’m still not letting the devs off the hook. This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. It’s tantamount to a SQL injection attack, but with less data in the “query” instead of more. You should not be assembling file paths for destructive writes or deletes by string concatenation. But this is on almost nobody’s radar. Is anyone else in this thread advocating for a change in software design? Mostly we are all blaming Google for fucking up. This is the headspace everyone but PHP was in for SQL fifteen years ago.
- TimTheTinker 7y ago
  > This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. Like most failures, the analysis needs to identify a chain of events involving various failures; perhaps it would go something like this: 1. Industry and libraries commonly use strings for path/URI manipulation. 2. A software engineer did so in the installer and made a typo. 3. Code review did not identify the problem. 4. QA (and the CI process) didn't test on a Mac that was either old enough not to have SIP or had SIP disabled. 5. Many Mac users, especially in specialized environments running custom or specialized kernel extensions and drivers, use macOS with SIP disabled. 6. Chrome is widespread enough that some users in (5) downloaded the update. That subset had their Mac systems hosed. I would identify (2), (3), and (4) as problems in the chain where Google carries blame.

hinkley 7y ago

In this case a smoke test on such a Mac could have sufficed, yes. But even when I have a QA team, which is less and less often, I like the devs to be involved in setting up stuff like this. QA is often not so good at engineering robust tests. But if they could write better code than we can they’d make more money as devs. So I’m still not letting the devs off the hook. This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. It’s tantamount to a SQL injection attack, but with less data in the “query” instead of more. You should not be assembling file paths for destructive writes or deletes by string concatenation. But this is on almost nobody’s radar. Is anyone else in this thread advocating for a change in software design? Mostly we are all blaming Google for fucking up. This is the headspace everyone but PHP was in for SQL fifteen years ago.

TimTheTinker 7y ago
> This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. Like most failures, the analysis needs to identify a chain of events involving various failures; perhaps it would go something like this: 1. Industry and libraries commonly use strings for path/URI manipulation. 2. A software engineer did so in the installer and made a typo. 3. Code review did not identify the problem. 4. QA (and the CI process) didn't test on a Mac that was either old enough not to have SIP or had SIP disabled. 5. Many Mac users, especially in specialized environments running custom or specialized kernel extensions and drivers, use macOS with SIP disabled. 6. Chrome is widespread enough that some users in (5) downloaded the update. That subset had their Mac systems hosed. I would identify (2), (3), and (4) as problems in the chain where Google carries blame.