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

151–160 of 509 posts

Re: Backdoor in event-stream library dependency

#151

Post by jimison »

AndrewGaspar wrote: post #55
tschellenbach wrote: post #26

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

The reasonable answer is that he should absolutely not have handed over publish capabilities to a completely unknown third-party. This seems obvious to me.

It's the internet... we're all unknown to each other, and many modern web apps are running a huge stack of unvetted code.

Honestly, a problem like this is overdue, especially for the NPM ecosystem with its propensity for a huge number of transitive dependencies, but also for all other major repos (nuget, cargo, CPAN, Docker, etc.). OS-based repos (Debian, Ubuntu, FreeBSD) might feel a little safer because it's harder to become a publisher, but it's not at all impossible. Perhaps the only reason it hasn't been a target before now is because there are easier avenues for cybercrime.

Re: Backdoor in event-stream library dependency

#153

Post by dragonwriter »

raesene9 wrote: post #126
dragonwriter wrote: post #106

Earlier quoted context omitted.

End-users are harmed and are not licensees, and so, even if the license disclaimers are effective (boilerplate disclaimers are often broader than the law of some jurisdictions will give effect to) the claims they would have for negligence would not be covered (and would not be transferred to downstream maintainers, who likely have concurrent liability, absent a indemnity clause as well as a disclaimer in the license.…

The people with legal liability to the end-users, I expect, are the developers that made use of this library without properly vetting all changes to it.

Liability is very often not exclusive in law, and, in particular, tends to flow the whole way up supply chains. With nothing being sold you probably aren't dealing with strict product liability upstream, but exposure of end users is reasonably foreseeable so there's no immediately obvious blanket reason for ruling out upstream negligence liability to end users.

The idea that the party most proximate to end users is exposed to potential liability is true, but the idea that this must mean noone else in the chain is exposed is not.

Re: Backdoor in event-stream library dependency

#154

Post by jrockway »

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 no legal right to use the code. Not sure what else there is to discuss.

Re: Backdoor in event-stream library dependency

#155

Post by michaelmrose »

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

He should just not allow any party not known and trusted to distribute under the original product name.

Let it be known that it's discontinued and let the new maintainer trade on his own reputation.

Re: Backdoor in event-stream library dependency

#156

Post by jwhitlark »

eli wrote: post #119
nmg wrote: post #34

Earlier quoted context omitted.

The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.

If I thought I might be on the hook for damages caused by a mistake in how I run an open source project, I would never open source anything.

Yeah, no kidding.

That's why the idea of commercial support exists. You need to depend on it? Pay for it.

Re: Backdoor in event-stream library dependency

#157

Post by tschellenbach »

rando231 wrote: post #72
tschellenbach wrote: post #26

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

If you can't or don't want to maintain the project and can't find anyone trustworthy to take it over, just don't do anything. This effectively deprecates the project, while not harming its existing functionality. This maintainer actively ceded control of his library to some random person.

Yeah this one is easy to spot, but what if someone makes valid contributions and for pull request #10 slips in a backdoor. Most open source projects are not able to check that anywhere near thoroughly enough.

Re: Backdoor in event-stream library dependency

#158

Post by kevin_b_er »

raesene9 wrote: post #81
kevin_b_er wrote: post #50

Move fast and break things. I view this as an endemic fault of how npm, and to a larger extent javascript, culture works and thinks. I believe npm to be a giant landmine of untrustwothy packages thrown together. No package is trustyworthy as the dependency chain runs too wide and too deep. And having unwieldy dependency trees is considered a feature of npm.

Unfortuntely, whilst npm is the largest source of packages, it's not the only place where this problem exists. Most programming languages have this issue to one degree or another, which is that they have a package management repository where there is no curation of content, and generally no package signing (there are some cases where that exists, but the take-up isn't always great). The challenge is that this now see…

Yes. The fast moving package management dependency hell seems to be spreading, but I believe its root comes from npm/javascript. If we see it elsewhere it is because it is borrowed from javascript as it was seen as "the future" of software development.

Re: Backdoor in event-stream library dependency

#159

Post by codetrotter »

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…

> other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization.

Define failure. I don’t know Dominic and I haven’t looked into the Scuttlebutt project beyond being aware of its existence and what it is, but...

He talks about creating a community where anyone is welcome to contribute.

It is perfectly fine for an open source project to have the development process and the community as its raison d'être.

Just because a project doesn’t outcompete every single alternative doesn’t mean it’s failed.

Just because a project isn’t even used by more than a handful of people doesn’t mean it’s failed.

It all depends on what the goal of the project was in the first place, and what the goal of the contributors are.

Re: Backdoor in event-stream library dependency

#160

Post by meowface »

jhardy54 wrote: post #48
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…

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…

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.
Post reply on HN