Today’s JavaScript trash fire and pile on
medium.com
medium.com
As the article says, I'm not convinced code signing would have made this not happen - given the distribution model you could trivially just have node library updates check to see whether the owner/maintainer had the same user name.
Similarly it is absolutely not the fault of the old maintainer - no one should have to commit to permanently supporting a library they wrote years in the past. And if you weren't maintaining a library why would you necessarily be opposed to transferring ownership over to someone who is at least apparently working on/with it?
I wouldn't want my name being forever attributed to something I stopped working on years ago. If I make a lib with my name on it it's my lib and my name's gotta stay on it forever. Feel free to clone it and do whatever you want with it, but this one should stay mine for no other reason than the one we're seeing today. Then link to the latest maintained fork in your README.
The alternative is changing the name (should libfoo.js become libfoo2.js? Libfoo-maintainer_name.js) etc.
Then all the libraries that depend on it have to change their deps and their actual code (require(x) or import x are both based on library name).
If they don’t then any libraries that transitively include the old version of the library could be compromised by any bugs that happen to be included in the old version, so you also can’t say “everyone who cares about the library should update” because library A may depend on library-B which isn’t updated.
If anything the problem here is that npm doesn’t have any real “the maintainer has changed” notification, and that’s couple with the average developer not having any way to know if that change is legitimately ok without auditing the published code.
If size/resource consumption is a concern, the library could be broken up and `import`ed as necessary now that modules are a thing. Whatever standards body that chooses to implement this wouldn't even need tot worry about breaking old code and name collisions, as it could all be opt-in.
On AWS, lock-down outgoing traffic. The Node instance (heaven help you if it's in a browser) on the back-end shouldn't be able to get out to anything, with the necessary exceptions of your codes back-end data store, and, perhaps temporarily, your deployment store.
There could be a concept of "trusted" packages. That have had at least a review step. So either your package is trivial and easily automated or difficult with manual review. Where the costs are absorbed is the thing.
In the end, I do feel that anything that's being published publicly should have publicly available source, and that the build should be repeatable at the least... that wouldn't prevent such a thing (if it was checked into git), but would at least make it harder to hide.
The attack was present in the minified JS, but not the source JS.
(I'm ignorant about NPM.) Does this mean on NPM, the publisher gets to publish the source AND the minified version? Is there no validation that the minified code is sourced from the true source code?
At least with paid software, in theory if not in practice, the organization publishing the software is responsible for verifying it, and for keeping track of whom it is employing to contribute to the code, so you can figure out who to lock up if they intentionally push malicious code.
I like to think of academic journal articles in that regard: the title neatly summarises the abstract (which itself summarises the article), so there's as little ambiguity as possible.
I have no opinion on the article either way, might just be something to sit at the back of one's head for next time. I get the feeling HN has two crowds: those who prefer newspaper-style articles and those who prefer academic journal-style articles. Difficult to find the happy medium (sic).
1. Detect commits that are radically different from previous ones in the same repo by some measure (tricky)
2. Detect npm publish events whose contents are different than source repo
3. Detect author/ownership changes in the context of npm packages
What else?
This would have the side effect of requiring likely paid exceptions for popular binary packages or those that have more complex build requirements. However, the vast majority of npm packages could probably be built via some form of template.
npm test - must have a configured script in package.json and must not error (this is easy enough to work around, but should be required)
npm run build - should be added as a required step, where the output to be packaged is outputted process.env.BUID_OUTPUT as a directory.
This would at the very least minimize some of the risks... signed commits could be an additional step, but coordination to make tooling for this easier to use would have to happen.
Also, ownership changes should have a FREEZE only allowing a new Major release after transfer of a package.
You must trust them not only to not be malicious, but not to have been compromised. How can there be an automated solution to this problem? The only solution is to develop some discipline around dependencies. Unfortunately the current culture around Node/NPM has gone in the opposite direction.
I mean in theory any npm package could have a payload that would hijack the machine or override other system functions, where is the security in any of that?!
In theory the same applies to PyPI or Rubygems or whatever else you use too, but it's the fact that JavaScript packaging culture has grown to have many, small "does one thing well" packages that makes it harder to be across those which you are giving trust to.