4 ms·

Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked

Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.

bendmorris 8y ago
I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing. Stack (https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.
PeterisP 8y ago
This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common. If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.
- bendmorris 8y ago
  >If semantic versioning always behaved as it should be The exploit in question specifically relied on this expectation, by creating a new patch release for the exploit. Even if you could trust well-intentioned maintainers to use it correctly, there's always this risk.
nradov 8y ago
In theory perhaps, but in practice what actually happens is that your dependencies gradually fall so far out of date that after a couple of years it becomes impossible to upgrade anything at all. Then it becomes impossible to add features and before you know it the whole application is dead end legacy code.

Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.

bendmorris 8y ago

I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing. Stack (https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.

PeterisP 8y ago

This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common. If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.

bendmorris 8y ago
>If semantic versioning always behaved as it should be The exploit in question specifically relied on this expectation, by creating a new patch release for the exploit. Even if you could trust well-intentioned maintainers to use it correctly, there's always this risk.

nradov 8y ago

In theory perhaps, but in practice what actually happens is that your dependencies gradually fall so far out of date that after a couple of years it becomes impossible to upgrade anything at all. Then it becomes impossible to add features and before you know it the whole application is dead end legacy code.