4 ms·

The community discussion is focused on the wrong thing. Here is the problem: https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-

The community discussion is focused on the wrong thing. Here is the problem: https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream Look at that URL. It has "dominictarr" in it. Now click on the URL. Look at the big "dominictarr/event-stream" in the upper left of the screen. Many are going to conclude that this package belongs to dominictarr. Almost everything in the UI indicates this. Developers don't trust code, they trust people and organizations. NPM and Github needs to make it very clear when ownership has changed. And needs defaults that properly inform all users when ownership has changed. For example, when I SSH into a server the first time, it asks if I trust the key. Then one day, what if it asks again? Then I can stop and investigate why the key has changed, what's going on, and if I should trust it again. With the current NPM/Github there's no warning to users. A developer could've checked dominictarr's background and decide they are trustworthy, which would then extend to event-stream as well. But where's the warning to users when ownership of event-stream has changed and they need to re-evaluate whether to trust the new owner? And why does it look like the project still belongs to dominictarr when it actually doesn't? Those are the key issues here.

trickstra 8y ago
> Developers don't trust code, they trust people well the code doesn't write itself, so partially true. But ultimately it's about accountability. If Dominic himself added the backdoor, his presence in the community would end that day. If an anonymous alias does that, we don't even know who to blame. Dominic's fault is not the backdoor, but the irresponsibility of handing over a used package to an anonymous alias. Not being clear about the fact that the package is abandoned. I wouldn't depend on an abandoned package, if I knew that.
- QuantumGood 8y ago
  > Not being clear about the fact that the package is abandoned This is really the key point here.
always_good 8y ago
The NPM organization could go much further to make these attacks harder. You pitch a really good one: Any time you npm update/install, display ownership changes (especially compared to your prev version). Another one is to show the source code on the NPM website itself instead of hiding it in a tarball. NPM basically trains people to assume the published code == the code at the linked repository. It's a hacky honor system that only helps attackers.
- WorldMaker 8y ago
  Another easy suggestion is that NPM could have forced a semver major change on the new maintainer. It would have been an easy signal for people to check what changed, and fewer developers would have accidentally installed the infected version because it was only a "minor" change.

trickstra 8y ago

> Developers don't trust code, they trust people well the code doesn't write itself, so partially true. But ultimately it's about accountability. If Dominic himself added the backdoor, his presence in the community would end that day. If an anonymous alias does that, we don't even know who to blame. Dominic's fault is not the backdoor, but the irresponsibility of handing over a used package to an anonymous alias. Not being clear about the fact that the package is abandoned. I wouldn't depend on an abandoned package, if I knew that.

QuantumGood 8y ago
> Not being clear about the fact that the package is abandoned This is really the key point here.

always_good 8y ago

The NPM organization could go much further to make these attacks harder. You pitch a really good one: Any time you npm update/install, display ownership changes (especially compared to your prev version). Another one is to show the source code on the NPM website itself instead of hiding it in a tarball. NPM basically trains people to assume the published code == the code at the linked repository. It's a hacky honor system that only helps attackers.

WorldMaker 8y ago
Another easy suggestion is that NPM could have forced a semver major change on the new maintainer. It would have been an easy signal for people to check what changed, and fewer developers would have accidentally installed the infected version because it was only a "minor" change.