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

251–260 of 509 posts

Re: Backdoor in event-stream library dependency

#251

Post by samirm »

StavrosK wrote: post #29

I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…

Why would the average joe trust something like this? Your FAQ says each maintainer is vetted and handpicked, but nothing about criteria or how they're picked.

Do you mind explaining this vetting process a little more? How can we be sure that something like this flatmap thing doesn't happen on codeshelter?

Re: Backdoor in event-stream library dependency

#252

Post by tjholowaychuk »

gregknicholson wrote: post #145
AndrewGaspar wrote: post #87

Earlier quoted context omitted.

Seriously, I don't get how the others in this thread don't get this. Nobody's talking about the legalese of the license - he's undermined his _own_ credibility, which is all that really matters in open source. If he's fine with people not trusting his packages in the future, that's fine, but THAT's the trade-off, regardless of how you license the code.

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 get tired of receiving emails about those kinds of things personally, you try to just ignore them, sometimes their request sounds reasonable but still, can those people be trusted, who knows.

Re: Backdoor in event-stream library dependency

#253

Post by eropple »

malvosenior wrote: post #180
eropple wrote: post #94

Earlier quoted context omitted.

Please substantiate your own open source projects at any and all sizes so that we may, too, cast aspersions on your relationships with governmental agencies. I'm sure that will improve things mightily . This is a community problem based on insufficient incentives and the way that the software development community is content to allow individual labor to replace community efforts and you, as a member of that community…

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.

I understand the security risks involved. Security is part of my job and I have on more than one occasion been the guy unwinding the entire ecosystem to see what depends on the latest insecure library of the week.

And somehow, despite this experience, I am also blessed with the minimal capablility to understand the swamp-ass social toxicity that's happening here. I am likewise blessed with the modicum of good sense to realize that this is not a problem that goes away by stuffing one person in the wicker man and setting it ablaze. Systemic problems have systemic solutions and a real part of actual security is applying systemic solutions instead of looking for scapegoats that let you think you're a tough guy on the Internet.

Because it is about feelings. It's always about feelings when somebody fumfuhs about how serious and important it is that they, or a likeminded compatriot, get to be an asshole to an individual about a systemic problem. It's just about their feelings and given place of pride because they're theirs. So maybe we shouldn't play that game at all and maybe we should look at the systemic issues that actually matter.

Haveaniceday.

Re: Backdoor in event-stream library dependency

#254

Post by gkya »

sulam wrote: post #138
kd5bjo wrote: post #78

Earlier quoted context omitted.

You can use smaller, more targeted libraries so that the changes you need to review are actually relevant to your project.

In the Node/NPM world, this is pretty difficult. There are many ( many ) small libraries and everything you depend on brings in many more.

That's a big and totally objective reason to abandom the Node.js/NPM ecosystem, like its original author did.

A language that doesn't have a decent standard library means that you'll have to use huge amounts of code that random strangers used, and the chain of dependencies will grow larger and larger.

In languages like Ruby and Python, you have a decent standard library, and then big libraries and frameworks that are maintained by the community, like Rails, Django, SqlAlchemy, Numpy, etc. That's healthy because it minimises or zeros the amount of small libraries maintained by a single guy, thus maximising the amount of code that you can trust (because you can trust the devs and development process of a popular library backed by a foundation or with many contributors).

With Node, almost every function comes from a different package. And there's no bar to entry, and no checks.

If Node.js is going to stay, someone needs to take on the responsability of forming a project, that belongs to an NGO or something, where the more popular libraries are merged and fused into a standard library, like that of Python's. Personally, I'm not touching it until then.

Re: Backdoor in event-stream library dependency

#255

Post by tjholowaychuk »

zeroname wrote: post #198

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.

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.

Re: Backdoor in event-stream library dependency

#256

Post by rosser »

ummonk wrote: post #206
21 wrote: post #182

Earlier quoted context omitted.

> Lieutenants gain authority based on the merit of their contributions Meritocracy is an outdated discriminatory practice. https://postmeritocracy.org/ https://www.theguardian.com/commentisfree/2017/mar/20/merito...

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.

Re: Backdoor in event-stream library dependency

#257

Post by pier25 »

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 one of the reasons we've moved to Go for our server side code.

Re: Backdoor in event-stream library dependency

#258

Post by xvector »

jsd1982 wrote: post #234
meowface wrote: post #160

Earlier quoted context omitted.

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.

If you can't evaluate the trustworthiness who you're handing the package over to, just don't hand it over. Mark it as deprecated and call it a day. This is Open Source 101.

Re: Backdoor in event-stream library dependency

#259

Post by AnaniasAnanas »

trickstra wrote: post #201
meowface wrote: post #160

Earlier quoted context omitted.

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

exactly, transferring a package to an unknown person is not only giving them access to the code but also to all the people who already trust that code

To be honest that kind of your fault for trusting that code. Heck, the commits were not even signed as far as I know, had they been signed the change of "ownership" would have been clear.

Re: Backdoor in event-stream library dependency

#260

Post by ergothus »

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…

The problem is that everyone is trying to push everything to one side. That's just not stable. Yes, the maintainer SHOULD (but doesn't have to) make a hand-off explicit at a minimum. Yes, people should take responsibility for ensuring their packages are (and remain) legit. But both of these can break down.

It's like litter. It is not realistic to have anyone clean up everyone's trash. It's also not realistic to expect that things remain clean if everyone only picks up their own trash. Everyone needs to clean up their own trash and a little bit more, to compensate for the burps in the system.

Post reply on HN