loading...

ESLint and the Problem with NPM

Derek Kuhnert on July 12, 2018

The Situation Today, the ESLint package for NPM was compromised. In short, a publisher for that package had his account hijacked, and a ... [Read Full]
markdown guide
 

This is one of the more interesting reads on this general topic:

hackernoon.com/im-harvesting-credi...

 

I immediately though of that article. It's an awesome story everyone using NPM should read.

 

I’d say on pure quality of story-telling, everyone in tech should read this.

 

I agree with the concern you bring up, but I object to the tone you're using to describe the NPM team here.

As it happens, I personally know one of the NPM developers and was at a meetup with him yesterday. It was a bad day for him and his team.

Statements like " they really just care about pushing the issue under the rug asap." paint that team in a very unfair light.

Let's concentrate more on the behaviors and things you'd like to change, and speculate less on the other parties' motivations for those behaviors, which we're generally not privy to.

 

Statements like " they really just care about pushing the issue under the rug asap." paint that team in a very unfair light.

It may not be how they intend to act or how they usually deal with problems, but in this case that's the impression that they gave to casual consumers.
I agree that we should help to improve things instead of just criticizing, but the team should've also given more thought to the post-issues that would arise from their solutions instead of just marking everything as "solved".

 

It's also totally unrealistic for a user of npm developing a mid size app to manually inspect the source of hundreds or thousands of packages installed with npm or yarn.

There has to be an alternative approach to fix this at the source

 

I personally think there is a serious attitude issue in the JS community where "don't reinvent the wheel" is taken to extremes.

The fact that you pull in a framework plus some libraries to deal with common-but-complex stuff like date/time calculations or authorization is reasonable.

But JS developers seem to belong in the "special kind of lazy" group, where packages are used for every little thing. Depending on other developers (strangers!) saves time, but comes at the cost of decreased stability and security.

Of course, NPM should also increase security by using package signing, asking for 2FA when publishing a new version of a package, and possibly working on some heuristics to flag packages for review.

 

this would be a valid point, if the issue didn’t originate in a package that is essentially used by all serious javascript developers. this isn’t the pad-left incident, this is a major package being compromised. i don’t think laziness motivates any developer to install ESLint in the first place.

thanks for the clarification Pedro!

 

It's really complex problem hard to address.

In my opinion, it all come down to everyone responsibility. You have to check the stability of your direct dependencies and correct if need be.

After all, the eslint event was pretty well handled.
About 1h for someone to notice the virus, and 4h for eslint to publish a new version en even less for user to take down the pastebin. All potentially stolen tokens quickly revoked.
That the power of OOS.

ps: there's a 2FA option on NPM and every maintainers should activate it.

In my opinion, it all come down to everyone responsibility. You have to check the stability of your direct dependencies and correct if need be.

Tooling should help though. npm-audit goes in the right direction

Hum yes, but it only warn for know issues. Which is good, but lack the human inspection for new vulnerabilities.

yeah sure, it can't warn for something that's unknown.

Maybe in the future we'll have AI that can help with this sort of things, in the meantime we just need to do better.

 

I agree Orian, it's a mixture of issues. The one that's probably easiest to solve is to increase the baseline security for accounts (with 2FA) and add package signing.

The other is a cultural/attitude issue that's even glorified by some in the JS community which I don't understand. I know it's also due to the lack of a real standard library but having packages whose only purpose is to return the first element of an array is kind of ludicrous in my opinion :-)

So, basically a helper for this??
myArray[0];

There a few checks and you can decide how many items to return bit yeah.

Also if that's the case then npm should make an easy to use tool that can sign your package

 

This makes complete sense. What is npm's argument?

 

That is partially safe as the attacker could also choose to paste the contents of the ~/.ssh/ folder and steal your keys.

eval is evil

code of conduct - report abuse