Backdoor in event-stream library dependency • Hacker News Board

Re: Backdoor in event-stream library dependency

#311

Post by bandrami » Mon, Nov 26, 2018, 8:10 PM UTC

So, I'm not a javascript person. I don't know the ecosystem that well. I'm not really even a programmer except at gunpoint, just a sysadmin.

But even 5 years ago I remember thinking "400 dependencies for a project is just WAY too many" and imagining something like this. And now I see some of the big frameworks require literally thousands of packages. Is there something about Javascript that necessitates this kind of ultra-fine hairsplitting on packages, or could that be made better?

Re: Backdoor in event-stream library dependency

#312

Post by dwild » Mon, Nov 26, 2018, 8:11 PM UTC

kurtisc wrote: post #233

meowface wrote: post #160

Earlier quoted context omitted.

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.

Dominic is the same kind of random stranger to most of the people whose codebases he's in.

Sure but he earned the trust of the community by building everything he did. It took times and effort, unlike that other strangers, which does give more credence to what he does.

Sadly he didn't deserved that trust.

Re: Backdoor in event-stream library dependency

#313

Post by raesene9 » Mon, Nov 26, 2018, 8:15 PM UTC

SCHiM wrote: post #226

raesene9 wrote: post #68

Earlier quoted context omitted.

Even package managers where signing support nominally exists, the take-up is often poor. IIRC rubygems support package signing but almost no-one uses it, so it's effectively useless. We're seeing the same pattern again with Docker. They added support for signing (content trust) but unfortunately it's not at all designed for the use case of packages downloaded from Docker hub, so it's adoption has been poor.

I think browsers show how to migrate away from insecure defaults successfully. The client software should start showing big obvious warnings. Later stages should add little inconveniences such as pop-ups and user acknowledgement prompts, eg. 'I understand that what I'm doing is dangerous, wait 5 seconds to continue'. The final stage should disable access to unsigned packages without major modifications to the default…

Browser security has heavily benefited from the fact that ther are a small number of companies with control over the market and an incentive to improve security.

Unfortunately the development world doesn't really have the same opporunities.

If, for example, npm started to get strict about managing, curating, security libs, they could just move to a new package manager.

Security features (e.g. package signing, package curation) have not been prioritised by developers, so they aren't widely provided.

Re: Backdoor in event-stream library dependency

#314

Post by jodrellblank » Mon, Nov 26, 2018, 8:16 PM UTC

JustSomeNobody wrote: post #195

eeZah7Ux wrote: post #86

Earlier quoted context omitted.

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

No, there is no alternative. You are responsible for what you ship. Even if you pay for the software, you should vet it as best you can as you're responsible.

How are you going to have the time and skill to vet Oracle anything?

Re: Backdoor in event-stream library dependency

#315

Post by jerf » Mon, Nov 26, 2018, 8:18 PM UTC

pcwalton wrote: post #291

jerf wrote: post #80

Earlier quoted context omitted.

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

I'm not convinced that this incident argues in favor of Go's "a little copying is better than a little dependency", which I continue to strongly disagree with. Rather, it indicates that you shouldn't blindly upgrade. Dependency pinning exists for a reason, and copying code introduces more problems than it solves.

I don't think you have to get all the way to the Go community's opinions to be in a reasonable place; I think the JS community is at a far extrema in the other direction and suffer this problem particularly badly, but that doesn't mean the other extreme is the ideal point. I don't personally know of any other community where it's considered perfectly hunky-dory to have one-line libraries... which then depend on other one-line libraries. My Python experiences are closer to the Go side than the JS side... yeah, I expect Python to pull in a few more things than maybe Go would, but still be sane. The node modules directories I've seen have been insane... and the ones I've seen are for tiny little projects, relatively speaking. There isn't even an excuse that we need LDAP and a DB interface and some complicated ML library or something... it was just a REST shell and not even all that large of one. This one tiny project yanked in more dependencies than the sum total of several Perl projects I'm in charge of that ran over the course of over a decade, and Perl's a bit to the "dependency-happy" side itself!

Re: Backdoor in event-stream library dependency

#316

Post by jodrellblank » Mon, Nov 26, 2018, 8:19 PM UTC

reacweb wrote: post #37

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…

Maybe it should be easier to give monetary rewards so that popular module maintainers get more motivation to care.

Claims here are that dominictarr maintains "hundreds of packages" even though that's too much work for one person.

If maintaining modules earned money, that would be much more incentive to "maintain" thousands of random things you never look at, and to hand over control while keeping it in your name (which he's also being blamed for).

Re: Backdoor in event-stream library dependency

#317

Post by mkeedlinger » Mon, Nov 26, 2018, 8:29 PM UTC

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.

I agree.

If anything maybe those who depend on unchecked code so willingly have the burden of responsibility?

Re: Backdoor in event-stream library dependency

#318

Post by oh_sigh » Mon, Nov 26, 2018, 8:31 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…

Why refuse? Because you have no idea who the person is, they don't have a history, and it is possible they want to take over the project to insert exploits into it. An ignored project (un)maintained by an ethical person is better than a project just handed off to whomever. At the very least a slight background check should have been done to see if the user has a history of contributing and maintaining open source projects.

Re: Backdoor in event-stream library dependency

#319

Post by mkeedlinger » Mon, Nov 26, 2018, 8:34 PM UTC

jabberthemutt wrote: post #199

jrockway wrote: post #154

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…

> Not sure what else there is to discuss. Morals and ethics.

I agree that this is a good discussion to have, but maybe we should include the responsibility that people who so easily include potentially untrusted code have in this?

This is free code, responsibility to check may need to have a social shift to those who use it.

Re: Backdoor in event-stream library dependency

#320

Post by mehrdadn » Mon, Nov 26, 2018, 8:35 PM UTC

I see a way to solve this with technology and that is for tools to allow secondary developers to publish on the package repository, but after a mandatory N-day delay. The main owner can then always have a chance to review.