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

401–410 of 509 posts

Re: Backdoor in event-stream library dependency

#401

Post by jrockway »

jabberthemutt wrote: post #199
jrockway wrote: post #154

I love reading these threads. People seem to expect way more out of open-source software than is actually guaranteed to them. It is a template of some computer code that may be relevant to your work; nothing more, nothing less. "I can't believe you let this happen to me!" Well, read the license: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED". If you don't agree to that, you have…

> Not sure what else there is to discuss. Morals and ethics.

What are the ethics? The developer isn't interested in maintaining it. Someone else was. So the developer gave it to that interested party.

I feel like 90% of the open source libraries I've written are maintained by someone other than me now. If that's considered unethical, next time I'll just not open-source it.

Re: Backdoor in event-stream library dependency

#402

Post by gnulinux »

zawerf wrote: post #387

Anyone know how this was found and whether that process can be automated? There are likely a lot more packages that are infected with the same technique. I looked at the linked commits: https://github.com/dominictarr/event-stream/commits/master and it looks so surprisingly normal. I am pretty sure I wouldn't have caught it even if I was code reviewing it. Did someone heroically rerun every package's build process to…

For what it's worth: it'd be undecidable to catch all vulnerabilities even if you very precisely define the semantics of your virtual machine, because it'd require knowing whether a certain line of code will be executed, which is known to be as hard as the halting problem. Practically, maybe? Maybe one can use ML to check codebase for suspicious code. But in an ecosystem like npm no matter what protection you have against hackers, someone will try very hard and inject vulnerabilities like this. You should defend yourself and use checksums for deps and execute only trusted code.

Re: Backdoor in event-stream library dependency

#403

Post by heartbreak »

shittyadmin wrote: post #127
ocdtrekkie wrote: post #58

Earlier quoted context omitted.

You can't vet the people, but you can vet the code. Of course, if you just give someone commit rights, then you can't. But generally speaking the maintainer understands the code they merge into a project, and that is the vetting that takes place.

Sure, but then they have to actively invest time into the project... not everyone can afford that.

Then mark the project as abandoned and add a note suggesting the new volunteer’s fork.

Re: Backdoor in event-stream library dependency

#404

Post by PhilippGille »

semi wrote: post #377
joshmanders wrote: post #266

Earlier quoted context omitted.

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

I don't follow your comparison. What parts of the Linux ecosystem have a single person maintaining a large multitude of packages? Looking at the kernel itself you see a hierarchy where people are only responsible for small segments of the kernel. Looking at a standard distro like Debian, which makes this easily available at https://www.debian.org/devel/people you'll see that most individuals are only responsible for…

I think with "single responsibility" he means the packages. So instead of complex packages that are hard to maintain they have lots of smaller packages that are easier to maintain. So a single person can maintain several packages.

Not saying that I think maintaining hundreds sounds like a good idea, just trying to point out the misunderstanding :) .

Re: Backdoor in event-stream library dependency

#405

Post by btilly »

jakelazaroff wrote: post #370
raesene9 wrote: post #273

Earlier quoted context omitted.

oh sure the criminal who put the backdoor in place, no-one's arguing his/her liability. But the point that I was referring to is any suggestion that the repo. owner who handed it over could bear any liability for doing so, I'd suggest that's not probable/practicable.

I don't see how the text of the MIT license can be construed to indemnify a negligent developer but not a malicious one.

I am not a lawyer, but my understanding is that the text of the MIT license is a potential defense to a suit, it does not prevent one. As in I try sue you, you say, "But did you read the license?" I do, talk to my lawyer, and still decide to sue you. You tell the judge, "But look at the license!" And then it is up to the judge to decide whether it matters.

Therefore the issue isn't the license, it is the rules of the law in question under which the author is being sued.

Therefore your intent can matter. Whether a valid contract exists matters. Whether I can be expected to have read it matters. THAT THE INDEMNITY IS WRITTEN IN ALL CAPS MATTERS. (I'm not making that up - see https://law.stackexchange.com/questions/18207/in-contracts-w... to see that it does matter.)

The result? The indemnity in the contract can say whatever it wants and still only provides partial protection. The real rules are complicated and elsewhere in the legal system.

Re: Backdoor in event-stream library dependency

#406

Post by dragonwriter »

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.

> The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5.

The concept is significantly older, but the implementation of a systematic facility for it rather than more ad hoc mechanisms may date from then. (It's a lot harder to sneak in and use an exploit in books of source code used in the 1970s-80s, though; convenience comes with a price.)

Re: Backdoor in event-stream library dependency

#407

Post by trickstra »

rglover wrote: post #310

That thread is a huge argument for paid software. It's mind blowing how folks expect people to maintain things for nothing and get mad when it doesn't work perfectly. Some silly choices were made by the original maintainer but give the dude a break. He doesn't owe you a damn thing.

do you know how many of your paid software contains a similar disclaimer that removes their responsibility for the damages caused by the software? Only you'd never have a chance to look at that code and find this injection...

Re: Backdoor in event-stream library dependency

#408

Post by notatcomputer68 »

JustSomeNobody wrote: post #209
ianwalter wrote: post #181

People have to understand that the Node.js ecosystem is different than in other programming languages/platforms. Modules are composed from smaller modules with a granularity so small that it is almost unique. When you're publicly publishing something low-level to npm you really should understand that the community may build on top of it to the point where it is used by many modules and as a result used by many end-us…

So much irony here. So, the community can be careless and just import whatever, but the maintainer can't pass maintainership on to someone else without it being dubbed careless? Shouldn't this whole situation be the fault of the community because they let in a bad actor? Society is great when everyone is benefiting, but something goes wrong and out comes the pitchforks.

This is how transitive trust works. You vouch for a bad guy - you lose trust yourself.

Far from being ironic, this is the normal functioning of the system.

Re: Backdoor in event-stream library dependency

#409

Post by xorcist »

jrochkind1 wrote: post #224
raesene9 wrote: post #179

Earlier quoted context omitted.

You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software ... really? If that were the case, you'd pretty much wipe out the software industry as it stands today :) I'd be very interested in case law where you can see the users of a service (which might not even disclose what software they use) are able to sue the author of a package used as part…

I'm pretty sure they'll be legally liable for intentionally inserted malicious code, no matter what the license text says. I'm not talking about the original maintainer (who didn't introduce malicious code intentionally), but the person he turned it over to (who seems to have). Legal liability and ethical responsibility are not always the same thing, although it's generally only the first that matters in court.

Oh, no, sir. I didn't insert the backdoor. I gave the keys to this anonymous person on the Internet, and he inserted the backdoor.

That clearly absolves me of any responsibility, does it not?

Re: Backdoor in event-stream library dependency

#410

Post by malvosenior »

smacktoward wrote: post #355
malvosenior wrote: post #329

Earlier quoted context omitted.

> 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.

I know the pitch for this is very strong but I've never seen any benefit in real life. Javascript was designed to be a client side browser scripting language, it's not equipped with a standard library that competes with other languages that were designed from day one for the server or systems programming. The skill sets of front-end and back-end developers are also very different. In my experience, when you use Node you end up with front-end devs programming back-end servers very poorly or you end up with back-end devs forced to use Node/JS. I've never actually met a seasoned back-end developer who would choose JS for the domain given no constraints.
Post reply on HN