Do not use NPM 5.7

- One size fits all, (clients can only run one language, JS, so it has to fit many use cases).

- Popular (JS seems to be the most popular language at the moment, having beaten Java on most scales in the past year).

- Not owned by a corporation, (whilst probably a good thing, this does lead to "design by committee" issues.

- Backwards compatible (in all this time, only a minimal amount of breaking changes).

I don't know whether you're genuinely missing my point or just trolling, but this doesn't seem to be a very productive discussion so this will be my last comment here.

Your argument seems akin to saying that you could choose to install only open source software, and to personally audit every line of code in that software including all its dependencies, so if you don't do that then it's your own fault if something bad happens. If you're both a world class programmer and a security expert, and yet bizarrely you have ample free time available and nothing better to do with it, that might work. In the real world, it's totally impractical, and a much better solution is to operate according to the principle of least privilege, enforced at the level of the OS, without having to rely on conventions and/or good will.

If you want for a modern OS to enforce mandatory restriction on all installed software, modify your sudoers file to only allow to run rpm/yum or dpkg/apt. Because packages installed via these mean fulfil the conditions that you describe.

No, they don't, as I've repeatedly tried to explain. At best, even if packages are available and properly constructed, your method keeps track of where files go and can remove them again afterwards. It doesn't enforce any systematic use of the filesystem to contain packages within specific areas; it doesn't manage related issues like configuration files that you might want to back up or preserve across software changes; it doesn't restrict access to files, networking or other system resources that the software has no business touching; it doesn't scale to the many-small-dependencies model prevalent with tools like NPM; and at this point there are already so many fundamental problems with basic robustness and security that anything else is probably moot anyway.

I leave you with a question, which brings us back to where we came in. Given that this broken version of npm exists and that it was made available via at least one production channel that should not have included it as a result of presumed human error by the maintainers, how would anything material have changed today if people had been installing it via an official package and their package manager as you suggest, rather than via npm update?

Many places where my most important private data is stored (keychain for example) are not accessible without privilege escalation by processes running with my uid.

There of course local root exploits that exist and plenty of holes — but for many information stores on the system, I definitely want there to be an additional privilege escalation requirement for any semi-trusted code I choose to run ... furthermore overtime I want more of these personal information sources stored in a way that requires escalation — and I definitely am not going to defeat any of these future advancements prior to their release by running code with maximum system privilege for the sake of the defeatism of a previous age ... also it’s ridiculous to suggest that I am better off running untrusted code with more privileges than less — giving untrusted code maximum privileges makes everything about trying to be as practically secure as I can manage orders of magnitude harder. Running semi-trusted code with maximum privileges makes it even easier for the nefarious code to exploit me in ways I will never detect — simply by leaving more of the easy-to-write hard-to-detect exploit vectors completely unimpeded.

What is the difference between an unstable and a stable version? Testing by users. So as soon as enough users have tested / enough time has passed without issues, an unstable release becomes stable. In the best case nothing about the code needs to change, the release just needs to be promoted to the stable channel / dist-tag. That is pretty common practice for a lot of software and especially packages on npm.

With dist-tags, you can still make the versions meaningful. Between unstable versions, you can still express in semver terms what type of release it is (patch/minor/major). In classic prereleases, that is not possible. There is no semantic relationship expressed between a -alpha.1 and -alpha.2. Was it a bugfix? Does it add a feature? You don't know.

The issue is that npm did not mention in their blog post that 5.7 was released on the unstable `next` channel. The issue is not release channels in general.

[0] https://disjoint.ca/til/2017/11/10/managing-package-dependen...