Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not use NPM 5.7

github.com

Post reply on HN
Print view View original

51–60 of 233 posts

Re: Do not use NPM 5.7

#51

Post by diggan »

reificator wrote: post #20
zaarn wrote: post #3

Excuse me, but what the fuck? Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I wan…

I completely agree with you. But in fairness, I can't count the number of times that I've needed to fix things after people treated `sudo npm` as Simon Says[1]. I'm sure they struggled a lot with that issue before coming to this solution. Was it the right solution? Absolutely not. But that's not the point I'm trying to make. It's all too easy to tunnel vision on a particular solution. I've done it plenty of times, an…

I don't remember exactly what tool does this, but one package manager (can be homebrew but long time ago I used homebrew) warns users if you are running it as root, since it should install packages as the user.

I think npm could implement a similar strategy and educate the users how packages should really be installed.

Re: Do not use NPM 5.7

#52

Post by breatheoften »

tbranyen wrote: post #31
foepys wrote: post #24

Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions. Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.

Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!

Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks.

Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.

Re: Do not use NPM 5.7

#53

Post by vetinari »

y4mi wrote: post #30
vetinari wrote: post #17

Earlier quoted context omitted.

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck…

Yes, I meant dpkg.

Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small steps to phase them out: https://www.youtube.com/watch?v=kE-8ZRISFqA

Re: Do not use NPM 5.7

#54

Post by dharmab »

diggan wrote: post #51
reificator wrote: post #20

Earlier quoted context omitted.

I completely agree with you. But in fairness, I can't count the number of times that I've needed to fix things after people treated `sudo npm` as Simon Says[1]. I'm sure they struggled a lot with that issue before coming to this solution. Was it the right solution? Absolutely not. But that's not the point I'm trying to make. It's all too easy to tunnel vision on a particular solution. I've done it plenty of times, an…

I don't remember exactly what tool does this, but one package manager (can be homebrew but long time ago I used homebrew) warns users if you are running it as root, since it should install packages as the user. I think npm could implement a similar strategy and educate the users how packages should really be installed.

Several Arch Linux AUR helpers (pacaur and trizen, for example) refuse to run as root. Instead, they invoke sudo to escalate only during the necessary phases.

Re: Do not use NPM 5.7

#55

Post by carussell »

foepys wrote: post #24

Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions. Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.

`sudo npm install -g` is one of several examples of the normalization of deviance rife in the NodeJS community. Most command-line utilities distributed through NPM recommend running as root (implicitly—because they all suggest installing it as a global package). Here's[1] Microsoft's instructions to install the TypeScript compiler, for example.

NPM's awfulness notwithstanding, it's trivial to write a shell script to do what you say and add a symlink to ~/bin. But everyone on StackOverflow will tell each other "just run it with sudo", and they do, and then quickly move on with their lives (presumably to be followed with "and break things"). Instead of doing the right thing, raising their hackles about how poorly NPM is designed, and holding its community leaders accountable.

1. https://github.com/Microsoft/TypeScript/blob/b29e0c9e3ab2471...

Re: Do not use NPM 5.7

#56

Post by vetinari »

Silhouette wrote: post #41
vetinari wrote: post #17

Earlier quoted context omitted.

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt? No, not really. For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. For ano…

> For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case.

There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do.

> For another thing, even packages installed with a distro's own package manager can typically dump whatever files they want wherever they want, rather than having the OS restrict them to a controlled environment.

The list of files in manifest is checked beforehand and if there's a conflict with existing package, the installation is aborted.

Re: Do not use NPM 5.7

#57

Post by mbrumlow »

jguimont wrote: post #33
jlgaddis wrote: post #25

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…

I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…

> 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 build server should produce a artifact that can then be deployed to your staging servers and if all is well THEN productions servers. npm is a build tool and should not be installed or ran on production servers -- for many reasons more than just stupid stuff like this.

Re: Do not use NPM 5.7

#58

Post by Piskvorrr »

floatboth wrote: post #29
Piskvorrr wrote: post #9

Earlier quoted context omitted.

And even worse, 5.6.0 to 5.7.0 is, by semver, one minor point release to another minor point release - no breaking changes, no major bugs. 5.7.0-pre would raise some flags.

Uhh. Does semver actually say anything about bugs ?! o_0

I'm pretty sure that "we're now changing permissions willy-nilly" is both a breaking change (which would warrant a major version bump, as per semver), and a bug (even though it's presented as an improvement by the authors). I should have been more clear.

Re: Do not use NPM 5.7

#59

Post by nolok »

jguimont wrote: post #33
jlgaddis wrote: post #25

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…

I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…

> It is not expected that updating npm will kill the complete system it is on... It would be expected to have some deploy failure of some sort.

"It is not expected that" is the definition of unexpected behavior, which is the very reason why we use staging servers. So your message is essentially "I didn't use a server meant to check for unexpected behavior, because I didn't expect that behavior to happen". Well, yeah, that's the point.

Also, I'm really not sure what your smiley is trying to convey here, and of all the possibilities I can't see one that's positive and contributive to the conversation. Really un-needed, please refrain from doing that.

Re: Do not use NPM 5.7

#60

Post by pm215 »

y4mi wrote: post #30
vetinari wrote: post #17

Earlier quoted context omitted.

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck…

dpkg won't allow one package to overwrite a file from another unless you pass it --force-overwrite, which is not the default.
Post reply on HN