Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in event-stream library dependency

github.com

Post reply on HN
Print view View original

441–450 of 509 posts

Re: Backdoor in event-stream library dependency

#441

Post by ktorn »

wpietri wrote: post #356
slg wrote: post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

Definitely. One of his coworkers has a great thread about this, including on how he has hundreds of libraries in use: https://twitter.com/andrestaltz/status/1067157915398746114 Many, many people treat open-source projects like consumer products. Except the paying-money part, of course. That they're happy to leave out. This is a systemic problem, and blaming one guy won't solve anything. Especially since so many are b…

This, and then make sure the rewards trickle down to everyone involved: https://github.com/ktorn/vdp

Re: Backdoor in event-stream library dependency

#442

Post by jnewell »

OJFord wrote: post #359
XCSme wrote: post #109

Earlier quoted context omitted.

It's just doing 2^logN...

Which ought to be just N - but notice the argument passed in is mysteriously renamed. It may be nothing - I'm not even sure what N is here - I just agree that it looks weird.

https://github.com/barrysteyn/node-scrypt/pull/119

Re: Backdoor in event-stream library dependency

#443

Post by stockkid »

rglover wrote: post #310

That thread is a huge argument for paid software. It's mind blowing how folks expect people to maintain things for nothing and get mad when it doesn't work perfectly. Some silly choices were made by the original maintainer but give the dude a break. He doesn't owe you a damn thing.

I agree. The author released this library under MIT license which explicitly states that there is no warranty. Yet some people in the GitHub issue thread are acting as though the author owed something to them personally.

Re: Backdoor in event-stream library dependency

#444

Post by jrockway »

heartbreak wrote: post #400
jrockway wrote: post #154

I love reading these threads. People seem to expect way more out of open-source software than is actually guaranteed to them. It is a template of some computer code that may be relevant to your work; nothing more, nothing less. "I can't believe you let this happen to me!" Well, read the license: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED". If you don't agree to that, you have…

The MIT license isn’t as bulletproof as you think it is.

The license doesn't really matter here. I'm only quoting it to set expectations. People are showing up demanding some sort of quality standard, when they explicitly agreed that there was no such standard. A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved.

To your point, if the author added the malicious code, I don't think the license would necessarily protect him. Intent is key. But he didn't.

Re: Backdoor in event-stream library dependency

#445

Post by meowface »

tclancy wrote: post #419
meowface wrote: post #160

Earlier quoted context omitted.

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

Have you ever created a package that people started to use, which you then had to maintain for purposes that didn't do anything for you and then no longer even need the package? Pretty much any rando offering to take over maintenance is going to be welcome to it compared to the dozens of requests and insults offered as bug reports.

Yes, I am in this situation right now, actually. I have a project with around 700 stars on GitHub with over a million downloads per month (according to PyPI) which I no longer have the time, interest, or willpower to continue maintaining.

I placed an open call to find a new maintainer months ago, and have received many requests. Every single request I've received has been roughly as shady as the request sent to event-stream. I've declined them all due to their shadiness. I know exactly what could happen (this situation right here) if I give it to the wrong person.

Re: Backdoor in event-stream library dependency

#446

Post by yc12340 »

floatingatoll wrote: post #352
slg wrote: post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

I don’t think any blame is due to the author at all. Volunteer project ownership is voluntary, and transferring to another volunteer is the only choice other than abandonment for a lot of volunteers. Package repositories don’t support monetization and there’s no pool of volunteers associated with the repository itself to take up maintenance of what otherwise would have been abandoned. Would we have preferred if the o…

> Package repositories don’t support monetization and there’s no pool of volunteers associated with the repository itself to take up maintenance of what otherwise would have been abandoned.

Your statement contradicts itself: there is a pool of volunteers, — they are the ones maintaining NPM packages to begin with. In fact, the author of event-stream has given control to another person, because he believed, that the guy was an ordinary volunteer like himself. Unfortunately, the reality is a bit more complicated than just that: people will voluntarily help you to maintain your projects, but only if they share your goals. Ideally, one should ensure, that the to-be-maintainer has invested a lot of effort in the project they are trying to take over — reported issues, fixed bugs, added features etc. for considerable amount of time. In other words — ensure, that they can contribute to the project in significant way and move it forward. Otherwise, what is the point of transferring maintenance?!

Re: Backdoor in event-stream library dependency

#447

Post by pier25 »

malvosenior wrote: post #329
pier25 wrote: post #257

The problem with JS (Node and browser) is that the standard library is pretty much useless. What JS/NPM needs is some sort of certification program for secure libraries that would fill the void of the lack of a standard library. NPM of course would give a warning when installing a non certified library. This would be a tremendous effort, but it would really be the only way for NPM to survive in the long term. NPM is…

> NPM is one of the reasons we've moved to Go for our server side code. It's one of the reasons, but far from the only reason. With Go, Python, Rust, Swift... is there any reason to use Javascript on the backend? Most attempts I see to "share" code between the browser and the server end up adding needless layers of abstraction and complexity.

I think SSR is probably the best reason for using Node.

Another one is making a GraphQL API that concentrates data for the clients from different places. It could be made in another language, but it's better if front end developers maintain that project.

For bite sized cloud functions Node is also not a bad choice.

But for pure backend projects, yeah, Node isn't the greatest choice these days.

Re: Backdoor in event-stream library dependency

#449

Post by zawerf »

gnulinux wrote: post #428
zawerf wrote: post #412

Earlier quoted context omitted.

Not really asking for perfect/decidable. Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one was live for 3-4 months before it got found by luck? For example I would really appreciate if they added something to detect/warn when a package needs eval or http requests permissions (yes, I know npm packages don't have a concept of permissions). Anyway your c…

I wasn't intending to say reading every single commit of your dependencies is practical. I was arguing that unless you do that, you get absolutely no guarantee of security. If you take code for granted because it has 17k internet points, you're putting yourself at risk. I can't see how this is not very simple.

It's "very simple" that you will also "get absolutely no guarantee of security" unless you personally rewrite every line of code you use in a provable/verifiable language, design and manufacture your own hardware, hide in a cave to avoid all social engineering, and so on.

Hopefully you see why your advice is similarly impractical.

Re: Backdoor in event-stream library dependency

#450

Post by 83457 »

nneonneo wrote: post #386
jonknee wrote: post #165

Earlier quoted context omitted.

> you’re trusting random strangers on the Internet to run code on your systems I mean that's pretty much how the world works. Even running Linux is trusting random strangers on the internet. Most of the time it works pretty well, but obviously it's not perfect. Even the largest companies in the world get caught with security issues from open source packages (remember Heartbleed?).

When I visit a random website, it is very hard for that website to compromise my computer or my private data. The only really viable way is a zero-day in my browser, or deception (e.g. phishing, malicious download). When I install an app on my iPhone, it is very very hard for that app to compromise my phone or my private data. In both of these cases, I can download and run almost any code, and be fairly confident tha…

I think what you just described are platforms where you don't have to trust strangers.
Post reply on HN