The honest answer is a hard truth: you don't use npm at all. The npm ecosystem is out of control and beyond saving. I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is - trusted third-parties that independently audit and publish new packages.
Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.
1. You can protect against problems like "a subdependency's patch version automatically bumped to something bad" with a lockfile, either yarn.lock or package-lock.json. Of course, that doesn't help if you chose to update your lockfile in the handful of hours this attack was live.
2. It seems to me that, accordingly, a client-side command to only download packages/versions that have been live for more than n hours/days would decrease the likelihood of downloading malicious code substantially. The community is large and folks tend to find the bad stuff.
3. If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower.
4. We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can.
5. Yarn operates a mirror, and there are several CDN's with everything on npm - unpkg.com, cdn.jsdelivr.net/npm, bundle.run. Perhaps one of them will let you download everything for examination.
I wouldn't be surprised if NPM, Inc. would help you audit the rest of the ecosystem if you reached out.
>If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower.
So? The JavaScript community could stand to slow down a bit.
>We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can.
They might publish, but they certainly don't audit. Anyone can publish a package on npm in tens of seconds and it's immediately live for anyone to install. It's not even signed. This looks nothing like a Linux distro.
"Move fast and break things" leads to breaking things, it's a shitty and reckless attitude to take towards software development and it puts innocent and vulnerable users at risk.
Nobody is forcing you to, I'm building a tiny internal only dashboard right now, move fast and break things works great, because the worst that will happen is our tiny internal dashboard won't work... And spending a ton of time properly engineering and securing a dashboard will be mostly wasted time.
But when I'm working on a core application for the company, I slow down and take my time and actually engineer software.
I don't need all of software development to "slow down" to do that.
Yes, and anything that warrants higher security doesn't happen from a Dev machine, and isn't possible with just creds on a Dev machine.
They are horribly insecure by nature. They almost all have root, they download and install tons of software, they are often portable, and us developers aren't infallible and will eventually fuck up.
Systems that require better security won't rely on any one or even 2 dev systems, and yes that requires more time and effort, but it's better than the alternative of hoping all of your developers never make a single mistake.
It's not perfect, but if you have a perfectly secure system, I'd love to hear it!
I don't have a good solution, but I come from a time when, if a machine was compromised, you changed every one's security tokens and re-imaged the affected machines.
Yeah, I won't be broadcasting it publicly, but it would be stupid to spend hundreds of hours properly securing it and wasting countless hours making anyone that wants to access it jump through tons of hoops.
If there is something that starts processing data or is customer facing, then more work goes into securing and engineering it. If an outage would cause significant issues, more work goes into security and engineering. If it processes personal data, then even more work goes into security and engineering.
I'm honestly surprised this is something that most people don't agree with... Do you really advocate using the highest security and redundancy practices for even the smallest of front end projects?
I'm not advocating throwing all common sense out the window and just eval-ing anything and everything, just that a "move fast and break things" ethos has it's place, and can massively increase productivity in places where it's useful, and a "slow and safe" ethos can always be used when needed. Or anything inbetween.
> So? The JavaScript community could stand to slow down a bit.
It's not "a bit", and it's not just the Javascript community, unfortunately. Practically every software project pulls in heaps of unaudited third-party code.
Debian is different as they build all their own packages, as do most other OS package managers.
And that comes with significant cost. Not only money cost in that it's expensive to staff, maintain, and constantly work with authors to build their stuff, but also in terms of "lag".
OS packages are often months or longer behind current releases, and I'd argue that the difficulty of getting one's package into all the different systems is one of the reasons why language-specific package managers have grown so much.
If you feel that approach is useful, then feel free to implement or call for it's implementation on top of something like NPM. But don't call for all package managers to be as slow, cumbersome, difficult to use, and expensive as OS package managers are.
Just because it hasn't happened doesn't mean that slowing down would prevent it. There's plenty of reasons why certain projects could be a target and some others are not - the sheer size of the npm ecosystem could for example be an important factor.
That said, Debian is an interesting example, because they have indeed slowed down significantly (i.e. not "a bit") compared to e.g. Maven and npm, and have significant more manual checks. I do believe that that helps them a lot in being less vulnerable, but I also believe that that approach is far more viable for their use case than for e.g. Maven and npm.
Though on the other side, you have to judge how many libraries you want aren't in the Debian repositories, how much effort it takes to publish something into the Debian repositories, and how completely out of date many things in them are.
The JS community encourages micromodules and leveraging NPM to a fault. We saw that with left-pad years ago, where such a basic function was used all over the place even though it was highly inefficient. That is a testament to how little people actually check their dependencies and just assume others vetted open source code
The npm ecosystem is the "worst" in this regard, definitely, but it would be foolhardy to assume that this is not likely to happen to you just because you're not using Javascript, or that slowing down to the level of other ecosystems would prevent this from happening to npm.
Come to think about it, if you're not a fan of the paucity of public mirrors evinced by the first link, you could use the second one to do something significant toward improving that situation. But I grant it's easier merely to criticize.
"Yudkowsky's Law of Continued Failure says that if they're dumb enough to do X, they're dumb enough to go on doing X after the next stimulus." In this latest saga of NPM-related fail, it's just another stimulus, so don't expect anything to happen that might address the underlying problems of the ecosystem.
I did say it was about Node, not NPM, but you're right on the article quality too. I even used Node after reading that post..and liked it. But actually I was wrong to even associate it with Zed's post, since Zed's post is mainly about the community and not about the technology. I inferred the call for a similar post on NPM to be technology related and pattern matched on the wrong dimension of "poorly received ranty criticism" entirely! Oh well.
And risk getting pilloried by the community for being divisive? Or worse, for triggering someone?
Zed has taken a way-out-of-proportion amount of heat (and mostly people just trying to bait him) from people for his confrontational style. Even then, the social climate is much less receptive to that sort of thing now than it was then.
Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.