Hey internet,
Here is my statement on the event-stream issue: gist.github.com/dominictarr/9f
Thanks to everyone who sent me friendly emoji ;) I'm okay. But this is really a much bigger issue (the viability of open source). I'm glad that this incidence is raising awareness!
Conversation
Replying to
It's incredible to me the amount of baseless praise you're getting for putting so many people at risk of getting pwnd. Of course, much of it is to be expected for Twitter. You messed up, and you should realize you messed up and apologize. Simple as. Nothing praise worthy here.
3
1
1
Replying to
I will apologize for giving away event-stream if you apologize for not volunteering to maintain it. really could have used your help there @PaulHBrittain
1
15
Replying to
It does not need to be maintained. You could mark it as unmaintained and leave it as-is. If someone wanted to maintain it they can fork it and put it up on NPM themselves. No need to give away NPM publish rights on your package. How do you not understand this?
2
So what happens if an abandoned, widely used project has a serious security vulnerability and there's no maintainer to address it? I think the bar should have been higher for transferring control to someone else but the attacker seems determined enough to pass the usual vetting.
1
They did maintenance and implemented a previously requested feature with an appropriate library, where they hid the backdoor. They could have contributed first to build trust if needed. Few projects do much vetting of contributors before entrusting them with commit access, etc.
1
It does appear a significant portion of the npm community applies a much lower bar than I'm used to for giving out commit access or turning over maintainership. However, the usual criteria is just that people contributed useful changes for a while and appear decent and competent.
1
I don't think the vast majority of community projects have much resistance to a determined attacker willing to bide their time and actually do useful work leading up to planting a backdoor. They could do that with multiple projects waiting to make their move when they gain trust.
The code was open source, many people were using it and no one noticed for quite some time. The people directly using it were developers not users generally unable to inspect the code. The overall development model failed to fund maintenance and provide any semblance of security.
1
It's not the failing of one person. made the mistake of trusting someone malicious, sure. Downstream projects made the mistake of not ensuring their dependencies had adequate resources for maintenance and security and they clearly didn't audit/review what they used.
1
Show replies