Re:What NPM should do to stop a new colors attack
by zkldi on Monday January 10, 2022 @06:41PM
(#29884764)
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?
Re:What NPM should do to stop a new colors attack
by acdha on Monday January 10, 2022 @07:02PM
(#29885024)
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.
Re:What NPM should do to stop a new colors attack
by zkldi on Monday January 10, 2022 @09:14PM
(#29886379)
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.
Re:What NPM should do to stop a new colors attack
by johannes1234321 on Monday January 10, 2022 @07:17PM
(#29885193)
> 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)
Re:What NPM should do to stop a new colors attack
by watwut on Tuesday January 11, 2022 @01:23AM
(#29888242)
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.
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.