Thread by @theefer

A few thoughts on the Node event-stream compromise:
[context: theregister.co.uk/2018/11/26/npm…]

Discussions seem to be overly focused on Dominic's role/responsibility, or the reliance on unpaid open source contributions, when the root is clearly a systemic issue with the Node ecosystem.

The nature of NPM is such that I'd expect most large corporate Node software to depend on at least a couple of single individuals' hobby projects. The problem is that those projects don't tend to fulfill the same expectations of security, quality and maintenance.

For example, the risk with individualistic modules is that maintainers move on, leaving their projects unattended. This is natural, since their motives for publishing them in the first place revolved around fun, sharing or personal promotion; not everlasting responsibility.

For that reason, the solution cannot be to pay hobbyists to maintain ad eternum some project they worked on in the past for fun and have since lost interest in. You cannot simply transform hobbyists hacking out of passion into obedient corporate workers by throwing money at them.

The security profile of such projects is also hard to trust. Corporate software usually goes through some form of peer review process, whereas with small single maintainer packages, there is little oversight of what goes into releases or who ownership is transferred to.

Even when the author is not malicious, the lack of cryptographic signing of packages (or mandatory 2FA) increases the risk of compromised code, e.g. by stealing the author's NPM credentials.

Some have argued that developers should be responsible for reviewing the code they depend on, but in practice, relying on large and deep dependency trees of small modules makes auditing practically infeasible, especially if code might be minified and obfuscated.

Besides tighter security around distribution, a case could also be made that imported code is granted more access to the system than necessary. The event-stream compromise showed how easy it is to obfuscate execution of arbitrary code in what looks like idiosyncratic Node code.

The convenience and flexibility of both the Node APIs and the JavaScript syntax make it very hard to statically analyze code for unwarranted operations (e.g. filesystem or network I/O); those are also impossible to restrict.

This is something Node creator Ryan Dahl highlighted in his JSConf EU 2018 talk as one of the design flaws in Node, and is attempting to fix in his new Deno project.

github.com/denoland/deno

But one of the most surprisingly unquestioned aspects of this discussion is the reliance on single-person projects, which would be seen as a serious risk (aka “bus factor”) in other contexts.

Unlike tiny & narrow modules, coarser, larger projects tend to make space for a community to form and share ownership, manage code reviews and keep each other accountable. They can also reduce the burden on authors and more smoothly transition ownership where necessary.

Perhaps it is time to transition from the micro-package approach and consolidate popular individualistic modules into larger-scoped community-led projects that would give stronger guarantees of security, quality and maintainability.