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

121–130 of 509 posts

Re: Backdoor in event-stream library dependency

#121

Post by muraiki »

jerf wrote: post #80
dmortin wrote: post #22

Earlier quoted context omitted.

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.

"If you have tons of depedencies then it's not feasible to check every diff." Part of bringing in a dependency is bringing in the responsibility for verifying it's not obviously being used badly. One of the things I've come to respect the Go community for is its belief that dependencies are more expensive that most developers currently realize, and so generally library authors try to minimize dependencies. Our build…

Unfortunately, one of the things that makes JS dev pull in so many deps is that it lacks a decent standard library. Meanwhile, the Go standard library is amazing!

Re: Backdoor in event-stream library dependency

#122

Post by ddingus »

JumpCrisscross wrote: post #79
M2Ys4U wrote: post #70

Earlier quoted context omitted.

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

> There's a difference between legal liability and moral liability Making business decisions on the hope that someone else's moral codes will perfectly align with your own is unscalable. That's why we have written laws, codes and contracts.

When that happens, pay people.

Seriously. Having a moral discussion in tandem with scale seems very poorly misaligned with the interests, needs, risks of pretty much everyone involved.

Re: Backdoor in event-stream library dependency

#123

Post by programmarchy »

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…

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 behind Linux. Lieutenants gain authority based on the merit of their contributions, and are responsible for reviewing the work of other developers. Authority works, has worked for thousands of years, and will continue to work for thousands more.

Re: Backdoor in event-stream library dependency

#124

Post by eropple »

ryandrake wrote: post #118
SpicyLemonZest wrote: post #31

Earlier quoted context omitted.

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

You can, but it's opt-in. At least once with every new project I go "gah, dammit!" because I forget to check in a lockfile, but I sleep better at night.

I do not know if NPM lockfiles are transitive, though. Guess I'd better go looking...

Re: Backdoor in event-stream library dependency

#125

Post by perfunctory »

xvector wrote: post #89
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.

It’s about ethically handing off a package. No one is forcing him to maintain it. But when you make a package used by millions of people, you become responsible for their safety. To then hand over a package to a hacker or unknown party is just morally wrong. Just mark it as deprecated and call it a day, like a normal and responsible person.

Well, he didn't really hand it over to a hacker, did he?

Re: Backdoor in event-stream library dependency

#126

Post by raesene9 »

dragonwriter wrote: post #106
raesene9 wrote: post #44

Earlier quoted context omitted.

You may not like it but from a license standpoint, I think you may be incorrect As quoted elsewhere in this thread " THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

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.

Re: Backdoor in event-stream library dependency

#127

Post by shittyadmin »

ocdtrekkie wrote: post #58
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.

You can't vet the people, but you can vet the code. Of course, if you just give someone commit rights, then you can't. But generally speaking the maintainer understands the code they merge into a project, and that is the vetting that takes place.

Sure, but then they have to actively invest time into the project... not everyone can afford that.

Re: Backdoor in event-stream library dependency

#128

Post by igolden »

StavrosK wrote: post #29

I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…

I really like this idea, thanks for sharing.

Re: Backdoor in event-stream library dependency

#129

Post by pcnix »

perfunctory wrote: post #125
xvector wrote: post #89

Earlier quoted context omitted.

It’s about ethically handing off a package. No one is forcing him to maintain it. But when you make a package used by millions of people, you become responsible for their safety. To then hand over a package to a hacker or unknown party is just morally wrong. Just mark it as deprecated and call it a day, like a normal and responsible person.

Well, he didn't really hand it over to a hacker, did he?

His responsibility as a maintainer is to signal when there's a change in power, since the package is trusted via his credentials.

Re: Backdoor in event-stream library dependency

#130

Post by raesene9 »

michaelmrose wrote: post #105
raesene9 wrote: post #44

Earlier quoted context omitted.

You may not like it but from a license standpoint, I think you may be incorrect As quoted elsewhere in this thread " THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

Putting it on paper does not make it so. A single lawsuit and you could easily be out thousands even if you win. The legal outcome could vary widely state to state and nation to nation. If putting a blurb in a text file makes you feel safe about being sued for negligence you haven't considered all possible venues. Here is an article about liability waivers https://www.enjuris.com/blog/questions/liability-waivers/

So you reckon that people who publish open source software should be liable for flaws/vulnerabilities in their code?

It's a bold assertion, I'd be interested to see if you can provide any case law where it's been tested.

Post reply on HN