So I can make a malicious module called expres and another one called expresss and screw with ppls machines?
This. I love that the Node community enjoys innovating for convenience, but ideas like this one are less than half-baked from a security perspective. Just make a few typo'd popular packages, and use npm install scripts [1] and you have a very easy remote code execution vector on developer workstations. The bigger problem I see is that npm is a circus. No package signing and a ridiculous debate on why that's been goin…
Show HN: Auto install npm dependencies as you code
31–40 of 80 posts
Re: Show HN: Auto install npm dependencies as you code
#32Very cool! The Webpack equivalent: https://github.com/ericclemmons/npm-install-webpack-plugin
Re: Show HN: Auto install npm dependencies as you code
#33I mean, wow. I've seen half-baked ideas before, but this takes the cake. Typos now equal remote code execution, and it's even easier to enter dependancy hell, because deps are now implicit.
Re: Show HN: Auto install npm dependencies as you code
#34Given that in npm v3 the order of installation determines where things are installed, this seems like it might cause some interesting bugs that never happen on the developer's machine. :)
Re: Show HN: Auto install npm dependencies as you code
#35Given that in npm v3 the order of installation determines where things are installed, this seems like it might cause some interesting bugs that never happen on the developer's machine. :)
Re: Show HN: Auto install npm dependencies as you code
#36I mean, wow. I've seen half-baked ideas before, but this takes the cake. Typos now equal remote code execution, and it's even easier to enter dependancy hell, because deps are now implicit.
Re: Show HN: Auto install npm dependencies as you code
#37Re: Show HN: Auto install npm dependencies as you code
#38Earlier quoted context omitted.
> It's not usually core, it's all the plugins by authors of unknown provenance and skill. This is otherwise known as an active developer community and is a good thing. In any open library ecosystem, it's ultimately up to the developer to carefully choose and vet third-party modules. There isn't any substitute for that. The alternative is a tightly controlled standard library, but that isn't npm's stated goal. Such a…
> The alternative is a tightly controlled standard library, but that isn't npm's stated goal. What npm says it is doing on paper and in its charter is not necessarily what npm gets used for. At this point in the ecosystem's maturity, npm developers are doing their users a massive disservice and opening them up to a lot of risk. Maintaining this line of a vibrant active community, and "developers should be responsible…
Re: Show HN: Auto install npm dependencies as you code
#39Earlier quoted context omitted.
> It's not usually core, it's all the plugins by authors of unknown provenance and skill. This is otherwise known as an active developer community and is a good thing. In any open library ecosystem, it's ultimately up to the developer to carefully choose and vet third-party modules. There isn't any substitute for that. The alternative is a tightly controlled standard library, but that isn't npm's stated goal. Such a…
> The alternative is a tightly controlled standard library, but that isn't npm's stated goal. What npm says it is doing on paper and in its charter is not necessarily what npm gets used for. At this point in the ecosystem's maturity, npm developers are doing their users a massive disservice and opening them up to a lot of risk. Maintaining this line of a vibrant active community, and "developers should be responsible…
I agree that npm has been a bit slow with a bunch of important features like package signing, sandboxing post-install scripts, etc. but as a counterpoint to the authoritativeness issue, I would argue that vetting and defining "authoritative" packages is a difficult problem. I'm not aware of any open/semi-open package ecosystem that has solved this problem (please do correct me if I'm wrong).
As an example in the JS world, which of lodash/ramda/underscore/functionaljs should be the/an authoritative javascript FP library? Should they all be marked authoritative? If so, what is the criteria for a new library to also be authoritative? What happens when a library is abandoned? How do you even define abandoned in an open ecosystem?
These are solvable problems, but not easy ones to reach consensus on.
The Redhat-like alternative is to have a central entity employ/pay contributors to audit and maintain libraries, but it's debatable whether npm would have grown to its current size with that model.
Re: Show HN: Auto install npm dependencies as you code
#40I mean, wow. I've seen half-baked ideas before, but this takes the cake. Typos now equal remote code execution, and it's even easier to enter dependancy hell, because deps are now implicit.
Typos with npm have always allowed RCE. You can have typos while doing $npm install ... .
With this, you have to be careful the WHOLE time you are typing. You normally don't worry about hitting return in your editor causing RCE.