Just to share, there is an issue about uglifyjs https://github.com/mishoo/UglifyJS2/issues/936
Vulnerability #319816 – npm fails to restrict the actions of malicious packages
61–70 of 138 posts
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#62Just to share, there is an issue about uglifyjs https://github.com/mishoo/UglifyJS2/issues/936
The uglify authors should use 'uglify' per the naming conventions and can easily reserve uglify-js and uglifyjs as empty / legacy packages.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#63Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…
[deleted]
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#64Earlier quoted context omitted.
shrinkwrap might work for a bit. but if you regenerate the file you will run into the same issue. a way to protect you 100% against the problem is to define your dependency as a link to a specific commit or tarball.
Or a specific version since they can't be written to twice in the npm repo.
According to https://news.ycombinator.com/item?id=11341142 , in at least one case, now, this is not true.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#65> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…
When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…
I'm not trying to dispute that a problem exists, only that semver is a red herring here. It seems like the problem that you describe doesn't have to do with semver, rather that it has to do with npm lacking something like lockfiles.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#66Earlier quoted context omitted.
Or a specific version since they can't be written to twice in the npm repo.
According to https://news.ycombinator.com/item?id=11341142 , in at least one case, now, this is not true.
Except the exact same code was republished, so the point still stands.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#67Earlier quoted context omitted.
When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…
I'm not trying to dispute that a problem exists, only that semver is a red herring here. It seems like the problem that you describe doesn't have to do with semver, rather that it has to do with npm lacking something like lockfiles.
> npm lacking something like lockfiles
`npm shrinkwrap --dev` will give you a shrinkwrap file, with dev-deps also locked. Still, it took me 3 months of heavy Node usage before I found that out. Over in PHP land, while Composer has its own set of faults, it's at least generating a lockfile automatically.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#68Earlier quoted context omitted.
When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…
I'm not trying to dispute that a problem exists, only that semver is a red herring here. It seems like the problem that you describe doesn't have to do with semver, rather that it has to do with npm lacking something like lockfiles.
It is semver compounded with the "^x.y.z" version requirements for dependencies that NPM uses as a default when a package author `npm install --save` something.
When someone else installs that package it will bump y or z if `x > 0`, and z if `x == 0 && y > 0` for all dependencies.
You can manually freeze deps to 'x.y.z'.
The main problem is the "^" default.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#69> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…
When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…
I mean, don't use `npm install --save` then. I'm not really sure why people started using it in the first place, it's such a lazy thing to do. Instead, add it to your package.json yourself with the exact specific version you want (none of the ^a.b.c funny business).
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#70Earlier quoted context omitted.
Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea. The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.
the problem with relying on chroot is that (AFAIK) it might not be available on all platforms supported by the language-specific package managers.
The new Docker runs on Microsoft Hyper-V and on Mac's equivalent. So that would actually be a solution.