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

451–460 of 509 posts

Re: Backdoor in event-stream library dependency

#451

Post by syrrim »

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. What does "a project dying" even mean? The code still runs, and will for the foreseeable future. If it was half complete, then that would be bad, but this was clearly a complete solution. Let it remain complete. This was a quick way on dominics part to kill the project actually

Re: Backdoor in event-stream library dependency

#452

Post by testvox »

brobdingnagians wrote: post #384
codetrotter wrote: post #159

Earlier quoted context omitted.

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

A security hole and backdoor is always a failure in a software product. Having someone else control your system is just about the worst you can get. It has nothing to do with relative definitions because it always degrades every other objective the project could or does have. If a model of leadership leads naturally and often to security holes, it is time to reconsider the model. If it is a common library, then it is…

Lots of projects, including windows and linux have had security holes that allow remote control of your system. Security flaw does not mean failure, its always about weighing the cost of security flaws against the utility the software provides. Even a completely compromised system can provide utility to many users.

Re: Backdoor in event-stream library dependency

#453

Post by sarapetersara »

rglover wrote: post #310

That thread is a huge argument for paid software. It's mind blowing how folks expect people to maintain things for nothing and get mad when it doesn't work perfectly. Some silly choices were made by the original maintainer but give the dude a break. He doesn't owe you a damn thing.

Paid software most often contains open source components that are equally vulnerable as this one, and if you expect paid software to be explicitly better maintained in terms of code than free software... you are in for a surprise (hint: corporate release cycle is a grinder)

Re: Backdoor in event-stream library dependency

#454

Post by swsieber »

83457 wrote: post #450
nneonneo wrote: post #386

Earlier quoted context omitted.

When I visit a random website, it is very hard for that website to compromise my computer or my private data. The only really viable way is a zero-day in my browser, or deception (e.g. phishing, malicious download). When I install an app on my iPhone, it is very very hard for that app to compromise my phone or my private data. In both of these cases, I can download and run almost any code, and be fairly confident tha…

I think what you just described are platforms where you don't have to trust strangers.

Yes, and I think they meant to. Node isn't one of those.

Edit: partially because of design decisions around package permissions.

Re: Backdoor in event-stream library dependency

#455

Post by heartbreak »

jrockway wrote: post #444
heartbreak wrote: post #400

Earlier quoted context omitted.

The MIT license isn’t as bulletproof as you think it is.

The license doesn't really matter here. I'm only quoting it to set expectations. People are showing up demanding some sort of quality standard, when they explicitly agreed that there was no such standard. A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved. To your point, if the a…

> A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved.

It's an author/maintainer issue (and not an NPM issue) because the maintainer explicitly gave the bad actor the right to publish via NPM's delivery channel. The maintainer did so in gross negligence, in my opinion.

Re: Backdoor in event-stream library dependency

#456

Post by marshray »

bmurphy1976 wrote: post #431
AgentME wrote: post #388

Earlier quoted context omitted.

`cat` without any options support is possibly simpler than left-pad. I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distr…

Do you really think cat is as simple as left-pad? https://github.com/freebsd/freebsd/blob/master/bin/cat/cat.c Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source. Left pad it is not.

> `cat` without any options

Interestingly, the `raw_cat()` function is 37 lines long.

https://github.com/freebsd/freebsd/blob/e511976db9f51bae1a59...

Re: Backdoor in event-stream library dependency

#457

Post by floatingatoll »

yc12340 wrote: post #446
floatingatoll wrote: post #352

Earlier quoted context omitted.

I don’t think any blame is due to the author at all. Volunteer project ownership is voluntary, and transferring to another volunteer is the only choice other than abandonment for a lot of volunteers. Package repositories don’t support monetization and there’s no pool of volunteers associated with the repository itself to take up maintenance of what otherwise would have been abandoned. Would we have preferred if the o…

> Package repositories don’t support monetization and there’s no pool of volunteers associated with the repository itself to take up maintenance of what otherwise would have been abandoned. Your statement contradicts itself: there is a pool of volunteers, — they are the ones maintaining NPM packages to begin with. In fact, the author of event-stream has given control to another person, because he believed, that the g…

We’re colliding on English imprecisions. I distinguish growth (all unnecessary work) from maintenance (only necessary work: fix serious bugs, no new features, minimize rewrites). My use is the latter, not the former.

Re: Backdoor in event-stream library dependency

#458

Post by jodrellblank »

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 undermined his _own_ credibility, which is all that really matters in open source.

Even if I take your sentence dead seriously - the code injection, the crypto wallet stealing, the disruption to the downlevel users, none of that matters only Dominic's credibility matters - where does that get me?

Assume that Dominic was bribed to inject the code himself, with a share of the profits, and he did, maliciously and criminally, and he gets arrested, and people were still disrupted and money was stolen and insecurities were introduced and flamewars were had .. and his reputation is now justly and fairly tarnished for all time..

what good does that do anyone? How does that avoid it happening in future or change how we respond to it?

Re: Backdoor in event-stream library dependency

#459

Post by flukus »

dkns wrote: post #222
tschellenbach wrote: post #168

Earlier quoted context omitted.

This exploit is not NPM specific, could be any programming language. (Though NPM is a bit easier to exploit since there are so many packages and a large tree of deps)

Would it be possible to put compromised package in Debian repository? Or has something like this happened in the past?

It's certainly possible but to my knowledge hasn't happened. This case specifically where a random person got the authority to publish new versions would be prevented by debians organisational policies. Other distro's are much less stringent and open to this kind of attack though, arch/yaort for instance will happily install straight from github and this exact scenario could have played out there.

The gatekeeper model is a proven one, be it an organisation like debian, a paid curator like redhat or a locked down ecosystem like iOS.

Re: Backdoor in event-stream library dependency

#460

Post by jodrellblank »

michaelmrose wrote: post #413
jodrellblank wrote: post #308

Earlier quoted context omitted.

He is morally liable Google says "Definition of Liable: responsible by law; legally answerable". If you claim he's not legally responsible but is "morally liable", where "liable" itself means "legally responsible", what in your world does the term "morally liable" mean, specifically? What does it mean you can do to him, or what does it mean you should do in future in response to this?

Google isn't the ultimate source of truth of the meaning of words. When someone says that another party is morally liable they mean morally responsible. That he ought to feel responsible and act according and consider others actions in the future lest he feel like he has morally failed people in the future. Ultimately we are often and are often expected to be our harshest critic and ought not to limit our duty to oth…

The meaning of words isn't what I want to focus on, but the irrelevance of any response to this event along the lines of "well he SHOULD feel bad".

If "he is morally responsible" leads only to "he should feel bad" and nothing more, then what does it matter if he is/isn't morally responsible?

Ok he (does/doesn't) feel (justifiably/unjustifiably) bad .. now what?

Post reply on HN