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

371–380 of 509 posts

Re: Backdoor in event-stream library dependency

#371

Post by aaaaaaaaaab »

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

Is there a showcase of open-source projects managed/developed according to this post-meritocratic system?

Re: Backdoor in event-stream library dependency

#372

Post by preommr »

tjholowaychuk wrote: post #252
gregknicholson wrote: post #145

Earlier quoted context omitted.

He's been too naive and creduluous in judging a person based on limited information. His coding skills aren't in question — the software was fine while he was still in charge of it. I suspect Dominic didn't see himself as the maintainer of the package, but as a maintainer of a copy of the package (like how git is designed to work). With this perspective, of course someone else can be a maintainer. The problem is that…

Not to blame them NPM, they're great people, but I often get requests from random people going through NPM support to use an existing name (saying they will bump major). The centralized naming scheme is to blame here, it normalizes these "cute" names and users have demanded these since day one. They could/should have probably been scoped from the beginning, or people should just stop trying to capture fancy names. I…

> NPM support to use an existing name (saying they will bump major).

Sorry, could you please explain what this means? I keep seeing comments about bumping version numbers (e.g. the right9ctrl did some shenanigans with versioning).

Re: Backdoor in event-stream library dependency

#373

Post by jrochkind1 »

slg wrote: post #274
jrochkind1 wrote: post #218

Earlier quoted context omitted.

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

Without locking in to a specific version you are trusting the maintainer in perpetuity. That trust extends to things like reviewing their own dependencies, reviewing pull requests, adding other maintainers, or just flat writing bad code. I don't blame the author any more in this instance than if any of those other possible examples occurred. Security patches are part of my original point regarding why it is bad for a…

And yet, to produce the software that nearly any employer or client in 2018 wants at the price they want, requires using open source dependencies without manually reviewing every diff from every version released.

I don't really understand what you are trying to suggest.

Yes, whether we realize it or not, we are trusting the maintainers of our dependencies. Sometimes that trust is misplaced. That might lead us to try and avoid a particular dependency or maintainer in the future when it happens. And then it'll happen again.

We've built an ecosystem around using open source dependencies. Isn't that what the open source dream was? You might not like it, but not liking it doesn't make it realistic to develop software for money without using all sorts of open source dependencies for which you can't personally vouch for every line of code. I'm seriously not sure what it is you are trying to advocate for.

Re: Backdoor in event-stream library dependency

#374

Post by gkya »

faho wrote: post #351
joshmanders wrote: post #266

Earlier quoted context omitted.

Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.

It's not. Not to that degree. Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation. And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively. Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibi…

Add to that the fact that while the Unix way works well for connecting certain types of programs through pipelines and/or shell scripts, those programs themselves are written usually in C or Perl, Python &c, which are languages that have big standard libraries. It might be reasonable to assume that while programs that conform to Unix philosophy may constitute useful building blocks for end user or sysadmin tasks, more complex programs, even those "building blocks" themselves are better off with languages that provide them with a rather large, well-though-out toolset that's built as an integrated whole, i.e. a standart library.

Re: Backdoor in event-stream library dependency

#375

Post by jrochkind1 »

ryandrake wrote: post #290
jrochkind1 wrote: post #218

Earlier quoted context omitted.

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

Interesting, thanks for the explanation. I was not familiar with the npm ecosystem. If the ecosystem has a cultural norm of "blindly" updating dependencies regularly, that could be the root problem. If you're going to live on the bleeding edge, rolling the dice over and over, you're going to have a bad roll once in a while. Your world seems more sane, and I (also not in node, JavaScript, npm etc.) generally follow th…

You misunderstood me.

I don't work much with npm. I work mostly with ruby, using bundler for dependency management.

And i update my dependencies to new patch releases _all the time_ without reviewing the releases individually. I think most other ruby devs do too. My understanding of the intention of "semantic versioning" is to _allow_ you to do that.

My projects have dozens if not hundreds of dependencies -- don't forget indirect dependencies. (I think npm-based projects usually have hundreds+). How could I possibly review every new patch release of any of these dependencies every time they come out? I'd never get any software written. If I never updated my dependencies anwyay, I'd be subjecting my users to bugs that had been fixed in patch releases, and wasting my time debugging things that had already been fixed in patch releases.

This is how contemporary software development using open source dependencies works, for many many devs.

Re: Backdoor in event-stream library dependency

#376

Post by igolden »

jrochkind1 wrote: post #232

it's kind of impressive this compromise was discovered _at all_. Anyone know the story of how it was? There seems to be a lot of back story before the linked issue begins. I'm interested in who noticed the compromise, when, and how. Because with open source, noticing the compromise is about the _best_ we can expect from a "worst case".

A random, lucky find: https://github.com/remy/nodemon/issues/1442

Re: Backdoor in event-stream library dependency

#377

Post by semi »

joshmanders wrote: post #266
gkya wrote: post #220

Earlier quoted context omitted.

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

Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.

I don't follow your comparison. What parts of the Linux ecosystem have a single person maintaining a large multitude of packages?

Looking at the kernel itself you see a hierarchy where people are only responsible for small segments of the kernel.

Looking at a standard distro like Debian, which makes this easily available at https://www.debian.org/devel/people you'll see that most individuals are only responsible for a handfull of packages, with the bulk having a team responsible for them.

Re: Backdoor in event-stream library dependency

#378

Post by WorldMaker »

slg wrote: post #274
jrochkind1 wrote: post #218

Earlier quoted context omitted.

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

Without locking in to a specific version you are trusting the maintainer in perpetuity. That trust extends to things like reviewing their own dependencies, reviewing pull requests, adding other maintainers, or just flat writing bad code. I don't blame the author any more in this instance than if any of those other possible examples occurred. Security patches are part of my original point regarding why it is bad for a…

A lot of users had it locked to a semver major version or major.minor version, which isn't necessarily trusting the maintainer "in perpetuity", just the current development track.

Is a change between maintainers a semver-major breaking change? Several people have suggested that that is a baseline that npm could easily automate/enforce. That would have at least sent a community signal to re-review/re-audit the package in light of a new maintainer.

Re: Backdoor in event-stream library dependency

#379

Post by trickstra »

tschellenbach wrote: post #168
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.

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)

the mindset where handing over a package with 2 million weekly downloads to a complete stranger is a totally OK thing to do IS npm specific.

Re: Backdoor in event-stream library dependency

#380

Post by tjholowaychuk »

preommr wrote: post #372
tjholowaychuk wrote: post #252

Earlier quoted context omitted.

Not to blame them NPM, they're great people, but I often get requests from random people going through NPM support to use an existing name (saying they will bump major). The centralized naming scheme is to blame here, it normalizes these "cute" names and users have demanded these since day one. They could/should have probably been scoped from the beginning, or people should just stop trying to capture fancy names. I…

> NPM support to use an existing name (saying they will bump major). Sorry, could you please explain what this means? I keep seeing comments about bumping version numbers (e.g. the right9ctrl did some shenanigans with versioning).

Ah sometimes you get people asking to use a name such as my "log" pkg in npm, but bumping from 2.0 to 3.0 so that dependencies aren't messed up. Assuming the person has no bad intentions I think it's a perfectly reasonable request.

I ignored this particular request via email a few times, because I just really don't want to spend time dealing with Node stuff. You then get a request from NPM support asking the same thing, so I agreed to it, that's all it takes to get access to a package really.

I think from now on I'm just going to tell people to come up with a different name, this wouldn't be a problem if the names were scoped by default.

Post reply on HN