Backdoor in event-stream library dependency • Hacker News Board

Re: Backdoor in event-stream library dependency

#341

Post by gyrgtyn » Mon, Nov 26, 2018, 9:14 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 (…

I don't see how the same thing couldn't happen with an elm package? The attacker can commit to the github repo.

Re: Backdoor in event-stream library dependency

#342

Post by perennate » Mon, Nov 26, 2018, 9:17 PM UTC

joekrill wrote: post #324

thrower123 wrote: post #236

NPM is just a mess, and the whole culture and ecosystem that surrounds it. Micropackaging does make a little bit of sense at least in theory for the web, where code size ought to matter, but in practice it's a complete shitshow, and leads to these insane dependency paths and duplication and complete impossibility to actually keep abreast with updates to dependencies, much less seriously vet them. The insidious threat…

I don't see how this problem is limited to just NPM. This is a problem of any package manager. Or any software distribution system in general, really. Look at all the malware found on the Play Store and the Apple Store. Unless you're willing to meticulously scrape through every bit of code you work with you're at risk. Even if you can, what about the OS software? How about the software running on the chipset? This is…

I think part of the difference at issue is the number of distinct entities (users/organizations) you need to trust due to the acceptance of micropackaging.

With most programming languages, a small-to-medium project might pull dependencies from tens of entities, but with npm, even a small project can easily rely on hundreds or even thousands of entities.

It is easier to weed out unreputable entities when you are depending on fewer entities.

Re: Backdoor in event-stream library dependency

#343

Post by pytyper2 » Mon, Nov 26, 2018, 9:18 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…

This takes "charitable interpretation" to an extreme.

Re: Backdoor in event-stream library dependency

#344

Post by eli » Mon, Nov 26, 2018, 9:18 PM UTC

trickstra wrote: post #335

eli wrote: post #110

Earlier quoted context omitted.

A reasonable position -- and obviously better in this case -- but in general I'm not sure most people agree. The overwhelming majority of the time maintainers are not malicious.

the overwhelming majority of people are not thieves either, but we still lock our cars when we leave them in the parking lot

Sure, but we don't typically walk around the car and check that no one has slashed the back tires.

Re: Backdoor in event-stream library dependency

#345

Post by syn0byte » Mon, Nov 26, 2018, 9:20 PM UTC

jamp897 wrote: post #38

This is one of the gaping security holes that open source has always had, you don’t know where the code came from and your best indication if it’s safe is how popular it is. Npm and Maven libs being the scariest since there are hundreds for even small apps.

Are those points not the same for closed source products? "You don't know where the code came from" and "your best indication if its safe is how popular it is."

Re: Backdoor in event-stream library dependency

#346

Post by nneonneo » Mon, Nov 26, 2018, 9:21 PM UTC

joekrill wrote: post #324

thrower123 wrote: post #236

NPM is just a mess, and the whole culture and ecosystem that surrounds it. Micropackaging does make a little bit of sense at least in theory for the web, where code size ought to matter, but in practice it's a complete shitshow, and leads to these insane dependency paths and duplication and complete impossibility to actually keep abreast with updates to dependencies, much less seriously vet them. The insidious threat…

I don't see how this problem is limited to just NPM. This is a problem of any package manager. Or any software distribution system in general, really. Look at all the malware found on the Play Store and the Apple Store. Unless you're willing to meticulously scrape through every bit of code you work with you're at risk. Even if you can, what about the OS software? How about the software running on the chipset? This is…

NPM is quite a different software distribution mechanism than a typical app store.

In an app store, apps are self-contained packages with low to no dependency on other apps in the store, meaning that a single compromised or malicious app can only really affect that app's users. The OS may also isolate apps from one another at runtime, further limiting the amount of damage such an app can do (barring any OS bugs).

On the other hand, NPM packages depend on a veritable forest of dependencies, motivated by the "micropackaging" approach. Look at any sizable software package with `npm list`. For example, `npm` itself on my computer has over 700 direct and indirect dependencies, 380 of which are unique. That's bonkers - it means that in order to use npm safely, I have to trust that not a single one of those 380 unique dependencies has been hijacked in some way. When I update npm, I'm trusting that the npm maintainers, or the maintainers of their dependencies, haven't blindly pulled in a compromised "security update". And `npm` is in no way unique here in terms of dependency count.

So this problem is limited to NPM, as far as the potential impact of a single compromised package goes.

Re: Backdoor in event-stream library dependency

#347

Post by cabaalis » Mon, Nov 26, 2018, 9:23 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…

If you no longer want to maintain a package, and you do not have a trusted source to hand it off to, the right thing to do is let it wither.

If the package remains relevant, someone will eventually fork it. The burden of trust is no longer on your shoulders.

Re: Backdoor in event-stream library dependency

#348

Post by AndrewGaspar » Mon, Nov 26, 2018, 9:29 PM UTC

PurpleBoxDragon wrote: post #231

jabberthemutt wrote: post #199

Earlier quoted context omitted.

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

Is it ethical to use code while not agreeing to the license it is provided under?

The license doesn't say "You can't call the author out when they make a bad decision"

Re: Backdoor in event-stream library dependency

#349

Post by jolmg » Mon, Nov 26, 2018, 9:29 PM UTC

newnewpdro wrote: post #304

albinofrenchy wrote: post #172

Earlier quoted context omitted.

Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work. If this is an indictment of anything, it's an indictment of the entire NPM ecosystem -- it's been the wild wild west for years; haphazardly using whatever NPM install gives you is baked into the culture. Sure, Dominic is an active participant in that culture but it seems to me that it is impossibl…

> Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work. Linux didn't always have a giant user base, and it wouldn't have gotten there without strong leadership having a sense of pride and responsibility.

I'm curious if anyone knows how it really has developed. Has anyone documented the history? Do I understand correctly that right now it's a hierarchy with Linus at the top and levels of "Lieutenants" managing increasingly more detailed levels of subsystems. How was development organized before? Are the developers that are paid mostly on the top or the bottom of the hierarchy? Are the proportions of paid developers very distributed among different companies or does a major portion of them belong to one company?

Re: Backdoor in event-stream library dependency

#350

Post by stordoff » Mon, Nov 26, 2018, 9:33 PM UTC

perfunctory wrote: post #96

M2Ys4U wrote: post #70

Earlier quoted context omitted.

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

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

> If you sell your used car and it gets used to rob a bank, did you act immorally?

If he transfers it knowing other people are going to use it, and don't tell then them, then they cut the brakes, that's a problem. It's not just that it was sold, but people continue to use it and weren't told. That's a different situation.