Backdoor in event-stream library dependency • Hacker News Board

Re: Backdoor in event-stream library dependency

#141

Post by jwhitlark » Mon, Nov 26, 2018, 5:41 PM UTC

M2Ys4U wrote: post #70

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…

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

There's a moral liability to do your due diligence when using upstream software, too. Otherwise it's just whining about "the untrustworthy system I built upon is untrustworthy".

Re: Backdoor in event-stream library dependency

#142

Post by daburninatorrr » Mon, Nov 26, 2018, 5:41 PM UTC

This situation reminds me a lot of the hypothetical situation outlined in this post [1]. Definitely worth the read for anyone who hasn't already seen it.

[1] https://hackernoon.com/im-harvesting-credit-card-numbers-and...

Re: Backdoor in event-stream library dependency

#143

Post by [deleted] » Mon, Nov 26, 2018, 5:41 PM UTC

XCSme wrote: post #109

OJFord wrote: post #69

Earlier quoted context omitted.

Yes, that looks dodgy - a 64-bit 'N' being renamed 'logN', and its value changed to `1` left shifted by its prior self? I think there's a good bet that's just zeroing it out.

It's just doing 2^logN...

[deleted]

Re: Backdoor in event-stream library dependency

#144

Post by igolden » Mon, Nov 26, 2018, 5:42 PM UTC

always_good wrote: post #93

There are a few issues with NPM that make this kind of thing especially easy/lucrative: - An ecosystem of massive amounts of transitive dependencies increases the number of people you need to trust. If I wanted to attack a project that used NPM, their package.json dependencies would be a really good place to start. Find the least popular transitive dep they use and email the owner to see if you can be a contributor (…

+1 for source code browser on NPM

Re: Backdoor in event-stream library dependency

#145

Post by gregknicholson » Mon, Nov 26, 2018, 5:42 PM UTC

AndrewGaspar wrote: post #87

antocv wrote: post #82

Well this undermines everything dominictarr has done for secure scuttlebutt and other projects, including datproject and its connection to Knight Foundation. "Oops, I just gave the repo to an unkown dude", OK. Sure. Just replace "unkown dude" with "to my colleagues at 5 eyes secret service organization" This kind of mistake is not a mistake, not from a dude like dominic.

Seriously, I don't get how the others in this thread don't get this. Nobody's talking about the legalese of the license - he's undermined his _own_ credibility, which is all that really matters in open source. If he's fine with people not trusting his packages in the future, that's fine, but THAT's the trade-off, regardless of how you license the code.

He's been too naive and creduluous in judging a person based on limited information. His coding skills aren't in question — the software was fine while he was still in charge of it.

I suspect Dominic didn't see himself as the maintainer of the package, but as a maintainer of a copy of the package (like how git is designed to work). With this perspective, of course someone else can be a maintainer.

The problem is that NPM changed their upstream from Dominic to right9ctrl without checking. (Maybe because Dominic clicked a button — NPM is still responsible for accepting that decision or not.)

Re: Backdoor in event-stream library dependency

#146

Post by lsc » Mon, Nov 26, 2018, 5:43 PM UTC

_wmd wrote: post #36

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…

This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever : THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT…

The real problem is that so far, open source has been mostly more responsible than closed source. mostly. So many companies and people just go 'eh' and accept the defaults rather than really digging in. Which, in a real way, means they get what they deserve, but on the other hand, what is the alternative?

I mean, personally, the alternative I like is a sort of hybrid model, where you pay someone else to do the vetting, like RHEL, but nobody I support is willing to stay within the RHEL package world, or to otherwise pay to really vet the packages they use, so it's defaults all the way down, and it usually works just fine! until it doesn't.

Re: Backdoor in event-stream library dependency

#147

Post by perpetualcrayon » Mon, Nov 26, 2018, 5:44 PM UTC

We need to incorporate the fact that people will move on with their lives and transfer ownership of projects.

This could be solved in a few ways.

Maybe instead of signing over ownership, maybe the protocol should be to force a fork and make notes in the README that there's a new repo whose author has not been vetted and should be used with caution.

Re: Backdoor in event-stream library dependency

#148

Post by cmorgan31 » Mon, Nov 26, 2018, 5:44 PM UTC

mattdeboard wrote: post #116

gregknicholson wrote: post #90

Earlier quoted context omitted.

> And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. Well... yeah. If you don't trust him, don't trust him. If you don't trust NPM's vetting, don't trust NPM's vetting.

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.

Re: Backdoor in event-stream library dependency

#149

Post by StavrosK » Mon, Nov 26, 2018, 5:44 PM UTC

igolden wrote: post #128

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.

Thank you! I really hope it takes off, it's an effort from the community for the community.

Re: Backdoor in event-stream library dependency

#150

Post by [deleted] » Mon, Nov 26, 2018, 5:44 PM UTC

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…

[deleted]