[rattray]

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.

[Sir_Cmpwn]

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

[Klathmon]

You are free to slow down as much as you want as a developer.

Why is there this call for all software development to slow down? As if the bad actors will also listen and just slow down trying to attack...

[Sir_Cmpwn]

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

[Klathmon]

Then don't follow it?

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.

[mcguire]

"...because the worst that will happen is..."

... your credentials, development environment, and anything you can access are compromised.

[Klathmon]

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!

[afarrell]

What data does the dashboard serve? Could you please post some of it here?

[Klathmon]

It's not public, but that's why it's a trade off.

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.

[Vinnl]

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

[Sir_Cmpwn]

I disagree. Most projects pull in an order of magnitude fewer dependencies than your average JavaScript project, if not even fewer.

[Vinnl]

Fewer than npm projects, absolutely. Few enough to be significantly less vulnerable to this attack - I don't think so.

[Sir_Cmpwn]

When was the last time you heard of a Debian package being compromised, for example?

[Klathmon]

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.

[Vinnl]

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.

[AgentME]

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.

[TAForObvReasons]

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

[Vinnl]

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.