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

481–490 of 509 posts

Re: Backdoor in event-stream library dependency

#481

Post by lambdadmitry »

rosser wrote: post #256
ummonk wrote: post #206

Earlier quoted context omitted.

To be clear, you're arguing that people should be judged on their identity and background rather than the merit of their contributions?

Skimming those links, I think the position is that people are already being judged on their identities before they're judged on the merit of their contributions, not that they should be. The extent and congruence of the findings regarding, e.g., blinded vs non-blinded resumes alone should put the lie to the idea that a true "meritocracy" is something humans can actually meaningfully do at this point.

That's a contrived "no true Scotsman" right there. Also quite a few people argued that democracy should be replaced by dictatorship on similar grounds: "look at America, it's clear that democracy is shit".

Imperfect realization doesn't mean the ideal is invalid (except when that imperfection is inherent to the ideal). You can argue for more equal, more meritocratic community; tearing it down because it's not already perfect is disingenuous and destructive.

Re: Backdoor in event-stream library dependency

#482

Post by slavik81 »

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…

> If the original author has no use for the project anymore and someone offers to take it over from them, why should the author be expected to refuse?

People who use your project place their trust in you. If you pass that trust on to another developer without your users' involvement, then that developer's actions reflect on your reputation. Why? Because you've not given me the option of only trusting you. Your policy made it a package deal.

It's kinda like how I can't tell Bob about anyone's Christmas gift. He sometimes tells Fred the Loudmouth, who tells everyone and ruins the surprise. Bob never ruins the surprise directly, and he always asks Fred to keep it a secret, but it doesn't matter. I still can't trust Bob, even if Bob's only mistake is that he trusts in the wrong people.

Re: Backdoor in event-stream library dependency

#483

Post by geezerjay »

wpietri wrote: post #356
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…

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 vulnerability in his behalf.

Re: Backdoor in event-stream library dependency

#484

Post by chopin »

nneonneo wrote: post #346
joekrill wrote: post #324

Earlier quoted context omitted.

I don't see how this problem is limited to just NPM. This is a problem of any package manager. Or any software distribution system in general, really. Look at all the malware found on the Play Store and the Apple Store. Unless you're willing to meticulously scrape through every bit of code you work with you're at risk. Even if you can, what about the OS software? How about the software running on the chipset? This is…

NPM is quite a different software distribution mechanism than a typical app store. In an app store, apps are self-contained packages with low to no dependency on other apps in the store, meaning that a single compromised or malicious app can only really affect that app's users. The OS may also isolate apps from one another at runtime, further limiting the amount of damage such an app can do (barring any OS bugs). On…

Most Linux distribution package managers also draw in dependencies (alas not that much as npm) automatically. You have to trust that all are vetted correctly.

Re: Backdoor in event-stream library dependency

#485

Post by Sacho »

bsder wrote: post #286
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.

> I'd much rather have my dependencies die than start silently pulling in a fork. Maybe, but Node had that issue too, no? Remember leftpad? So, lots of people in the Node ecosystem don't agree with you.

No, that was a different issue. Left-pad was removed from npm, not just left abandoned and unmaintained. The people using it were happy to still use the (unmaintained) version of it.

Re: Backdoor in event-stream library dependency

#486

Post by lmm »

kurtisc wrote: post #210
lmm wrote: post #59

Earlier quoted context omitted.

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…

Would you have distrusted this maintainer though? If someone takes it over and publishes what appear to be real bug-fixes, I'd imagine most people would trust them. The same goes for trusting forks, or trusting the original developer not to hand over access.

> Would you have distrusted this maintainer though? If someone takes it over and publishes what appear to be real bug-fixes, I'd imagine most people would trust them.

Quite possibly. But I'd make a conscious decision to do it, and certainly wouldn't be in any position to blame the original maintainer.

Re: Backdoor in event-stream library dependency

#487

Post by raesene9 »

merb wrote: post #395
raesene9 wrote: post #130

Earlier quoted context omitted.

So you reckon that people who publish open source software should be liable for flaws/vulnerabilities in their code? It's a bold assertion, I'd be interested to see if you can provide any case law where it's been tested.

it depends. laziness can actually be used against you. even in european countries.

But on this topic specifically, I've never heard of Open source software authors being held liable in any fashion for software they've released in any country.

I'd be interested to hear if such precedent existed.

Re: Backdoor in event-stream library dependency

#488

Post by GordonS »

Are there actually any future plans for JavaScript to add a decent standard library?

Coming from other languages, the lack of built-in functions seems crazy, and the NPM situation just weird. An empty template I use for bootstrapping jquery-based web apps, based on using Gulp 4 for transpiling ES6, SASS compilation etc, has a node_modules folder with 23,268 Files across 3,080 Folders!

Re: Backdoor in event-stream library dependency

#489

Post by whitelister »

whitelister wrote: post #170

Is anyone going to bother crawling through all dependents of this library, extracting the package.json descriptions to find the proper key to decrypt the string and find out which package was being targeted?

The aes256 key is 'A Secure Bitcoin Wallet'.

Re: Backdoor in event-stream library dependency

#490

Post by Ayesh »

altfredd wrote: post #434
devman0 wrote: post #307

Earlier quoted context omitted.

When you sell your car there is generally a title transfer. A process which lets everyone know that the car is no longer yours. I think the largest gripe here is that the original maintainer let the new, unknown maintainer commit to his repo and publish under the already established package name instead of making him fork it and publish as a new package.

There is nothing wrong with publishing rewritten package with same name under full supervision of original developer . Transferring control generally implies full trust, and Dominic haven't established any trust with new developer. He didn't even ask them for their real name!

If someone's determined, they can always create a legit looking GitHub account, submit a few PRs (they did, in this case), gain trust, and _then_ deliver the malicious code. It just takes time.

But this trust part seems to work pretty well. You need to be trusted to be a Debian package manager, and I volunteer as a Drupal code review admin where we require all contributors to have a real name, and there is a back and forth discussion for a few days until we mark the user as vetted.

Post reply on HN