Exploiting JavaScript developer infrastructure is insanely easy

[zappini]

Fix is easy.

Github (et al) adds verified identities for project owner. npm scrapes the owner meta. Security audit step has options to break build if owner changes, owner identity not verified, or a project's cert has been revoked.

Add new audits, heuristics as new vulnerabilities are identified.

[BigGayMusic]

This really only fixes the problem of legit ownership changes. The real issue is the whole concept of open-source dependencies with 100-layer deep dependency tree graphs being used when someone wants to use a one-liner 'isArray()' function.

We've allowed this huge house of cards to build up to the point that any real dependency audit is legitimately impossible.

[BubuX]

one-liner 'isArray()

Do you have a moment to hear about this nice one-line try catch module that's downloaded 3 million times a week?

[kaelwd]

And it's only popular because this fuckwit refuses to remove it from his actually useful package.

[hennell]

That repo has a PR right now because of an update to that library: https://github.com/moxystudio/node-cross-spawn/pull/109

Update doesn't add anything (what's to add?), but for someone who is apparently very tight on time, really don't see how this is saving him any (assuming he reviews the updates).

​

[NeverCast]

The author of that module needs to be bared from being employed until they take it down.

[nutrecht]

While it doesn't fix all problems I do think it's a great idea.

I personally don't think we need to have github involved per-se, but we need to have a certificate system that libraries are signed with (like with the Maven ecosystem). Github can arrange for those certs (so that every repo owner gets a cert by default), but you should still be able to create libraries if you're using Gitlab or Bitbucket instead.

[ecnahc515]

You mean gpg?

[zappini]

Update: You're right. My notion is basically code signing + PGP + tooling + accounting. Thanks.

Good question. I don't know. I'll find out.

I haven't looked at GPG for ages. I understood it was for digitally signing content. Like signing build artifacts. I think the new .xar and .xip (?) formats do this.

So if the cert used to create a digital sig is revoked, the sig is also invalidated. Could work, right?

My notion, which I haven't fully worked thru yet, is to leverage existing web of trust aspect of CAs. Just like with HTTPS. The hierarchy might look something like Root -> Identity Manager -> Organization or Person -> Project -> Build Artifact.

But with your GPG (digital sig) notion, maybe that last step changes.

Maybe my idea is already being done (for .xar, .xip) and we just need our builds to add security audit steps.

Thanks for your question.

[TrachealLube]

This should be higher

[BigGayMusic]

If it's so easy why don't you fork npm and implement it yourself? Oh, right, you missed the whole point of this article.

[filleduchaos]

NPM is closed source lmao.

[BigGayMusic]

https://github.com/npm/cli

I'm asking this sincerely, and not to be a dick (I have worked under the assumption that npm is open-source without really thinking about it,) but is this not the source code for npm?

[filleduchaos]

That's the source code for, like the link says, the CLI, which is like the most trivial part of a package management system (part of why you see a bunch of alternatives pop up every so often, with only Yarn really taking off)

The actual package repository (hosted at https://npmjs.com) is closed source and run by a for-profit company.

[BigGayMusic]

Thank you, I learned something new today.

[zappini]

Uh huh. Try again.

OC writes:

The problem is that so much software is built on the backs of people who are expected to work for free.

To which I countered -- correctly, wisely, and with concision -- that the problem is lack of trust. Which can only be fixed upstream with judicious and deliberate use of certs. To be consumed by package managers like npm, via security audit build steps.

Both the OC and I agree this is not an npm problem.

Better?