91–100 of 138 posts
Just 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.
> 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…
That's not NPM's fault, its the fault of the way you deploy code. Even if you locked down a version, git is mutable so someone could change their code. That's why I "rsync" the code to production, so I know its the same as development.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world. Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric ke…
On update, can you send email to the purported author, telling them they've updated the package? (Similar to those "you have logged into some site from a new computer" emails.) An easy way to undo a publish would also be useful.
> 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…
Being a programmer you may, of course, try to automate that verification process with something like greenkeeper.io. That opens up its own kind of exploit opportunities.
Unless 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…
Take Maven as an example: it's not vulnerable to this attack for several reasons: 1) No install scripts. Fetching a dependency in NPM will execute arbitrary code. Fetching a dependency in Maven doesn't execute any code from the dependency. Obviously when I run my project, I'm expecting to call code in that dependency, so this is a mitigation not a complete fix. But that does lead on to the next point. Corollary: You…
A better fix to this issue is to require publishers to enter a two-factor token, to email them to confirm publishing, or the like.
Yeah, it makes everyone a bit uneasy with how much trust is involved in the ecosystem. Is there a better solution?
Earlier quoted context omitted.
As a developer in the node ecosystem, you run npm install multiple times a day. If one of the dependency you require has been infected, it will look for all the packages you own on npm and will publish a new infected version. Now any time another developer that has one of your packages as dependencies does npm install, it will infect that person again. Once it reaches a package like left-pad that is used by a ton of…
Solution: 1) Pin your packages to a specific version. If you aren't doing this already they you are in for a world of hurt when someone who doesn't know what they are doing releases a breaking package change on a minor version number. 2) Shrinkwrap your packages. Once again if you aren't already doing this then you npm install will probably break about once per three months when someone pushes a bad package to NPM. 3…
I prefer sticking to curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence. I get security updates, bug fixes, far fewer breaking changes, regular updates, reasonable assurance that code works together, and lower risk.
NPM has a lot to learn.
Earlier quoted context omitted.
What solution can we propose?
NPM could take a few actions. The original disclosure PDF[1] suggests these: ● Automatically expire login tokens ● Require 2 factor auth for publish operations ● Help users be logged out during install operations vjeux mentioned a few others on HN a few days back[2]: ● pre-install/post-install scripts should require user to accept or refuse. ● make shrinkwrap by default (and fix all the issues with it) so that runnin…
Unfortunately this wouldn't fix the issue. A malicious package could simply require() a JS script that does the same thing upon its first require(). There's no dependency on postinstall hooks for this worm to spread. Presumably, if you're installing packages, you intend to run them.
Earlier quoted context omitted.
NPM could take a few actions. The original disclosure PDF[1] suggests these: ● Automatically expire login tokens ● Require 2 factor auth for publish operations ● Help users be logged out during install operations vjeux mentioned a few others on HN a few days back[2]: ● pre-install/post-install scripts should require user to accept or refuse. ● make shrinkwrap by default (and fix all the issues with it) so that runnin…
It's definitely a nuanced issue. > ● Automatically expire login tokens I don't see how this helps the issue at hand; a worm could spread very quickly, requiring just a single publish from each freshly infected user. > ● Require 2 factor auth for publish operations This seems very reasonable, and the easiest to implement. It also has the nice effect of being a captcha to the publish operation, which gives it some of t…
Can you elaborate?