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

81–90 of 509 posts

Re: Backdoor in event-stream library dependency

#81

Post by raesene9 »

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 seems to be embedded in the culture of a lot of development, and changing that culture would be very challenging, I'd imagine.

Re: Backdoor in event-stream library dependency

#82

Post by antocv »

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.

Re: Backdoor in event-stream library dependency

#83

Post by jt3 »

Would anyone want to support a third party which audits popular dependencies, and digitally signs off after being reviewed? I currently audit source code for private companies, would be cool to pivot and focus on open source projects.

Feel free to email me, jt3@justin-taft.com

Re: Backdoor in event-stream library dependency

#85

Post by raesene9 »

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.

yep, and that's why I said "from a license standpoint". Software licenses aren't moral constructs, they are legal constructs.

Re: Backdoor in event-stream library dependency

#86

Post by eeZah7Ux »

_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…

> Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative.

The alternative is to use distributions that do vetting and staging.

Re: Backdoor in event-stream library dependency

#87

Post by AndrewGaspar »

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.

Re: Backdoor in event-stream library dependency

#89

Post by xvector »

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.

Re: Backdoor in event-stream library dependency

#90

Post by gregknicholson »

chippy wrote: post #65
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…

> maintains hundreds of packages Might be worth looking over some of these to see if he has also given access of them to some dodgy people. As most of them appear to be as old as event-stream and are also probably as unused by him. And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. But hes a good guy, so don't blame him if you find that he's done this befor…

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

Post reply on HN