6 ms·

My understanding is that /var was only removed on systems without SIP enabled, the recommended (and default) setting. This only affected users who went out of

My understanding is that /var was only removed on systems without SIP enabled, the recommended (and default) setting. This only affected users who went out of their way to disable this security feature. Presumably Google QA had this enabled on all their machines.

tannhaeuser 7y ago
That's hardly an excuse, is it? The question is whether, after this incident, you're still comfortable with using any Google app.
- cloudwalking 7y ago
  How many Chrome updates have you gotten that did not break your computer? Was your computer broken by this? My understanding is the rollout was stopped fairly quickly.
  - zepto 7y ago
    How many other equally dangerous and irresponsible mechanisms are Google using?
  - deleted 7y ago
    [deleted]
  - hinkley 7y ago
    How many times did Ann Rule interact with Ted Bundy and he didn't murder her once? I mean, he can't be all that murdery, right? We're talking about nuking a filesystem, not glitching out randomnly. That it hasn't nuked the filesystem before is not extenuating circumstances. It doesn't speak to character either.
    - filleduchaos 7y ago
      Yes, an app accidentally deleting a folder after you've turned off protections on that folder is definitely the same thing as serial killing. People here sometimes.
      - hinkley 7y ago
        > That's hardly an excuse, is it?
        filleduchaos 7y ago
        I was commenting on the hilariously bad choice of analogy.
- dreamcompiler 7y ago
  I'm as comfortable using Google apps today as I was a week ago, because I figured out long ago how to disable Keystone permanently. (It wasn't easy.) But I am rather pissed at Apple because SIP is a global switch and with it enabled, there are several significant, legitimate things you cannot do with your own computer. SIP should work like sudo, not like a meta version of root. If it did so, nobody would have been affected by this week's Google nonsense.
  - MarkyC4 7y ago
    > with it enabled, there are several significant, legitimate things you cannot do with your own computer. For those wondering about such a use case: the only way to get eGPU's working on <=2015 MBPs is to disable SIP (and use purge-wrangler). It's not officially supported because 2015s don't have TB3
TimTheTinker 7y ago
SIP is a relatively new feature. This would have been devastating only a few years ago. What Google did was effectively: sudo rm -Rf /var Would you trust a program that even attempted such a command on your machine? "But they had SIP disabled" is no defense for software that tries to take destructive action. SIP is intended to protect against malicious software and against users accidentally hosing their system; there are legitimate reasons for disabling it. This was not anyone's fault but Google's.
- sp332 7y ago
  I don't think this was intentional or malicious on Google's part. It's only not a defense for the QA team.
  - zepto 7y ago
    Whether it was malicious or not it was unnecessary and irresponsible. It’s not just a QA issue - it’s a design flaw.
    - sp332 7y ago
      I expect it was a typo, like that time Steam deleted people's data on Linux https://www.theregister.co.uk/2015/01/17/scary_code_of_the_week_steam_cleans_linux_pcs/ https://www.theregister.co.uk/2015/01/17/scary_code_of_the_w... , or [edit: ok this one probably isn't relevant] when Adobe CC removed random folders on Macs. https://help.backblaze.com/hc/en-us/articles/217665378--bzvol-is-missing https://help.backblaze.com/hc/en-us/articles/217665378--bzvo...
      - deleted 7y ago
        [deleted]
- magicalist 7y ago
  It's a symlink and / has to be writable by the logged in user, so it's actually just effectively rm /var
hotsauceror 7y ago
So, Google: 1) included code that performed dangerous system-level operations, despite the fact that 2) the included code was guaranteed to fail under the expected / default OS configuration? The only logic I could see for such a state would be "let's teach them a lesson" for those users who chose to operate in the "dangerous" configuration. It doesn't make sense why they'd even attempt the symlink removal.
- Tuna-Fish 7y ago
  or 3) They intended to remove a more specific symlink, with the address generated from variables, but due to bugs some/all of the variables were empty and the concatenation of the variables just produced /var instead. Which is the cause of like 90% of accidental "rm -rf /"s in history.
  - TimTheTinker 7y ago
    Right, but if you're a large software distributer, the onus is entirely on you to QA software releases on every possible OS configuration. If this were an individual working alone (or even a small company), I'd have some sympathy. But Google has enough to pay QA engineers and build a sufficiently sophisticated test lab. They should get no pass for this.
    - hinkley 7y ago
      Well, hold on. Let's not scapegoat another team for the fact that we can't seem to handle relative paths well after 30 years of spectacular case studies in how fucking stupid we are with path calculations. I'm always finding people doing string arithmetic instead of using the APIs. Sometimes I catch myself doing it. Rails got close to a solution by half-assedly tracking the provenance of all strings passed into certain functions. We could probably use a bit more of that.
      - TimTheTinker 7y ago
        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
Why do they have code that's trying to remove /var? Doing something stupid and relying on the safety equipment to save you is a stunt. Doing it with someone else's stuff is being an asshole. This is not the behavior of sober grown-ups.
- aidenn0 7y ago
  could be something as simple as "rm /var/$myfile" with myfile being null or unset. As long as /var isn't owned by the current user and/or SIP is installed, testing won't let them know they have a problem.
  - hinkley 7y ago
    This is why you should always construct paths in particular and URIs in general using your languages' path APIs instead of string interpolation. That doesn't protect you fully. You still have to check that $myfile is not undefined or "", but it helps with related problems and it tends to arrange the code in such a way that the lack of further sanity checks sticks out a bit more.

tannhaeuser 7y ago

That's hardly an excuse, is it? The question is whether, after this incident, you're still comfortable with using any Google app.

cloudwalking 7y ago
How many Chrome updates have you gotten that did not break your computer? Was your computer broken by this? My understanding is the rollout was stopped fairly quickly.
- zepto 7y ago
  How many other equally dangerous and irresponsible mechanisms are Google using?
- deleted 7y ago
  [deleted]
- hinkley 7y ago
  How many times did Ann Rule interact with Ted Bundy and he didn't murder her once? I mean, he can't be all that murdery, right? We're talking about nuking a filesystem, not glitching out randomnly. That it hasn't nuked the filesystem before is not extenuating circumstances. It doesn't speak to character either.
  - filleduchaos 7y ago
    Yes, an app accidentally deleting a folder after you've turned off protections on that folder is definitely the same thing as serial killing. People here sometimes.
    - hinkley 7y ago
      > That's hardly an excuse, is it?
      - filleduchaos 7y ago
        I was commenting on the hilariously bad choice of analogy.
dreamcompiler 7y ago
I'm as comfortable using Google apps today as I was a week ago, because I figured out long ago how to disable Keystone permanently. (It wasn't easy.) But I am rather pissed at Apple because SIP is a global switch and with it enabled, there are several significant, legitimate things you cannot do with your own computer. SIP should work like sudo, not like a meta version of root. If it did so, nobody would have been affected by this week's Google nonsense.
- MarkyC4 7y ago
  > with it enabled, there are several significant, legitimate things you cannot do with your own computer. For those wondering about such a use case: the only way to get eGPU's working on <=2015 MBPs is to disable SIP (and use purge-wrangler). It's not officially supported because 2015s don't have TB3

TimTheTinker 7y ago

SIP is a relatively new feature. This would have been devastating only a few years ago. What Google did was effectively: sudo rm -Rf /var Would you trust a program that even attempted such a command on your machine? "But they had SIP disabled" is no defense for software that tries to take destructive action. SIP is intended to protect against malicious software and against users accidentally hosing their system; there are legitimate reasons for disabling it. This was not anyone's fault but Google's.

sp332 7y ago
I don't think this was intentional or malicious on Google's part. It's only not a defense for the QA team.
- zepto 7y ago
  Whether it was malicious or not it was unnecessary and irresponsible. It’s not just a QA issue - it’s a design flaw.
  - sp332 7y ago
    I expect it was a typo, like that time Steam deleted people's data on Linux https://www.theregister.co.uk/2015/01/17/scary_code_of_the_week_steam_cleans_linux_pcs/ https://www.theregister.co.uk/2015/01/17/scary_code_of_the_w... , or [edit: ok this one probably isn't relevant] when Adobe CC removed random folders on Macs. https://help.backblaze.com/hc/en-us/articles/217665378--bzvol-is-missing https://help.backblaze.com/hc/en-us/articles/217665378--bzvo...
    - deleted 7y ago
      [deleted]
magicalist 7y ago
It's a symlink and / has to be writable by the logged in user, so it's actually just effectively rm /var

hotsauceror 7y ago

So, Google: 1) included code that performed dangerous system-level operations, despite the fact that 2) the included code was guaranteed to fail under the expected / default OS configuration? The only logic I could see for such a state would be "let's teach them a lesson" for those users who chose to operate in the "dangerous" configuration. It doesn't make sense why they'd even attempt the symlink removal.

Tuna-Fish 7y ago
or 3) They intended to remove a more specific symlink, with the address generated from variables, but due to bugs some/all of the variables were empty and the concatenation of the variables just produced /var instead. Which is the cause of like 90% of accidental "rm -rf /"s in history.
- TimTheTinker 7y ago
  Right, but if you're a large software distributer, the onus is entirely on you to QA software releases on every possible OS configuration. If this were an individual working alone (or even a small company), I'd have some sympathy. But Google has enough to pay QA engineers and build a sufficiently sophisticated test lab. They should get no pass for this.
  - hinkley 7y ago
    Well, hold on. Let's not scapegoat another team for the fact that we can't seem to handle relative paths well after 30 years of spectacular case studies in how fucking stupid we are with path calculations. I'm always finding people doing string arithmetic instead of using the APIs. Sometimes I catch myself doing it. Rails got close to a solution by half-assedly tracking the provenance of all strings passed into certain functions. We could probably use a bit more of that.
    - TimTheTinker 7y ago
      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

Why do they have code that's trying to remove /var? Doing something stupid and relying on the safety equipment to save you is a stunt. Doing it with someone else's stuff is being an asshole. This is not the behavior of sober grown-ups.

aidenn0 7y ago
could be something as simple as "rm /var/$myfile" with myfile being null or unset. As long as /var isn't owned by the current user and/or SIP is installed, testing won't let them know they have a problem.
- hinkley 7y ago
  This is why you should always construct paths in particular and URIs in general using your languages' path APIs instead of string interpolation. That doesn't protect you fully. You still have to check that $myfile is not undefined or "", but it helps with related problems and it tends to arrange the code in such a way that the lack of further sanity checks sticks out a bit more.