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

321–330 of 509 posts

Re: Backdoor in event-stream library dependency

#321

Post by tomjakubowski »

pcwalton wrote: post #292
kevin_b_er wrote: post #158

Earlier quoted context omitted.

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.

In case anyone is unfamiliar with Perl's version history like I was, Perl 5 and CPAN date to 1994.

Re: Backdoor in event-stream library dependency

#322

Post by tomjakubowski »

btbuildem wrote: post #278
cellis wrote: post #246

Earlier quoted context omitted.

Not really: http://www.paulgraham.com/schlep.html

Schlep is precisely a business opportunity -- tedious drudgery that you have to do regularly OR can pay and not worry about it again.

I think GP was responding to the second paragraph, which suggested that this business might not be viable just because it hadn't yet been tried.

Re: Backdoor in event-stream library dependency

#323

Post by gregknicholson »

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…

> The centralized naming scheme is to blame here

It would have been better just to use URLs, so if you see "npm install https://github.com/dominictarr/event-stream" then it's clear you're trusting "github.com".

(Yes, DNS is centralised. That can be fixed independently.)

Re: Backdoor in event-stream library dependency

#324

Post by joekrill »

thrower123 wrote: post #236

NPM is just a mess, and the whole culture and ecosystem that surrounds it. Micropackaging does make a little bit of sense at least in theory for the web, where code size ought to matter, but in practice it's a complete shitshow, and leads to these insane dependency paths and duplication and complete impossibility to actually keep abreast with updates to dependencies, much less seriously vet them. The insidious threat…

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 exactly why no one in their right mind should be advocating for electronic voting. There's simply no way to mitigate this problem completely.

Re: Backdoor in event-stream library dependency

#325

Post by yuchi »

stefan_ wrote: post #114
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 must be the fifth incident that could have been readily prevented if npm simply required signing for it's packages. Just do the same thing we have for SSH: on first connection (installation), ask if you trust the other side. That goes into your authorized_keys (lock file). If you connect again (update) and the key changed, print a big scary warning. No blockchain needed.

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.

Re: Backdoor in event-stream library dependency

#326

Post by gregknicholson »

antocv wrote: post #82

Well this undermines everything dominictarr has done for secure scuttlebutt and other projects, including datproject and its connection to Knight Foundation. "Oops, I just gave the repo to an unkown dude", OK. Sure. Just replace "unkown dude" with "to my colleagues at 5 eyes secret service organization" This kind of mistake is not a mistake, not from a dude like dominic.

How many people here seriously thought “Gee, I was trusting Dominic, but now he's broken my trust”?

So who were you trusting?

What's the risk for Scuttlebutt, Dat and the Knight Foundation? Dominic will be the only maintainer of a project and he'll foolishly hand over maintainership to a government spook?

Re: Backdoor in event-stream library dependency

#327

Post by yuchi »

mehrdadn wrote: post #320

I see a way to solve this with technology and that is for tools to allow secondary developers to publish on the package repository, but after a mandatory N-day delay. The main owner can then always have a chance to review.

And then attackers would just wait that N days before pushing exploits.

Re: Backdoor in event-stream library dependency

#328

Post by Severian »

AdmiralAsshat wrote: post #207

Seems like we need a linter that can look for binary, hex, or otherwise encrypted-looking data in source code (I have no idea how you'd teach the linter to look for anything that "looks like gibberish"--I'd leave that to people smarter than me). From past experience with other popular apps that get backdoored with bitcoin miners, anything intentionally obfuscated in what is supposed to be an open source application i…

You could measure the entropy of single lines and determine if the entropy is high. Although you'd probably get a lot of false positive.

Re: Backdoor in event-stream library dependency

#329

Post by malvosenior »

pier25 wrote: post #257

The problem with JS (Node and browser) is that the standard library is pretty much useless. What JS/NPM needs is some sort of certification program for secure libraries that would fill the void of the lack of a standard library. NPM of course would give a warning when installing a non certified library. This would be a tremendous effort, but it would really be the only way for NPM to survive in the long term. NPM is…

> NPM is one of the reasons we've moved to Go for our server side code.

It's one of the reasons, but far from the only reason. With Go, Python, Rust, Swift... is there any reason to use Javascript on the backend? Most attempts I see to "share" code between the browser and the server end up adding needless layers of abstraction and complexity.

Re: Backdoor in event-stream library dependency

#330

Post by yuchi »

staltz wrote: post #285

I think the underlying issue here is ownership of a package, that is the sensitive thing that was given away. This is why I prefer to publish scoped packages, e.g. `@dominictarr/event-stream` not `event-stream` onto npm, so that ownership doesn't need to be given away. If someone wants to give continuity to the project, it can be done under a different fork. Also, it's important to pin versions for immutability. Naiv…

Actually in such a case Domenic would have transferred the ownership of the package anyway, probably retaining some power in the process, but the major harm would have been done already.
Post reply on HN