Live data from Hacker News

Do not use NPM 5.7

github.com

111–120 of 233 posts

Re: Do not use NPM 5.7

#111
post #106

Earlier quoted context omitted.

How is this different than running apt or yum or pacman or most other package managers as sudo? Somebody has to install system software.

npm is not for managing system software and has not been developed as such. It's a javascript package manager. apt and pacman (and probably yum but never used so can't speak about it) have active maintainers for most packages and the mirrors are well taken care of. npm is basically a giant array that anyone can add package to. I'm using them both accordingly.

I believe that node is installed with npm and both are installed in system directories. I think they should by default point the npm global directory to the user dir and not a system dir.

Re: Do not use NPM 5.7

#112

Earlier quoted context omitted.

> It is not expected that updating npm will kill the complete system it is on... Yeah, but that is why you test your deployments BEFORE deploying them. Hell would be had had any developer at my company ran any such command on a production sever. The notion of even running a command at the terminal on a production server is even scary. Things like should be done on build servers which are in general throwaway. Your bu…

This response annoys me, because it's essentially victim-blaming. Yes, ideally you have some automation and staging in your server setup. We're grown-ups. We understand this. But it ignores many other dangerous possibilities here. Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply doesn't have the resources and/o…

I'm not sure that reviewing what went wrong and how to prevent that in the future is victim-blaming. Problems happen, and sometimes you need to change the way you do things to prevent problems in the future. Victim-blaming would be telling a victim to change when they really shouldn't need to. It's always a trade-off between security and usability, and in the case of the OP, he should have leaned more towards security. Did OP cause this? No, but OP could have prevented this. Is that victim-blaming? I don't think so.

>[T]hat doesn't really address the fundamental problem.

The fundamental problem of human error is unfixable. Human error can be mitigated through more robust systems, such as separate staging and production environments. Is encouraging more robust protection victim-blaming? I don't think that it is.

Re: Do not use NPM 5.7

#113

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

That situation can be easily fixed in RPM-based Linux with rpm --setperms and rpm --setugids.

Correction will be little harder on Debian derivatives and whole incident can be completely prevented on Solaris with file-mac-profile.

Re: Do not use NPM 5.7

#114
post #106

Earlier quoted context omitted.

npm is not for managing system software and has not been developed as such. It's a javascript package manager. apt and pacman (and probably yum but never used so can't speak about it) have active maintainers for most packages and the mirrors are well taken care of. npm is basically a giant array that anyone can add package to. I'm using them both accordingly.

I believe that node is installed with npm and both are installed in system directories. I think they should by default point the npm global directory to the user dir and not a system dir.

Depends on how you install them, think that's how the default install works but nvm (which I use) puts everything under user directories. Agree with your thinking though, should be changed in the default install for sure.

Re: Do not use NPM 5.7

#115
post #44

Earlier quoted context omitted.

The real fix is to not run npm with sudo. Why would you do that in the first place? npm runs install-scripts when you fetch packages, so you basically open up root access for all the packages you download.

This 1000 times. Running npm as sudo is a terrible terrible idea. I remember creating a slack channel in our team called 'never run npm with sudo' and ranting in dramatic fashion to try and overcome the effect of the printed advice which npm used to output in most failure situations to 'try re-running the command with sudo.' This tended to cause developers new to the ecosystem to re-run the command with sudo and crea…

True, but then npm can theoretically still e.g. install a keyboard logger for the current user, so you should remember to never run sudo as that user again. Of course, that's doable, but probably too much to ask from most users.

Re: Do not use NPM 5.7

#116
post #106

Earlier quoted context omitted.

How is this different than running apt or yum or pacman or most other package managers as sudo? Somebody has to install system software.

npm is not for managing system software and has not been developed as such. It's a javascript package manager. apt and pacman (and probably yum but never used so can't speak about it) have active maintainers for most packages and the mirrors are well taken care of. npm is basically a giant array that anyone can add package to. I'm using them both accordingly.

> npm is not for managing system software

Debatable but irrelevant.

I'm not saying npm is a good or bad system package manager, just that running arbitrary scripts for requested packages and their dependencies is hardly unique.

It's oblivious to single out npm as a package manager that allows you to be pwned by packages in whatever repo you pull from.

Re: Do not use NPM 5.7

#118
post #105

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

If he'd tested it beforehand the comment might instead be "this destroyed my laptop". You have a responsibility to test before releasing to production, yes. But the amount of fucked up your program has to be for `sudo ___ --help` to wreck the operating system, the unexpectedness of that result... IMO attention should be focused here on the irresponsibility of the npm team, not their users.

The fact that --help can actually DO something makes me quite upset.

That means npm is causing side effects even before reading what the user wants, or is blatantly ignoring the user's request

Re: Do not use NPM 5.7

#119

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

To play devil's advocate, this was a dev version, without any UA or E2E testing, tagged as a major release. This after there have been major bugs for several releases. This isn't 0.7.0.

Perhaps the problem is that the stability of the world's fastest growing development platform hangs on the implementation of best practices by a two person developer team.

NPM needs to step up its game or we need to make something like yarn the standard.

Re: Do not use NPM 5.7

#120
post #6

Reminds me of a recent Yarn problem, overwriting which(1). https://github.com/yarnpkg/yarn/issues/4205

Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model. Installing software where your options are 1. running as a regular user, and the install script can put whatever it wants within your user's directories or 2. running as root, and the install script can do literally anything to anywhere on your system is not fit for purpose, when…

Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model.

I agree. For instance, on recent macOS versions you cannot modify most system directories as root, unless System Integrity Protection (SIP) is enabled [1]. SIP can only be disabled by the user by booting into the recovery OS. Just making these directories read-only prevent accidents and malice.

AFAIK in Fedora Atomic Host/Server some system directories are also read-only [2]. Moreover, Fedora Atomic uses OSTree as a content-addressed object store, similarly to git, where the current filesystem is just a 'checkout'. So, you can do transactional rollbacks, upgrades, etc.

[1] https://support.apple.com/en-us/HT204899

[2] https://rpm-ostree.readthedocs.io/en/latest/manual/administr...

Post reply on HN