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

501–509 of 509 posts

Re: Backdoor in event-stream library dependency

#501

Post by [deleted] »

xorcist wrote: post #409
jrochkind1 wrote: post #224

Earlier quoted context omitted.

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?

[deleted]

Re: Backdoor in event-stream library dependency

#502

Post by ufmace »

cellis wrote: post #246
ufmace wrote: post #240

Makes me wonder if there's a business opportunity. Make your own version of NPM, based off of the real NPM, but some level of auditing for package updates. Don't report suspicious commits from new contributors right away, that sort of thing. Charge companies a few hundred $ a month to use your site instead of NPM, and they can update packages at will without risk of picking up something nasty. Then again, the fact th…

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

I never much liked dropping a link as a reply to a comment, because nobody can tell what you think about it.

But I will say that indeed almost all viable businesses involve some amount of schlep. But just because something involves a lot of schlep doesn't make it a viable business.

Re: Backdoor in event-stream library dependency

#503

Post by yetanotherjosh »

chomp wrote: post #67
dmortin wrote: post #22

Earlier quoted context omitted.

If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.

I would caution one to not have tons of dependencies. More surface area in terms of the amount of 3rd party libraries/developers means more chances that one of them is not a responsible maintainer, as in this case. That increases the application's security risk.

Then let's hope you're not using Webpack, which alone has several hundred of them and not small ones, mind you... super complex libraries that trying to "own" enough that you'd be able to securely review code diffs is completely infeasible.

Re: Backdoor in event-stream library dependency

#504

Post by jrockway »

heartbreak wrote: post #455
jrockway wrote: post #444

Earlier quoted context omitted.

The license doesn't really matter here. I'm only quoting it to set expectations. People are showing up demanding some sort of quality standard, when they explicitly agreed that there was no such standard. A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved. To your point, if the a…

> A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved. It's an author/maintainer issue (and not an NPM issue) because the maintainer explicitly gave the bad actor the right to publish via NPM's delivery channel. The maintainer did so in gross negligence, in my opinion.

If courts agree with you, the world of free software is over. It will be too risky to accept contributions. Github and NPM will be shut down over lawsuits.

For that reason, I think you are wrong.

Re: Backdoor in event-stream library dependency

#505

Post by heartbreak »

jrockway wrote: post #504
heartbreak wrote: post #455

Earlier quoted context omitted.

> A related issue is that NPM distributed malicious code to people. That sounds like a problem between people that downloaded the malicious version and NPM. Not sure how the author is involved. It's an author/maintainer issue (and not an NPM issue) because the maintainer explicitly gave the bad actor the right to publish via NPM's delivery channel. The maintainer did so in gross negligence, in my opinion.

If courts agree with you, the world of free software is over. It will be too risky to accept contributions. Github and NPM will be shut down over lawsuits. For that reason, I think you are wrong.

It is risky. Ask one of the 17 law firms involved with Oracle v Google if open source licensing is too risky.

Re: Backdoor in event-stream library dependency

#506

Post by g-harel »

shados wrote: post #362
g-harel wrote: post #84

NPM needs to make accessing the source code easier. It has always bothered me that the linked repository can be set to absolutely anything the author wants.

Not sure how that would help. Anyone can publish anything to npm, it doesn't even need a repository. So unless the source code itself was hosted on npm, and the entire toolchain was controlled by npm, there's not much to do.

Exactly, I think a source code browser on https://www.npmjs.com/ would be nice to have

Re: Backdoor in event-stream library dependency

#507

Post by floatingatoll »

lmm wrote: post #59
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.

Lack of code signing is what's harmful here. My maven projects' dependencies are technically all pinned, but updates are just a "mvn versions:use-latest-releases" away. But, crucially, I have a file that lists which GPG key IDs I trust to publish which artifacts. If the maintainer changes, the new maintainer will sign with their key instead, my builds will (configurably) fail, and I can review and decide whether I wa…

The sale of any business that makes use of cryptography will generally include the private keys and passwords necessary to ensure business continuity. Code signing would not necessarily protect you against a human-approved transfer of assets as occurred here, whether as part of a whole-business sale or as a simple open-source project handoff.
Post reply on HN