Live data from Hacker News

Do not use NPM 5.7

github.com

131–140 of 233 posts

Re: Do not use NPM 5.7

#131
post #102

Title should be changed to 5.7.0 as newly released 5.7.1 fixes the bug.

Maturely tagged with `#STOPUSINGPRERELEASESWITHSUDO`

When their Official Blog makes no mention of 5.7.0 being a prelease [0] and is semantically versioned as a stable release. The thread also later details that running `npm upgrade -g npm` instead of `npm install -g npm`will get 5.7.0 instead of 5.6.0 [1].

Is it standard practice for an `upgrade` command to pull a pre-release or beta? When I upgrade Firefox I don't get put onto the Nightly branch...

[0] https://vgy.me/LkvBKS.png

[1] https://github.com/npm/npm/issues/19883#issuecomment-3677268...

Re: Do not use NPM 5.7

#132
post #76

Earlier quoted context omitted.

dpkg will throw a fit in the same way.

it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about…

No, it will not install the package at all:

    $ mkdir root/bin/
    $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls
    $ chmod +x root/bin/ls
    $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root .
    Created package {:path=>"bad-ls_1.0_amd64.deb"}
    $ dpkg-deb -c bad-ls_1.0_amd64.deb
    drwxrwxr-x 0/0               0 2018-02-22 10:44 ./
    drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/
    drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/
    drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/doc/
    drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/doc/bad-ls/
    -rw-r--r-- 0/0             142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz
    drwxrwxr-x 0/0               0 2018-02-22 10:44 ./bin/
    -rwxrwxr-x 0/0              20 2018-02-22 10:42 ./bin/ls
    $ sudo dpkg -i bad-ls_1.0_amd64.deb
    Selecting previously unselected package bad-ls.
    (Reading database ... 837129 files and directories currently installed.)
    Preparing to unpack bad-ls_1.0_amd64.deb ...
    Unpacking bad-ls (1.0) ...
    dpkg: error processing archive bad-ls_1.0_amd64.deb (--install):
     trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1
    Errors were encountered while processing:
     bad-ls_1.0_amd64.deb
    $ ls -l /bin/ls
    -rwxr-xr-x 1 root root 134792 Oct  2 10:51 /bin/ls*
It doesn't just warn and leave things in a bad state.

Re: Do not use NPM 5.7

#133

Earlier quoted context omitted.

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

There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. Hence my "or otherwise bundled..." note. But you're still only thinking in terms of packages that are bundled and installed via the system tool. Anything not installed via that tool can typically do whatever it wants if its scripts run as root, and anything that is installed via tha…

This is governance issue.

Build all your software into packages appropriate for the OS you use and then put them in a company repo. Install from there.

If you're just dumping whatever "stuff" you want on a machine in whatever location with no control, you're gonna have a bad time.

Re: Do not use NPM 5.7

#134
post #38

Earlier quoted context omitted.

What strikes me as odd is that there are a lot of immature comments in that thread.

There is nothing odd about it. The JS community is today attracting most script kiddies. During the bubble, it was the same with PHP, and some of us were part of it. Youngsters must start to code somewhere.

I wish nobody will ever find the posts I’ve made on php.net as a teenager circa 2005

Re: Do not use NPM 5.7

#136

Why would reporter run sudo npm???

sudo yum sudo apt-get sudo pacman

Why wouldn't you naively assume sudo npm was safe if you wanted a global package (I know the behavior of npm...)

This is blaming the victims. If the user can blow their foot off, its not the users fault.

Re: Do not use NPM 5.7

#137
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…

Of course. Try running npm on a shared fs (fusehgfs). Most things don't work. This is just shit software and the people who make it need to concern themselves with fixing their software rather than trying to prevent imaginary security problems they shouldn't be trying to prevent anyway (I don't know what their security delusions are exactly, but I do know they are delusions). I'm an engineer and a sysadmin and I I know when something should be run as root or not. That should be my choice and my choice alone. I shouldn't be nagged about it and I certainly shouldn't be prevented. But this is npm. That's why people created yarn, I think.

Re: Do not use NPM 5.7

#138
Running npm as root is bad, either install the npm package from your distribution (apt, pacman...) or, to use `npm install -g` edit `.npmrc` add `prefix=/home//.node` in it, and add `~/.node/bin` to your path.

Re: Do not use NPM 5.7

#139
post #82

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…

What you say is 100% true, but I would go one step further and not have npm installed on any production server. And it's not specific to npm, I would do the same with gem, pip, cpan, etc. Not to mention curl http://ex.io/install.sh | sudo bash. Call me old school, but personally, I would avoid installing anything from language specific package managers. I would instead either build an rpm/deb package for every depend…

This is actually why I like working with C and Go. The compilers are on the build server and I just publish the resulting binary on a barebones production server after the build passes. In the past, working with Django, people always gave me shit for vendoring python package as part of the build, but it's to avoid having needlessly complex production environments and to remove the need for package managers.

Re: Do not use NPM 5.7

#140
post #131
post #102

Title should be changed to 5.7.0 as newly released 5.7.1 fixes the bug.

Maturely tagged with `#STOPUSINGPRERELEASESWITHSUDO` When their Official Blog makes no mention of 5.7.0 being a prelease [0] and is semantically versioned as a stable release. The thread also later details that running `npm upgrade -g npm` instead of `npm install -g npm`will get 5.7.0 instead of 5.6.0 [1]. Is it standard practice for an `upgrade` command to pull a pre-release or beta? When I upgrade Firefox I don't g…

This is relevant to the information I posted in my comment here how?

It is not.

Post reply on HN