nodejs and the javascript community continues to be a shit show run by amateurs.
Backdoor in event-stream library dependency
161–170 of 509 posts
Re: Backdoor in event-stream library dependency
#162Earlier quoted context omitted.
This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative. I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever : THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT…
The real problem is that so far, open source has been mostly more responsible than closed source. mostly. So many companies and people just go 'eh' and accept the defaults rather than really digging in. Which, in a real way, means they get what they deserve, but on the other hand, what is the alternative? I mean, personally, the alternative I like is a sort of hybrid model, where you pay someone else to do the vettin…
It always takes time for parasites to evolve in a new system.
Re: Backdoor in event-stream library dependency
#163I 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…
Open-source projects greatly depend on reputation.
E.g. I can trust the people behind git: some of them may be poor UX designers, but they won't let out a version that eats my files, or is backwards-incompatible. If a completely different team forked git, I would be quite wary to use the fork outright for my daily work.
When all long-term maintainers stop maintaining a project, the last person leaving should turn off the light. The project should be officially stopped, because no people remain in behind it.
Whoever wants to pick up the development should fork, and use a different name. This way, the forked project will accumulate its own reputation: of course, initially propped in major ways by the idea of "this is a fork of a well-known project".
At the very least, it would be a heads-up for everyone who depend on that project that a major change in it is happening.
Re: Backdoor in event-stream library dependency
#164A lot of butthurt people railing on the guy. Maybe he just doesn't care anymore about a dead package he has no intention of maintaining. Blame yourselves devs, not the author who donated hours and hours of free work for your benefit.
It’s about ethically handing off a package. No one is forcing him to maintain it. But when you make a package used by millions of people, you become responsible for their safety. To then hand over a package to a hacker or unknown party is just morally wrong. Just mark it as deprecated and call it a day, like a normal and responsible person.
>But when you make a package used by millions of people, you become responsible for their safety.
Says you! I don't agree with that. Author clearly doesn't either. You're painting it as though the author knowingly handed it over to some hacker when in reality he had 0 cares about this package and just handed it over to the first guy who asked. I would have done the same probably.
Re: Backdoor in event-stream library dependency
#165Unpinned 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.
> 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?).
Re: Backdoor in event-stream library dependency
#166Earlier quoted context omitted.
It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…
> That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership. I'm sure he would do it for $150k/year. He won't do it for $150k/year? Increase the price until he says "Yeah, sure I will maintain it". Or maybe h…
How about just not transfer ownership of the original name. Let foo become foo-new or go from john/foo to bob/foo whichever is appropriate thus ensuring that only those who affirmatively added bob/foo or foo-new are ever effected.
Vetting new maintainers sounds like hard work that you might not feel like doing for free no problem just don't do it and don't give them the damn name.
Re: Backdoor in event-stream library dependency
#167I see a lucrative business opportunity in alerting users when pwned/vulnerable NPM packages are used in their projects. Maybe something like this exists already?
Sounds like Snyk:
Re: Backdoor in event-stream library dependency
#168Move 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 exploit is not NPM specific, could be any programming language. (Though NPM is a bit easier to exploit since there are so many packages and a large tree of deps)
Re: Backdoor in event-stream library dependency
#169> Now we have to run a background check when someone wants to help? The problem is in the tools. I don't agree with this comment, really. But -- there's almost always room for improvement w/tools. IIUC this unpacks encrypted JS bytecode and then executes it? Is there any way to statically know whether this could happen? "var newModule = new module.constructor;" ... newModule['_compile']() From what terribly little I…
That doesn't look that far off from what you'll see in generated code, e.g. something like babel could easily output the lines you've pasted. The rest of it is extremely dodgy, of course.
I feared as much would be the case. Even in non-generated code there's perhaps some instances where that code would make sense.
However, if you were to audit your dependencies and find a new case of this, you could examine it further to determine whether it passes muster. I suspect code like this is infrequently added to packages.
Re: Backdoor in event-stream library dependency
#170Is 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?