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

191–200 of 509 posts

Re: Backdoor in event-stream library dependency

#191

Post by lozenge »

teej wrote: post #75
floatingatoll wrote: post #14

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

How does this work practically when the vuln exists only in the minified version of the code?

Most projects are already bundling and minifying code themselves. Any cookiecutter type tool will say that up.

Re: Backdoor in event-stream library dependency

#192

Post by malvosenior »

quaunaut wrote: post #185
malvosenior wrote: post #180

Earlier quoted context omitted.

antocv, like many of us values security over feelings. If you want to run maybe insecure code to help be supportive of someone, go for it. His point is valid though and you can ignore it at your own risk.

There's a significant difference between caring about security and one's reputation and jumping to conclusions as antocv has here. Dominic clearly handled this poorly, but there isn't a need to exaggerate for what he "could" have done as a means of impinging his reputation further than what's been done here and now.

Exploring possible threat vectors is not "jumping to conclusions". Again, security is important to many people.

Re: Backdoor in event-stream library dependency

#193

Post by program9 »

xvector wrote: post #89
sergiotapia wrote: post #42

A lot of butthurt people railing on the guy. Maybe he just doesn't care anymore about a dead package he has no intention of maintaining. Blame yourselves devs, not the author who donated hours and hours of free work for your benefit.

It’s about ethically handing off a package. No one is forcing him to maintain it. But when you make a package used by millions of people, you become responsible for their safety. To then hand over a package to a hacker or unknown party is just morally wrong. Just mark it as deprecated and call it a day, like a normal and responsible person.

No -- downstream devs are responsible for the safety of their own apps, users, and org.

Re: Backdoor in event-stream library dependency

#194

Post by [deleted] »

nine_k wrote: post #163
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…

Open-source projects greatly depend on reputation. E.g. I can trust the people behind git: some of them may be poor UX designers, but they won't let out a version that eats my files, or is backwards-incompatible. If a completely different team forked git, I would be quite wary to use the fork outright for my daily work. When all long-term maintainers stop maintaining a project, the last person leaving should turn off…

[deleted]

Re: Backdoor in event-stream library dependency

#195

Post by JustSomeNobody »

eeZah7Ux wrote: post #86
_wmd wrote: post #36

Earlier quoted context omitted.

This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever : THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT…

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

Re: Backdoor in event-stream library dependency

#197

Post by icebraining »

lmm wrote: post #59
floatingatoll wrote: post #14

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

Lack of code signing is what's harmful here. My maven projects' dependencies are technically all pinned, but updates are just a "mvn versions:use-latest-releases" away. But, crucially, I have a file that lists which GPG key IDs I trust to publish which artifacts. If the maintainer changes, the new maintainer will sign with their key instead, my builds will (configurably) fail, and I can review and decide whether I wa…

What if the maintainer had also given away the key used to sign the previous releases?

I know, it doesn't make much sense why would anyone do that, but then again, I think "why would you that?!" feeling is part of what is triggering the negative reactions here. We just don't expect people to do things we wouldn't.

Re: Backdoor in event-stream library dependency

#198

Post by zeroname »

Everyone is fired.

If you insist on pushing out hundreds of packages on npm, then drop support for them and hand over rights to random strangers, you are acting completely irresponsibly. You shouldn't be given a pass because you're doing it all voluntarily. Your professional reputation should suffer for it.

Re: Backdoor in event-stream library dependency

#199

Post by jabberthemutt »

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.

Re: Backdoor in event-stream library dependency

#200

Post by always_good »

AndrewGaspar wrote: post #55
tschellenbach wrote: post #26

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

The reasonable answer is that he should absolutely not have handed over publish capabilities to a completely unknown third-party. This seems obvious to me.

Then let me ask you, how long should have dominic let right9ctrl contribute to the project before trusting him and giving him publish capabilities? With hindsight, we know that right9ctrl is going to publish a backdoor the second he gets rights. How long do you make right9ctrl wait? And does that accomplish what you want?

If you think that ownership transfer should exist at all, then the attack vector still exists no matter how long you wait to trust right9ctrl.

Post reply on HN