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

491–500 of 509 posts

Re: Backdoor in event-stream library dependency

#491

Post by yuchi »

stefan_ wrote: post #338
yuchi wrote: post #325

Earlier quoted context omitted.

This was, from the eyes of npm Inc. and everyone else a completely legitimate ownership transfer. There was a "human error" (Domenic trusting the wrong person) that was completely unpreventable by technological means. There was no hijacking involved.

There is also never hijacking involved when the SSH key of my server changes, but that doesn't mean I trust SSH Inc. to verify that for me.

In your metaphor this would be not one of your servers, but a customer’s one. Then the customer says: «oh yes, we changed the keys, it’s all ok».

Re: Backdoor in event-stream library dependency

#492

Post by tjholowaychuk »

zeroname wrote: post #463
tjholowaychuk wrote: post #255

Earlier quoted context omitted.

Easy for people who have zero packages and no pressure to say. Don't contribute to OSS and you have no problems. If these huge companies profiting off OSS work actually contributed financially and with time, maybe maintainers would happily remain maintaining.

> Easy for people who have zero packages and no pressure to say. If you have this "no warranty, no responsibility" attitude then how can you have pressure to maintain anything? How does that translate into pressure to hand off the project to strangers? Nobody asked for that. > Don't contribute to OSS and you have no problems. Yes, please don't contribute if you have this kind of attitude. It's harmful. If you can't m…

Dozens of emails / notifications, people pinging / bothering you on multiple platforms, multiple emails, etc.

It's stupid to blindly trust someone's code, regardless of who they are of if they are the current maintainer, that is not how you build secure software.

If you want to start some organization which vets people for maintainers go for it, but don't expect maintainers to do it, I can guarantee you that thousands of maintainers do not. You're responsible for what ends up on your servers.

Re: Backdoor in event-stream library dependency

#493

Post by zeroname »

tjholowaychuk wrote: post #492
zeroname wrote: post #463

Earlier quoted context omitted.

> Easy for people who have zero packages and no pressure to say. If you have this "no warranty, no responsibility" attitude then how can you have pressure to maintain anything? How does that translate into pressure to hand off the project to strangers? Nobody asked for that. > Don't contribute to OSS and you have no problems. Yes, please don't contribute if you have this kind of attitude. It's harmful. If you can't m…

Dozens of emails / notifications, people pinging / bothering you on multiple platforms, multiple emails, etc. It's stupid to blindly trust someone's code, regardless of who they are of if they are the current maintainer, that is not how you build secure software. If you want to start some organization which vets people for maintainers go for it, but don't expect maintainers to do it, I can guarantee you that thousand…

> Dozens of emails / notifications, people pinging / bothering you on multiple platforms, multiple emails, etc.

Two options:

1. Stop supporting the package, mark it as deprecated, ignore/delete the spam

2. Hand over project to a stranger, endangering all of your users

One of these options is irresponsible, the other one isn't. I'm not asking anyone to do something for me, I'm asking them to not do something for the sake of sanity.

> It's stupid to blindly trust someone's code, regardless of who they are of if they are the current maintainer, that is not how you build secure software.

I agree, but both of us know that pretty much the entire Javascript ecosystem is exactly that stupid. Let me ask you: What have you personally done to vet your dependencies? Have you used Babel or any of the other popular Javascript packages that have a huge dependency tree? If you have, chances are you are effectively blindly trusting all the developers in that tree. You're not checking every single commit that goes into it.

> If you want to start some organization which vets people for maintainers go for it, but don't expect maintainers to do it, I can guarantee you that thousands of maintainers do not.

I don't expect that they do, I expect that if they fuck up that their reputation takes a hit. That would some incentive for not fucking up. Instead, there isn't even any consensus that this guy fucked up. He's taking no responsibility whatsoever.

Re: Backdoor in event-stream library dependency

#494

Post by geocar »

geocar wrote: post #214
evan_ wrote: post #208

Earlier quoted context omitted.

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 .

Aha: It's:

    npm_package_description = 'A Secure Bitcoin Wallet';

Re: Backdoor in event-stream library dependency

#496

Post by meowface »

Ayesh wrote: post #464
meowface wrote: post #445

Earlier quoted context omitted.

Yes, I am in this situation right now, actually. I have a project with around 700 stars on GitHub with over a million downloads per month (according to PyPI) which I no longer have the time, interest, or willpower to continue maintaining. I placed an open call to find a new maintainer months ago, and have received many requests. Every single request I've received has been roughly as shady as the request sent to event…

This is good maintainership right here! For outsiders, it looks like the maintainer is greedy to keep the project to themselves. The bug reports pile up, and dozens of people are offerring to maintain. And then insults start to come up, because it looks like you don't want to hand it over. If you want to take over a project, you just earn the trust if the current maintainer, be it patches for existing PRs, finding se…

Thank you. Exactly.

Re: Backdoor in event-stream library dependency

#497

Post by wpietri »

geezerjay wrote: post #483
wpietri wrote: post #356

Earlier quoted context omitted.

Definitely. One of his coworkers has a great thread about this, including on how he has hundreds of libraries in use: https://twitter.com/andrestaltz/status/1067157915398746114 Many, many people treat open-source projects like consumer products. Except the paying-money part, of course. That they're happy to leave out. This is a systemic problem, and blaming one guy won't solve anything. Especially since so many are b…

> Many, many people treat open-source projects like consumer products. To me, this linr of argument completely misses the point. It's entirely immaterial how a FLOSS project is treated. This problem is essentially an identity hijacking problem. The community trusted the old maintainer, but then he screwed up by enabling an attacker to essentially take over his identity and thus create and exploit a major vulnerabilit…

It is not immaterial. Projects are run by human beings, and economics does not cease to exist once a computer is involved. People's expectations were out of line for what they were paying.

I also think the words "community" and "trust" are being badly abused here. A community is a relationship of mutuality. Most of the people affected here never did a thing. They were leeches, not participants. A healthy community would have looked at the guy laboring overtime for free and said, "Hey, buddy, let's split that load up." And most of the people who benefited from his work didn't even know his name. They didn't trust him; they trusted the system.

He owed those people nothing. He gave them more than that: a good-faith effort to find a new maintainer.

Re: Backdoor in event-stream library dependency

#498

Post by [deleted] »

jerf wrote: post #315
pcwalton wrote: post #291

Earlier quoted context omitted.

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.

I don't think you have to get all the way to the Go community's opinions to be in a reasonable place; I think the JS community is at a far extrema in the other direction and suffer this problem particularly badly, but that doesn't mean the other extreme is the ideal point. I don't personally know of any other community where it's considered perfectly hunky-dory to have one-line libraries... which then depend on other…

[deleted]

Re: Backdoor in event-stream library dependency

#499

Post by WorldMaker »

slg wrote: post #399
WorldMaker wrote: post #378

Earlier quoted context omitted.

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…

Does npm currently control versioning to any extent? A quick Google search seemed to show that they only make versioning recommendations with no real rules. If you are operating from the premise that the maintainer is potentially compromised, why would you trust them to stick to the semantic versioning spec?

Admittedly, npm can't control the "semantic" in semver as that will likely always be a human judgment call, but npm has a lot of general control in package versioning. Their semver recommendation [1] is pretty strong in their docs, and embedded in the default version range specifiers ^ (a previous default) implies semver major, and ~ (the current default) implies semver major.minor.

Other small ways that npm controls versioning is that it does not allow you to publish the same version number for a package [2], and `npm version` [3] is often the most common tool for incrementing version numbers, which itself provides a number of semver-focused shortcuts.

So yes, it's certainly a common expectation in npm that packages follow semver, largely due directly to npm's documentation and tools support.

> If you are operating from the premise that the maintainer is potentially compromised, why would you trust them to stick to the semantic versioning spec?

The suggestion was that in the current case the maintainer changed with no warning. One warning system that npm provides is semver major breaking changes. npm does have enough version control (for instance, the part not allowing previously submitted version numbers to be reused) that they could theoretically force all new versions submitted after a maintainer change to jump a semver major version. That would at least send a signal to the large number of developers that don't pay attention to the changelogs of minor and patch versions (and may naturally have a ^ or ~ scope in their package.json) to at least check the changelog for breaking changes. That's possibly the easiest "sufficient" fix for this problem of an otherwise unannounced maintainer change.

[1] https://docs.npmjs.com/about-semantic-versioning

[2] https://docs.npmjs.com/cli/publish.html

[3] https://docs.npmjs.com/cli/version

Re: Backdoor in event-stream library dependency

#500

Post by jonknee »

nneonneo wrote: post #386
jonknee wrote: post #165

Earlier quoted context omitted.

> you’re trusting random strangers on the Internet to run code on your systems I mean that's pretty much how the world works. Even running Linux is trusting random strangers on the internet. Most of the time it works pretty well, but obviously it's not perfect. Even the largest companies in the world get caught with security issues from open source packages (remember Heartbleed?).

When I visit a random website, it is very hard for that website to compromise my computer or my private data. The only really viable way is a zero-day in my browser, or deception (e.g. phishing, malicious download). When I install an app on my iPhone, it is very very hard for that app to compromise my phone or my private data. In both of these cases, I can download and run almost any code, and be fairly confident tha…

What does that have to do with development? My point was nearly everyone uses libraries that are written by strangers from the internet. It mostly works.
Post reply on HN