Live data from Hacker News

Show HN: Auto install npm dependencies as you code

npmjs.com

31–40 of 80 posts

Re: Show HN: Auto install npm dependencies as you code

#31
post #4

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…

Thank you, I knew I wasn't the only who thought this.

Re: Show HN: Auto install npm dependencies as you code

#33

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

Re: Show HN: Auto install npm dependencies as you code

#36

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

Indeed. If there's one thing we learned about node dependencies this year it's that nothing can go wrong if you take dependencies without thinking about them.

Re: Show HN: Auto install npm dependencies as you code

#38
post #13

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

It's taboo in npm culture (as in, the actual npm employees) to stop anyone at the gate. In fact, they actively encourage experiments of all kinds into it.

Re: Show HN: Auto install npm dependencies as you code

#39
post #13

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

> As I see it, npm appears to be acting like there are a lot of unsolved problems in this realm, and in doing so are endangering a developer community that is absolutely full of amateurs. > The problem with npm is that the cost of entry of your "cool stuff" into the hands of a thousand trusting others is too low; there is no delineation between what is authoritative and what isn't.

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

#40

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

Right, but when you are running npm install you know you are installing and so you know you should be careful, and only hit return if you are sure it is right.

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.

Post reply on HN