Live data from Hacker News

Backdoor in event-stream library dependency

github.com

241–250 of 509 posts

Re: Backdoor in event-stream library dependency

#241

Earlier quoted context omitted.

npm does vetting?

NPM increased their efforts with regards to auditing. They realized it was a prominent attack vector and without them taking responsibility for some level of the problem they would be throwing their reputation down the drain. It isn't perfect, but it's a step to improving the situation.

Sweet! There are so many brilliant & creative people in the Node community. I'm positive there are some innovative ways to approach this problem.

Re: Backdoor in event-stream library dependency

#242
Semver seems like a huge problem here, blindly pulling in changes is just asking for a lot trouble, intentional or not.

I'd also say NPM's centralized naming structure is also problematic, people don't want to update 1000's of modules to some new latest version of X which was forked and is now maintained, so it's handed off like this.

Re: Backdoor in event-stream library dependency

#243

Earlier quoted context omitted.

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…

Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work. If this is an indictment of anything, it's an indictment of the entire NPM ecosystem -- it's been the wild wild west for years; haphazardly using whatever NPM install gives you is baked into the culture. Sure, Dominic is an active participant in that culture but it seems to me that it is impossibl…

[deleted]

Re: Backdoor in event-stream library dependency

#244
post #206
post #182

Earlier quoted context omitted.

> Lieutenants gain authority based on the merit of their contributions Meritocracy is an outdated discriminatory practice. https://postmeritocracy.org/ https://www.theguardian.com/commentisfree/2017/mar/20/merito...

To be clear, you're arguing that people should be judged on their identity and background rather than the merit of their contributions?

You are feeding a troll. Please don't.

Re: Backdoor in event-stream library dependency

#245

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

Lots of tiny dependencies.

Re: Backdoor in event-stream library dependency

#246
post #240

Makes me wonder if there's a business opportunity. Make your own version of NPM, based off of the real NPM, but some level of auditing for package updates. Don't report suspicious commits from new contributors right away, that sort of thing. Charge companies a few hundred $ a month to use your site instead of NPM, and they can update packages at will without risk of picking up something nasty. Then again, the fact th…

Not really: http://www.paulgraham.com/schlep.html

Re: Backdoor in event-stream library dependency

#247

Earlier quoted context omitted.

> That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership. I'm sure he would do it for $150k/year. He won't do it for $150k/year? Increase the price until he says "Yeah, sure I will maintain it". Or maybe h…

How about just not transfer ownership of the original name. Let foo become foo-new or go from john/foo to bob/foo whichever is appropriate thus ensuring that only those who affirmatively added bob/foo or foo-new are ever effected. Vetting new maintainers sounds like hard work that you might not feel like doing for free no problem just don't do it and don't give them the damn name.

That's fundamentally not how identification on the Internet works. You are whoever you say you are. It's absurd to tie identity to a physical person.

Re: Backdoor in event-stream library dependency

#248

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

But you also have to review the diffs of your dependency's dependencies. And their dependencies. And so on and so on.

Re: Backdoor in event-stream library dependency

#249

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

I wish JS/npm was more centralized... I wish there was some centralized authority who took some responsibility for maintaining the security and stability of core packages.

I think it'd make sense for npm to be this authority. They're a for-profit organization who benefits most from the success of the npm ecosystem. So why don't they try and take over the most popular projects like left-pad and event-stream? Especially the projects that are small and mostly unmaintained.

Re: Backdoor in event-stream library dependency

#250
Regardless of if the author's to blame, the outcome would be no different if the author's Github account were compromised or the author themselves were compromised/decided to act maliciously. In either case, user's of the code also have an effort to act responsibly. Are any downstream package author's that incremented the dependency or failed to lock it to a specific version less culpable? (event-stream is being used by SuperPopularPackageX which allows the compromised version)
Post reply on HN