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

351–360 of 509 posts

Re: Backdoor in event-stream library dependency

#351

Post by faho »

joshmanders wrote: post #266
gkya wrote: post #220

Earlier quoted context omitted.

> Especially given that Dominic maintains hundreds of packages > maintains hundreds of packages > hundreds How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.

Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.

It's not.

Not to that degree.

Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation.

And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively.

Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibility for half a thing".

The pieces are just too tiny, which leads to an explosion of packages, which leads to packages being badly maintained.

Re: Backdoor in event-stream library dependency

#352

Post by floatingatoll »

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…

I don’t think any blame is due to the author at all.

Volunteer project ownership is voluntary, and transferring to another volunteer is the only choice other than abandonment for a lot of volunteers. Package repositories don’t support monetization and there’s no pool of volunteers associated with the repository itself to take up maintenance of what otherwise would have been abandoned.

Would we have preferred if the original creator had simply deleted the repository altogether? The last time someone did that on NPM, it generated deafening howls of rage — but here we are today in the non-abandonment scenario, listening to renewed howls of outrage.

Re: Backdoor in event-stream library dependency

#353

Post by MrStonedOne »

bandrami wrote: post #311

So, I'm not a javascript person. I don't know the ecosystem that well. I'm not really even a programmer except at gunpoint, just a sysadmin. But even 5 years ago I remember thinking "400 dependencies for a project is just WAY too many" and imagining something like this. And now I see some of the big frameworks require literally thousands of packages. Is there something about Javascript that necessitates this kind of…

In the web, any dependencies have to be sent to the client as well, so making them small and having the build chain handle grouping them all up in one minified file is suppose to make things quicker for clients.

also languages like python require an affirmed compile time resolved call to the classes so it can more easily know what code is not used or not going to ever be used.

Javascripts string based introspection and runtime generation of code being the backbone to the entire framework also makes it impossible to know what parts of included code are even used, just because no code calls out to it at build time doesn't mean the code isn't going to generate calls to it.

Re: Backdoor in event-stream library dependency

#354

Post by floatingatoll »

Klathmon wrote: post #64
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.

Code review can't catch determined malicious actors. It just isn't a viable protection against that kind of attack. Take a look at the underhanded c contest for plenty of proof where even very senior developers told up front that there is a backdoor in the code often can't find it! And they can't all be blamed on C being C, many of them would work the same in any language. I don't know the solution, but shaming users…

There’s no shame in refusing to study dependency diffs. If you consciously evaluate the risk and deem it acceptable, I agree with your judgement call.

What I find shameful is the lack of advisory warnings about this risk — by the repository, by the language’s community, by the teaching material.

This should have been a clearly-known risk. Instead, it was a surprise. The shame here falls on the NPM community as a whole failing to educate its users on the risks inherent in NPM, not the individual authors and users of NPM modules.

Re: Backdoor in event-stream library dependency

#355

Post by smacktoward »

malvosenior wrote: post #329
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.

The appeal of being able to use one language across the whole project, rather than one on the backend and a different one on the frontend, is very strong.

Re: Backdoor in event-stream library dependency

#356

Post by wpietri »

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 blaming him for not doing enough free work to help them with their paid jobs. If open-source libraries are truly valuable, we need to find a way to jointly pay maintainers for their labor. I can think of many options (a non-profit build with hefty donations from tech companies, governments giving out tax-funded grants, places like NPM and GitHub making crowdfunding 10x easier). But the ideas aren't the problem. It's getting one or more of them done.

Re: Backdoor in event-stream library dependency

#357

Post by [deleted] »

dmitriid wrote: post #275
raesene9 wrote: post #44

Earlier quoted context omitted.

You may not like it but from a license standpoint, I think you may be incorrect As quoted elsewhere in this thread " THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

This license is invalid in quite a few jurisdictions around the world.

[deleted]

Re: Backdoor in event-stream library dependency

#358

Post by underwater »

newnewpdro wrote: post #304
albinofrenchy wrote: post #172

Earlier quoted context omitted.

Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work. If this is an indictment of anything, it's an indictment of the entire NPM ecosystem -- it's been the wild wild west for years; haphazardly using whatever NPM install gives you is baked into the culture. Sure, Dominic is an active participant in that culture but it seems to me that it is impossibl…

> Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work. Linux didn't always have a giant user base, and it wouldn't have gotten there without strong leadership having a sense of pride and responsibility.

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)."

Re: Backdoor in event-stream library dependency

#359

Post by OJFord »

XCSme wrote: post #109
OJFord wrote: post #69

Earlier quoted context omitted.

Yes, that looks dodgy - a 64-bit 'N' being renamed 'logN', and its value changed to `1` left shifted by its prior self? I think there's a good bet that's just zeroing it out.

It's just doing 2^logN...

Which ought to be just N - but notice the argument passed in is mysteriously renamed. It may be nothing - I'm not even sure what N is here - I just agree that it looks weird.

Re: Backdoor in event-stream library dependency

#360

Post by trickstra »

CoffeeDregs wrote: post #230

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

- the pervasiveness of left-pad style packages - npm's governance - the community's perspective and culture

Also the low-effort nature of javascript language itself - no strong typing, able to rip out or replace foreign methods, even redefine standard behavior, no private methods, ... if somebody enjoys living in such environment, then they are more likely to also be ok with unmaintained packages, npm bumping your package versions without asking, npm allowing anyone to re-take a package name after it was deleted, developers transferring ownership without as much as googling for the username... but hey, as long as they have cool emoji icons...

Post reply on HN