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

211–220 of 509 posts

Re: Backdoor in event-stream library dependency

#211

Post by zeroname »

21 wrote: post #182
programmarchy wrote: post #123

Earlier quoted context omitted.

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…

> Lieutenants gain authority based on the merit of their contributions Meritocracy is an outdated discriminatory practice. https://postmeritocracy.org/ https://www.theguardian.com/commentisfree/2017/mar/20/merito...

> Meritocracy is an outdated discriminatory practice.

Of course merit is judged subjectively (like anything else), but what exactly is the alternative?

In particular, I don't find anything actionable in that manifesto in regards to decision making.

Re: Backdoor in event-stream library dependency

#212

Post by ummonk »

eropple wrote: post #124
ryandrake wrote: post #118

Earlier quoted context omitted.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

You can, but it's opt-in. At least once with every new project I go "gah, dammit!" because I forget to check in a lockfile, but I sleep better at night. I do not know if NPM lockfiles are transitive, though. Guess I'd better go looking...

As far as I know, you can pin your versions (something I always recommend), but those packages can always pull in other dependencies with version bumps. And NPM in particular encourages a massive plethora of micropackages, so the dependency tree gets extremely large.

Re: Backdoor in event-stream library dependency

#213

Post by [deleted] »

sroussey wrote: post #202
geocar wrote: post #99

Earlier quoted context omitted.

It's attacking a particular package -- some package out there depends on ps-tree directly or indirectly, and its description is the secret key.

Which means there is a finite list to check, unless the package is something internal and not on npm.

[deleted]

Re: Backdoor in event-stream library dependency

#214

Post by geocar »

evan_ wrote: post #208
sroussey wrote: post #202

Earlier quoted context omitted.

Which means there is a finite list to check, unless the package is something internal and not on npm.

from the github issue it looks like a couple people are working on that using publicly available lists, and they've even found a few valid decryption keys, but none that turn the payload into executable javascript

It's AES: Anything the right length will decrypt to something.

Re: Backdoor in event-stream library dependency

#215

Post by ianwalter »

ryandrake wrote: post #118
SpicyLemonZest wrote: post #31

Earlier quoted context omitted.

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

You can, but this package is very low-level so chances are that it's not a direct dependency for many end-users. A lot of popular modules that may be using this module also don't pin dependencies or don't use lock files so that's one problem. A second problem is that when a npm package is transferred to someone else and then a new version is published, there is nothing notifying you that the package in under new ownership. A third problem is that sometimes users might delete their lock files and re-install dependencies when they encounter some versioning issue and are looking for a quick fix without realizing the implications of doing that.

Re: Backdoor in event-stream library dependency

#216

Post by PurpleBoxDragon »

nmg wrote: post #34
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…

The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.

What was he compensated with in exchange for taking on responsibility? Without compensation the contract by which he takes on responsibility is not valid.

Re: Backdoor in event-stream library dependency

#217

Post by Matthias247 »

albinofrenchy wrote: post #172
programmarchy wrote: post #123

Earlier quoted context omitted.

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…

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.

And also important: It even has a giant number of paid maintainers, for who this is their main job.

For those the incentive to continuously maintain things is different than for someone who gets nothing expect more work out of it.

Re: Backdoor in event-stream library dependency

#218

Post by jrochkind1 »

ryandrake wrote: post #118
SpicyLemonZest wrote: post #31

Earlier quoted context omitted.

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

> Why would someone update to a new version of a dependency if they don’t trust the new maintainer?

They didn't know there was a new maintainer, let alone that they didn't trust them.

> In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

Because new versions come out with bugfixes _and_ security patches all the time. In my world (which I'll be clear is not npm), I update all my dependencies to whatever backwards-compat latest version there is, to get advantage of any bugfixes or security patches without having to spend time being aware of every possibly applicable bugfix or security patch. If I spend a day hunting down a bug that ended up having already been fixed in an upstream dependency and I wouldn't have even been subject to it if I had updated... that was a wasted day.

Also if I regularly update, I get security patches without having to have spent time being aware of every one.

This all applies to indirect dependencies (dependency of a dependency) along with direct ones too.

Some of these issues are general to any kind of dependency system. But the particular balance of trade-offs changes in different ecosystems. One thing that seems to be somewhat special in npm is how _small_ and _numerous_ the dependencies are. Npm ecosystem is built upon a large number of very small and discrete dependencies. This has advantages, but the big disadvantage that it becomes very difficult to 'manually' keep track of them, and easy for a bad actor to sneak something bad in.

Re: Backdoor in event-stream library dependency

#219

Post by raesene9 »

dragonwriter wrote: post #189
raesene9 wrote: post #179

Earlier quoted context omitted.

You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software ... really? If that were the case, you'd pretty much wipe out the software industry as it stands today :) I'd be very interested in case law where you can see the users of a service (which might not even disclose what software they use) are able to sue the author of a package used as part…

> You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software Where the type of harm that results is reasonably foreseeable and could have been prevented by reasonable care by the developer (or maintainer; different though often co-occurring roles), I don't see how the general law of negligence doesn't fit. AFAIK, negligence has no open source soft…

Do you think anyone would publish open source software if it was possible that they might be held liable by people who used services or software which included that code at any future date when they had no say in how their code was used??

Really you think that's realistic, given the astonishingly heavy presence of open source software?

Re: Backdoor in event-stream library dependency

#220

Post by gkya »

jhardy54 wrote: post #48
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…

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…

> Especially given that Dominic maintains hundreds of packages

> maintains hundreds of packages

> hundreds

How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.

Post reply on HN