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

131–140 of 509 posts

Re: Backdoor in event-stream library dependency

#131

Post by ddingus »

elorm wrote: post #49
ericcholis wrote: post #23

Earlier quoted context omitted.

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…

So if I understand you correctly, he was supposed to have run some sort of background check with all the state agencies to figure out if he was a bad actor or someone who really relied on the module and wanted to maintain it. You can’t protect against all possible outcomes from a situation like this. Seems like we’re just looking for people to blame whenever there’s an issue these days

Free lunch tasted bad? And let's not blame the free lunch people who are always on the hunt for people and ingredients needed to put together free lunches.

Paying for a better, more consistent lunch makes sense at some point, yes?

People are motivated to work, ingredients are vetted, better prepared, etc...

Not blaming anyone, just pointing out an obvious problem by analogy.

Re: Backdoor in event-stream library dependency

#132

Post by michaelmrose »

perfunctory wrote: post #96
M2Ys4U wrote: post #70

Earlier quoted context omitted.

There's a difference between legal liability and moral liability.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

If you run a business where you have convinced people to give you access to their house to do some chore and you sell your business and your copy of their keys to a criminal it could be morally problematic.

A car is merely a fungible vehicle the customer would have been no better or worse off had the robber been driving a different car.

This would be an apt analogy for just giving / selling a code base.

Had it been distributed under a new account/name users could have decided to trust or not trust a new maintainer.

The dev allowed new people to trade under his name and rep worse allowed new people to delegate further to unknown others.

He is morally liable and ought to have known better.

Re: Backdoor in event-stream library dependency

#133

Post by mtgx »

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…

> Isn't adding another potentially unknown maintainer generally better for the community than a project dying?

No, not if the project becomes malicious. I'd rather it died and I switched to an alternative I can trust.

Re: Backdoor in event-stream library dependency

#134

Post by dspillett »

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…

> Isn't adding another potentially unknown maintainer generally better for the community than a project dying?

I don't disagree with your overall premise: if you aren't actively maintaining a project for what-ever reason (you don't currently have the interest in it compared to other project or can't justify the time that you could spend elsewhere instead) and someone else does have the time and the interest, the project should be allowed to live on through new maintainers.

But: just handing over admin access of a project that many rely on to an unknown entity is not a safe move as this case proves. I understand the point of not wanting a permissions based community and so forth, but (and call be cynical if you will) that is rather naive. The world is just too full or arseholes for that sort of idealism to be at all safe in practise.

Instead let the new person/people create a fork and update your documentation to state that you are not currently actively maintaining your fork and people should consider moving to the new one instead. This way no one else unknowingly uses the new fork. Of course people might blindly switch over without verifying the new maintainers which puts those people at the same risk, but at least they take action to blindly move over rather than not knowing at all that it has happened, and people who are more sensibly cautious will hopefully monitor the changes more carefully than they would under the previous stewardship so this sort of backdoor is less likely to go unnoticed.

Re: Backdoor in event-stream library dependency

#135

Post by lsc »

programmarchy wrote: post #123
jhardy54 wrote: post #48

Earlier quoted context omitted.

Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…

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…

> 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.

Maybe, but the sort of people who are not jerks (i.e. who don't get too much pleasure out of having power) who are willing to lead for free are... very rare.

Fundamentally, non-commercial open-source needs to evolve organizational methods that require less leadership, just because there aren't a lot of good leaders willing to work for free.

Re: Backdoor in event-stream library dependency

#137

Post by nine_k »

perfunctory wrote: post #96
M2Ys4U wrote: post #70

Earlier quoted context omitted.

There's a difference between legal liability and moral liability.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

If the car is sold, but still uses the same number plate, and is still attached to the name of the original owner, there is a problem.

Selling a car = shutting down the maintenance of current project, pointing to a fork done by someone.

What happened is just handing the car's keys to someone, without much notice.

Re: Backdoor in event-stream library dependency

#138

Post by sulam »

kd5bjo wrote: post #78
ttty wrote: post #53

Earlier quoted context omitted.

I'd love to do this, but how can you review thousands of lines of code that changed?

You can use smaller, more targeted libraries so that the changes you need to review are actually relevant to your project.

In the Node/NPM world, this is pretty difficult. There are many (many) small libraries and everything you depend on brings in many more.

Re: Backdoor in event-stream library dependency

#139

Post by tashoecraft »

sergiotapia wrote: post #42

A lot of butthurt people railing on the guy. Maybe he just doesn't care anymore about a dead package he has no intention of maintaining. Blame yourselves devs, not the author who donated hours and hours of free work for your benefit.

A dead package with 2million downloads a week, not very dead no matter what the maintainer thinks of it.

Re: Backdoor in event-stream library dependency

#140

Post by kentm »

dmortin wrote: post #22
floatingatoll wrote: post #14

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.

If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.

I would argue that having tons of dependencies is a problem in and of itself. This has become normal in software development because it’s been made easy to include dependencies, but a lot of the costs and risks are hidden.
Post reply on HN