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

41–50 of 233 posts

Re: Do not use NPM 5.7

#41

Post by Silhouette »

vetinari wrote: post #17
Silhouette wrote: post #7

Earlier quoted context omitted.

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…

> 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 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.

Re: Do not use NPM 5.7

#42

Post by joshmanders »

abritinthebay wrote: post #23
mkj wrote: post #6

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

Yup, but HN didn’t freak out over that. So most people probably won’t have heard about it.

While it is a pretty big issue, maybe people didn't freak out about it because it was from a new codebase, which was fixed in under 2 months. Meanwhile npm, Inc and their CLI dev team have 2+ year outstanding issues regarding the core functionality of their product not working correctly. Installing.

Re: Do not use NPM 5.7

#43

Post by zaarn »

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 think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states.

Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder. If npm blows up that way it doesn't murder the entire system, you'll still be able to SSH in. (That is unless you use a SSH agent based on node.js in which case; "why?")

Once npm has implemented such a location it should refuse to run with sudo and demand the user setup the correct permissions within the node folder (maybe setup a group "npm-manage" during install?)

Re: Do not use NPM 5.7

#44

Post by diggan »

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…

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.

Re: Do not use NPM 5.7

#45

Post by dagmx »

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…

But you should have still tried it on the Staging server to begin with.

That's the responsible method. The fact that you'd have to rebuild your staging server is exactly why you should have tested it there.

Sure NPM shouldn't have broken this but any number of things can cause issues during deployment and it's your job to check for them before pushing it out

Re: Do not use NPM 5.7

#46

Post by code_duck »

jlgaddis wrote: post #28
boffinism wrote: post #21

Good lord, when I try to follow the link I get the Unicorn error page with the message 'This page is taking way too long to load. Sorry about that. Please try refreshing and contact us if the problem persists.' Has this issue provoked so much outrage that GitHub can't handle the constant stream of angry emojis on the issue comment thread?

Log out of Github and then reload the page. WFM.

Does not work for me and I am not logged into github.

Re: Do not use NPM 5.7

#47

Post by jlgaddis »

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...

I don't disagree with you at all on that. The reality is, however, that sometimes "shit happens".

I'm more of a sysadmin than a developer and I learned many, many years ago that even the smallest little updates can "go wrong" and take the rest of the system with it. After getting burned a few times, even a baby will learn to stop touching a hot stove.

> 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 whole server there too.

Yes, but in that case your production servers would still be humming along just fine, no?

Re: Do not use NPM 5.7

#48

Post by woah »

grahamj wrote: post #8
btown wrote: post #5

There appear to be no unit tests for their entire lib/utils folder. Which includes things like this (misguided) chown utility. https://github.com/npm/npm/tree/release-next/test - and note the lack of testing in the commit linked in the bug report. I had an inkling that NPM was cancer, but not like this. Yarn, by contrast, has everything you would expect of a Facebook-engineered library: https://github.com/yarnpkg/yar…

"everything you would expect of a Facebook-engineered library" So it collects your personal information, even when not using it, and uses it for profit?

I don’t like Facebook much, but their engineering is very good

Re: Do not use NPM 5.7

#49

Post by tbranyen »

diggan wrote: post #36
tbranyen wrote: post #31

Earlier quoted context omitted.

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!

npm should never interact with hardware, it's job is to install and manage packages. I could understand that you have to run nodejs with root, since it actually can use the hardware. But using npm with root user? I can't think of a single usecase.

Well think harder. Npm runs scripts from package.json. Most folks wouldn't think twice to run sudo npm start as a replacement for sudo node. I sure wouldn't think npm would start mucking with file permissions.

Re: Do not use NPM 5.7

#50

Post by romanovcode »

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 you don't release pre-release versions without -pre or -beta or -rc tags in the end.
Post reply on HN