4 ms·

>Ultimately, you can't take dependencies for granted. The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to d

>Ultimately, you can't take dependencies for granted. The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to developers is generally not realistic. Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that? To compound things, this package could be a transient dependency of a transient dependency, so I may not even know the person who decided to depend on it in the first place, or the reason why, or what the package does. It's not that people are taking dependencies for granted - it's that there is no reasonable alternative.

starbeast 8y ago
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.
madrox 8y ago
There is a reasonable alternative, though...do not use that dependency! It's sure attractive (and easy) to use that one library with a thousand child dependencies, but that's a HUGE red flag that it's not as useful as you think it is.
- kylecordes 8y ago
  Incidentally this can come into play even for exceedingly popular packages. For example, consider deciding to use Babel versus TypeScript for ESn -> ES5. I am a fan of both, for different reasons and uses. Both are excellent tools, widely used, of great quality. Babel, configured in a typical way, will have at least hundreds of (transitive) dependencies. TypeScript has none, every line of code is from Microsoft. I have pointed this out to numerous people in the process of deciding between these tools; so far I don't think a single one has given this consideration any weight in the selection.
  - true_religion 8y ago
    I give it a lot of weight. Microsofts releases are backwards compatible in many cases, and when not, they always have a detailed transition path. Their changes are never motivated by having to change to suit an upstream packages new version, and their entire codebase is cohesive. Its what I like in a compiler: a stable tool that I never worry about.
Retra 8y ago
>Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that? People who care if their software works correctly. Everyone else relies only on herd immunity. If you have dependencies, you either belong to the first group or the second, and you make that choice. Neither choice is wrong, but it is still a choice you have to make and account for.

starbeast 8y ago

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.

madrox 8y ago

There is a reasonable alternative, though...do not use that dependency! It's sure attractive (and easy) to use that one library with a thousand child dependencies, but that's a HUGE red flag that it's not as useful as you think it is.

kylecordes 8y ago
Incidentally this can come into play even for exceedingly popular packages. For example, consider deciding to use Babel versus TypeScript for ESn -> ES5. I am a fan of both, for different reasons and uses. Both are excellent tools, widely used, of great quality. Babel, configured in a typical way, will have at least hundreds of (transitive) dependencies. TypeScript has none, every line of code is from Microsoft. I have pointed this out to numerous people in the process of deciding between these tools; so far I don't think a single one has given this consideration any weight in the selection.
- true_religion 8y ago
  I give it a lot of weight. Microsofts releases are backwards compatible in many cases, and when not, they always have a detailed transition path. Their changes are never motivated by having to change to suit an upstream packages new version, and their entire codebase is cohesive. Its what I like in a compiler: a stable tool that I never worry about.

Retra 8y ago

>Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that? People who care if their software works correctly. Everyone else relies only on herd immunity. If you have dependencies, you either belong to the first group or the second, and you make that choice. Neither choice is wrong, but it is still a choice you have to make and account for.