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

291–300 of 509 posts

Re: Backdoor in event-stream library dependency

#291

Post by pcwalton »

jerf wrote: post #80
dmortin wrote: post #22

Earlier quoted context omitted.

If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.

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

Re: Backdoor in event-stream library dependency

#292

Post by pcwalton »

kevin_b_er wrote: post #158
raesene9 wrote: post #81

Earlier quoted context omitted.

Unfortuntely, whilst npm is the largest source of packages, it's not the only place where this problem exists. Most programming languages have this issue to one degree or another, which is that they have a package management repository where there is no curation of content, and generally no package signing (there are some cases where that exists, but the take-up isn't always great). The challenge is that this now see…

Yes. The fast moving package management dependency hell seems to be spreading, but I believe its root comes from npm/javascript. If we see it elsewhere it is because it is borrowed from javascript as it was seen as "the future" of software development.

The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5.

Re: Backdoor in event-stream library dependency

#293

Post by StavrosK »

samirm wrote: post #251
StavrosK wrote: post #29

I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…

Why would the average joe trust something like this? Your FAQ says each maintainer is vetted and handpicked, but nothing about criteria or how they're picked. Do you mind explaining this vetting process a little more? How can we be sure that something like this flatmap thing doesn't happen on codeshelter?

Sure! They're either people I know personally and trust (and hopefully people will trust me to do this transitively) or they are people who are already authors of popular libraries and have shown they are experienced in maintaining OSS projects and trustworthy (since they're already pushing code to people's machines).

Trust is definitely an issue here, and trust is something you build, so I hope we'll be able to build enough trust to let people not think twice about adding their projects.

Re: Backdoor in event-stream library dependency

#294

Post by STRML »

Scoping dependencies to their author by default would help (not eliminate) this problem.

For example, if this had been @dominictarr/event-stream the entire time, and he chose a new maintainer, that would then by definition change the name of the package to @right9ctrl/event-stream, requiring all users to intentionally change their dependency.

Yes, it's painful. But it prevents getting caught out by a malicious patch release.

That said, the whole github/npm relationship is broken to begin with. No simple mechanism exists that I'm aware of to verify that a tag as pushed to GitHub is exactly the same as what is published to npm. And due to various prepublish hooks, it can be very difficult to actually prove this. One solution would be GitHub support for building & publishing packages, with a Travis-like build log, so users can be assured that the package as it sits on npm actually was built from expected source.

@right9ctrl could have just avoided committing this entirely, and just published a malicious patch release. If he had done that for a few days then published another that removes the injection, it might have gone unnoticed for months.

Re: Backdoor in event-stream library dependency

#295

Post by michaelmrose »

bigmanwalter wrote: post #247
michaelmrose wrote: post #166

Earlier quoted context omitted.

How about just not transfer ownership of the original name. Let foo become foo-new or go from john/foo to bob/foo whichever is appropriate thus ensuring that only those who affirmatively added bob/foo or foo-new are ever effected. Vetting new maintainers sounds like hard work that you might not feel like doing for free no problem just don't do it and don't give them the damn name.

That's fundamentally not how identification on the Internet works. You are whoever you say you are. It's absurd to tie identity to a physical person.

You are incorrect you are who you can prove who you are.

I can prove any of a number of identities scattered around the internet most of which are in fact my real name. Pretending that this is trust less is just not real.

Example I know from a wide variety of sources that certain projects are trustworthy even if I can only verify a pseudonym that itself is trustworthy and infer that authors other projects are trustworthy.

Accounts emails and domains are all useful tools even if not perfect.

People don't normally put years into developing trust in order to distribute malware. It's normally a low effort affair.

Not giving maintainership to random people who send you an email or selling projects to skeevy companies seems like a good way to avoid 80% of issues kind of like washing your hands can prevent a lot of colds.

Re: Backdoor in event-stream library dependency

#296

Post by abecedarius »

ivanhoe wrote: post #120

IMHO there are only 2 long-term solutions to this type of problems: 1) Reduce the number of external dependences as much as possible 2) Pay authors to properly maintain the packages that you rely on. If you use them on commercial projects it's the first and the cheapest possible security measure you should invest in.

The best solution is a module system that obeys the principle of least authority. An event-stream library shouldn't be able to find your cryptocurrency wallet, or communicate back to its author either.

Re: Backdoor in event-stream library dependency

#297

Post by meowface »

jsd1982 wrote: post #234
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.

Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.

At the very least, a few years of regularly contributing to Node projects on GitHub. The account he handed it over to has essentially zero history: https://github.com/right9ctrl. The one repo they have is just a copy of https://github.com/barrysteyn/node-scrypt.

I'm not against handing over projects, but some vetting has to be done.

Re: Backdoor in event-stream library dependency

#298

Post by meowface »

AnaniasAnanas wrote: post #259
trickstra wrote: post #201

Earlier quoted context omitted.

exactly, transferring a package to an unknown person is not only giving them access to the code but also to all the people who already trust that code

To be honest that kind of your fault for trusting that code. Heck, the commits were not even signed as far as I know, had they been signed the change of "ownership" would have been clear.

Makes no difference if they were signed or not. He handed over the NPM package, not the GitHub repo. NPM doesn't show commit history or authors and has no connection to GitHub; you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package.

Re: Backdoor in event-stream library dependency

#300

Post by paavoova »

gwbas1c wrote: post #204

To the outsider, these threads assume so much context that they don't make sense. (Of course, if you are a computer or you have intimate knowledge of these tools, and these threads make perfect sense!) Who, what, where, why, and how need to be answered. Usually when there's a link like this on hacker news, one of the highly moderated comments explains the situation in ways that don't require as much context as a typi…

And even if you understand what's going from the OP, you're unable to get full context as Github hides the majority of comments in the issue. I've clicked "Load more..." 5 times and still over 100 comments are hidden. Incredibly annoying.
Post reply on HN