3 ms·

CoreOS Linux Alpha Remote SSH Issue Post-Mortem

11 points by robszumski 10y ago

kchoudhu 10y ago
Thanks, but...Alpha software. Am I wrong in thinking of this as an overreaction?
- mjg59 10y ago
  There's an explanation of why we care about alpha releases in the article - does that cover it for you?
  - kchoudhu 10y ago
    Not really -- but I think that's because it's not clear/I don't understand (latter is more likely) what role the alpha channel plays in CoreOS deployments. I think I understand that you want us to use deployments of Alpha software as a smoke test in production environments. I'd be interested in hearing what risk profile you're expecting users to fit when deploying the Alpha channel in production systems, because it's completely alien to my way of thinking about stability in large scale systems. Today it's an SSH vulnerability, tomorrow it could be something worse. Who is going to take these risks in production?
    - mjg59 10y ago
      There's no strong reason to believe that the alpha releases have any worse security than other releases in the general case - the vast majority of security issues we've had to deal with are discovered months or years after they vulnerable versions first shipped, and so apply equally to stable. I don't think users should have entire deployments of the alpha releases, but I do think that one of the strengths of distributed computing is that you can run a subset of your deployment on alpha without worrying that bugs are going to take down your entire deployment. That makes it much easier for you to have confidence that new stable releases won't break things for you, which means you can adopt stable releases more quickly and avoid the security risks inherent in running older versions of software. For that to be possible you have to be confident that we're not shipping alpha releases with gaping security issues, and so it is a big deal when we fail in that respect.
zokier 10y ago
Nice writeup. I think the main takeaway from this story is that always remember to write tests for error handling in addition to "happy cases".

11 points by robszumski 10y ago

kchoudhu 10y ago

Thanks, but...Alpha software. Am I wrong in thinking of this as an overreaction?

mjg59 10y ago
There's an explanation of why we care about alpha releases in the article - does that cover it for you?
- kchoudhu 10y ago
  Not really -- but I think that's because it's not clear/I don't understand (latter is more likely) what role the alpha channel plays in CoreOS deployments. I think I understand that you want us to use deployments of Alpha software as a smoke test in production environments. I'd be interested in hearing what risk profile you're expecting users to fit when deploying the Alpha channel in production systems, because it's completely alien to my way of thinking about stability in large scale systems. Today it's an SSH vulnerability, tomorrow it could be something worse. Who is going to take these risks in production?
  - mjg59 10y ago
    There's no strong reason to believe that the alpha releases have any worse security than other releases in the general case - the vast majority of security issues we've had to deal with are discovered months or years after they vulnerable versions first shipped, and so apply equally to stable. I don't think users should have entire deployments of the alpha releases, but I do think that one of the strengths of distributed computing is that you can run a subset of your deployment on alpha without worrying that bugs are going to take down your entire deployment. That makes it much easier for you to have confidence that new stable releases won't break things for you, which means you can adopt stable releases more quickly and avoid the security risks inherent in running older versions of software. For that to be possible you have to be confident that we're not shipping alpha releases with gaping security issues, and so it is a big deal when we fail in that respect.

zokier 10y ago

Nice writeup. I think the main takeaway from this story is that always remember to write tests for error handling in addition to "happy cases".