4 ms·

I believe that npm no longer allows for republishing existing versions. Wouldn't this restriction remove this vulnerability altogether?

try_again 7y ago
It won't protect against a newer version of an established library introducing malicious behaviour.
- bluehatbrit 7y ago
  This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same. Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.
  - fpereiro 7y ago
    Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround. Thanks everyone for pointing out this issue.
    - bluehatbrit 7y ago
      In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.
jessaustin 7y ago
You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update. I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...
- t0astbread 7y ago
  Why the oldest possible?
  - jessaustin 7y ago
    Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.
    - t0astbread 7y ago
      I see. I've never heard of that before, thanks for sharing!

try_again 7y ago

It won't protect against a newer version of an established library introducing malicious behaviour.

bluehatbrit 7y ago
This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same. Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.
- fpereiro 7y ago
  Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround. Thanks everyone for pointing out this issue.
  - bluehatbrit 7y ago
    In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.

jessaustin 7y ago

You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update. I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...

t0astbread 7y ago
Why the oldest possible?
- jessaustin 7y ago
  Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.
  - t0astbread 7y ago
    I see. I've never heard of that before, thanks for sharing!