> apologies for the previous short comment. > Jeez that reads harsh. Apologies, it's late. All good, friend. > ... It's really time to move on. But is it? I

> apologies for the previous short comment. > Jeez that reads harsh. Apologies, it's late. All good, friend. > ... It's really time to move on. But is it? I fear that if this is a genuine issue, why would I want to move on from it? Essentially npm is enabling people to build bridges in the same way steel is helping people to build actual bridges. If there was a flaw in some steel production process, I wouldn't ignore it. People could suffer. Extreme(?) examples a side, if it's an issue, why not aim to solve it? This seems to pop up a lot, so perhaps it's time for a (long-term) solution? > Use org modules/private modules and the problem is solved. Yes! This is where I personally see the long-term solution: pick your top-level deps, (permanently) cache them locally and validate them, then implement/use them. Only update the cache when you're confident the remote, official copy has been changed in a manner that's safe for you and or your users. > I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues. How do you know you've not had any issues? If I was attacking you via some sort of "side channel" attack, like breaching and injecting bad code into an NPM module I know you're using, how would you know it's happened? Are you using a CI/CD process? The changes are high that you are and therefore unless you've version/commit pinning, it's likely you're blind to those deps being updated during your build process, enabling me to perform said "side channel" attack. > No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved. If it's being regurgitated so much, perhaps it is a "real world" problem to be solved.