6 ms·

It's damned if you do, damned if you don't for packages in the middle of your direct dependencies and a sub-sub dependency with an issue (be it security or tant

It's damned if you do, damned if you don't for packages in the middle of your direct dependencies and a sub-sub dependency with an issue (be it security or tantrum based). These middle deps could pin the exact version, but then when a security vuln is found and a patch issued, these libraries also need to update. This is like a traffic jam. If you're 6 hops from the vulnerable package you need to wait for not one, but six maintainers to push an update to npm before you can clear the security warning. To get around this, middle packages list semver ranges. And then you have your occasional left-pad issue. If I had to choose between those two ways to lose, I would use server ranges. The only way to win is to not play at all - have no dependencies.

johannes1234321 5y ago
as an example look at the log4j mess. "Everything" in the Java world needs log4j updates, but some dependecy's dependencies pull in some specific version. There you need the way to say "get the new version from 5 minutes ago" without waiting for all levels of the dependency hierachy. Especially as there were a bunch of emergency releases in short sequence and younhabe tonmake sure youbget zhe latest one. Dependencies are a mess. NIH can't be the solution either, though.
- watwut 5y ago
  You can ask for specific later fixed log4j version. You don't have to ask for unspecified latest one.
  - acdha 5y ago
    This isn't the problem being discussed: when something like log4j happens, everyone in the world needs to update. The difference is if one of your dependencies pin 2.14.0, you either have to wait for that project to also ship an update or do something more complicated whereas if they specify less than version 3 you can immediately ship that patch. Something like log4j or many packages in the NPM world are so widely used that on any non-trivial project the odds approach certainty that multiple dependencies will specify versions. The more specific the pin, the more likely it is that you'll be unable to ship a security update without risk of a functional change or blocking incompatibility. You can mitigate that with good CI/CD infrastructure and lots of automated testing, but that means taking on more infrastructure expense.
    - zkldi 5y ago
      What if the patch for the buggy `2.14.0` library was released as `3.0.0`? In semver MAJOR can be a superset of MINOR and PATCH, so this is a perfectly logical semver operation. You still have the exact same problem you described with `^2.14.0`. Someone would have to manually update the package to get the security fix in 3.0.0. Unless you're suggesting code should also automatically update major versions aswell?
      - acdha 5y ago
        Yes, if someone chooses not to follow semver correctly they can create problems but there are a somewhat unlimited number of ways in which an untrustworthy maintainer can do that. The difference is that following semver means it's easy to not do that since they can always ship 2.<latest + 1> with no changes other than the security fix.
        johannes1234321 5y ago
        > The difference is that following semver means it's easy to not do that since they can always ship 2.<latest + 1> with no changes other than the security fix. If the line between bug and feature were clear. (Log4j worked 100% as specified btw. in regards to log4shell) https://xkcd.com/1172/ https://xkcd.com/1172/
        zkldi 5y ago
        This is following semver correctly. A PATCH update may be a MAJOR update (since its a superset) and it may be considered a breaking change.
    - watwut 5y ago
      You don't have to wait till that lib updates. You update version yourself and overwrite it. Second, log4j is bad examples. Libraries don't pin that at all and people report bug is they do. Libraries are supposed to depend on logging api in general and end project decides whether use log4j or slfj.
- jonny_eh 5y ago
  What if NPM allowed a "global minimum version" for any package found to have critical security vulnerability?
  - johannes1234321 5y ago
    global for what? How much tracking of issues do I have to make? In an ideal world (which we can't have for multiple reasons) I get security fixes by default. (and no other breakage)
- MattPalmer1086 5y ago
  No, we really don't need a way to say get the last version from 5 minutes ago. We need to get the version that we tested with and know works, which is what it does. When we need to update, we say what version we want. Java can be a pain, but I'm very glad it doesn't handle dependencies like npm.
  - acdha 5y ago
    This is also saying you can't easily update from 1.2.3 to 1.2.4 without all of your dependencies which specify 1.2.3 also being updated without having an override mechanism. This isn't a simple problem where one option has no downsides.
    - MattPalmer1086 5y ago
      Oh, I agree that there's no simple solution that solves everything. I'm still glad that basically noone else handles dependencies like npm.
      - remram 5y ago
        Everybody else handles dependencies like npm, e.g. installs the latest versions that satisfy constraints. Some package managers have the ability to install from a lock file (e.g. Python's Poetry, Python's Pipenv, Rust's Cargo, npm) but will still grab the latest version when the lockfile doesn't exists (e.g. cloned a project with no lock file, or just added the dependency yourself), and have a command to update which updates every single package to the latest compatible versions. You can argue that npm's commands are poorly named and guide users towards bad defaults, but saying that it works in a unique way is not true.
        MattPalmer1086 5y ago
        I guess my experience is limited. For example, maven dependencies usually specify the exact version required in the pom files. At least, on all the projects I've ever dealt with.
- cesarb 5y ago
  > "Everything" in the Java world needs log4j updates, but some dependecy's dependencies pull in some specific version. There you need the way to say "get the new version from 5 minutes ago" without waiting for all levels of the dependency hierachy. At least with Maven, that's extremely simple. Just add to your project a dependency on that "new version from 5 minutes ago" of log4j. Maven always prefers the version from a direct dependency. You don't have to wait for "all levels of the dependency hierarchy" at all.
  - kristjansson 5y ago
    The problem is that, AIUI, each NPM package installs its own, isolated set of dependencies. It has facilities to manage versions down in the dep tree, but it’s not as simple as other managers which ultimately install a single set of packages that satisfy all version constraints.
    - johannes1234321 5y ago
      many java jars contain other jars withbthe dependency, so users don't have to run maven or something like thst, but jsut grab the jar. This is even worse. (there was no package manager early on, thus many java developers aren't taught that way, even decades after Maven was created ... and for end-user products it makes sense to bundle)

johannes1234321 5y ago

as an example look at the log4j mess. "Everything" in the Java world needs log4j updates, but some dependecy's dependencies pull in some specific version. There you need the way to say "get the new version from 5 minutes ago" without waiting for all levels of the dependency hierachy. Especially as there were a bunch of emergency releases in short sequence and younhabe tonmake sure youbget zhe latest one. Dependencies are a mess. NIH can't be the solution either, though.

watwut 5y ago
You can ask for specific later fixed log4j version. You don't have to ask for unspecified latest one.
- acdha 5y ago
  This isn't the problem being discussed: when something like log4j happens, everyone in the world needs to update. The difference is if one of your dependencies pin 2.14.0, you either have to wait for that project to also ship an update or do something more complicated whereas if they specify less than version 3 you can immediately ship that patch. Something like log4j or many packages in the NPM world are so widely used that on any non-trivial project the odds approach certainty that multiple dependencies will specify versions. The more specific the pin, the more likely it is that you'll be unable to ship a security update without risk of a functional change or blocking incompatibility. You can mitigate that with good CI/CD infrastructure and lots of automated testing, but that means taking on more infrastructure expense.
  - zkldi 5y ago
    What if the patch for the buggy `2.14.0` library was released as `3.0.0`? In semver MAJOR can be a superset of MINOR and PATCH, so this is a perfectly logical semver operation. You still have the exact same problem you described with `^2.14.0`. Someone would have to manually update the package to get the security fix in 3.0.0. Unless you're suggesting code should also automatically update major versions aswell?
    - acdha 5y ago
      Yes, if someone chooses not to follow semver correctly they can create problems but there are a somewhat unlimited number of ways in which an untrustworthy maintainer can do that. The difference is that following semver means it's easy to not do that since they can always ship 2.<latest + 1> with no changes other than the security fix.
      - johannes1234321 5y ago
        > The difference is that following semver means it's easy to not do that since they can always ship 2.<latest + 1> with no changes other than the security fix. If the line between bug and feature were clear. (Log4j worked 100% as specified btw. in regards to log4shell) https://xkcd.com/1172/ https://xkcd.com/1172/
      - zkldi 5y ago
        This is following semver correctly. A PATCH update may be a MAJOR update (since its a superset) and it may be considered a breaking change.
  - watwut 5y ago
    You don't have to wait till that lib updates. You update version yourself and overwrite it. Second, log4j is bad examples. Libraries don't pin that at all and people report bug is they do. Libraries are supposed to depend on logging api in general and end project decides whether use log4j or slfj.
jonny_eh 5y ago
What if NPM allowed a "global minimum version" for any package found to have critical security vulnerability?
- johannes1234321 5y ago
  global for what? How much tracking of issues do I have to make? In an ideal world (which we can't have for multiple reasons) I get security fixes by default. (and no other breakage)
MattPalmer1086 5y ago
No, we really don't need a way to say get the last version from 5 minutes ago. We need to get the version that we tested with and know works, which is what it does. When we need to update, we say what version we want. Java can be a pain, but I'm very glad it doesn't handle dependencies like npm.
- acdha 5y ago
  This is also saying you can't easily update from 1.2.3 to 1.2.4 without all of your dependencies which specify 1.2.3 also being updated without having an override mechanism. This isn't a simple problem where one option has no downsides.
  - MattPalmer1086 5y ago
    Oh, I agree that there's no simple solution that solves everything. I'm still glad that basically noone else handles dependencies like npm.
    - remram 5y ago
      Everybody else handles dependencies like npm, e.g. installs the latest versions that satisfy constraints. Some package managers have the ability to install from a lock file (e.g. Python's Poetry, Python's Pipenv, Rust's Cargo, npm) but will still grab the latest version when the lockfile doesn't exists (e.g. cloned a project with no lock file, or just added the dependency yourself), and have a command to update which updates every single package to the latest compatible versions. You can argue that npm's commands are poorly named and guide users towards bad defaults, but saying that it works in a unique way is not true.
      - MattPalmer1086 5y ago
        I guess my experience is limited. For example, maven dependencies usually specify the exact version required in the pom files. At least, on all the projects I've ever dealt with.
cesarb 5y ago
> "Everything" in the Java world needs log4j updates, but some dependecy's dependencies pull in some specific version. There you need the way to say "get the new version from 5 minutes ago" without waiting for all levels of the dependency hierachy. At least with Maven, that's extremely simple. Just add to your project a dependency on that "new version from 5 minutes ago" of log4j. Maven always prefers the version from a direct dependency. You don't have to wait for "all levels of the dependency hierarchy" at all.
- kristjansson 5y ago
  The problem is that, AIUI, each NPM package installs its own, isolated set of dependencies. It has facilities to manage versions down in the dep tree, but it’s not as simple as other managers which ultimately install a single set of packages that satisfy all version constraints.
  - johannes1234321 5y ago
    many java jars contain other jars withbthe dependency, so users don't have to run maven or something like thst, but jsut grab the jar. This is even worse. (there was no package manager early on, thus many java developers aren't taught that way, even decades after Maven was created ... and for end-user products it makes sense to bundle)