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

391–400 of 509 posts

Re: Backdoor in event-stream library dependency

#391

Post by ultraluminous »

All these arguments about Moral/Legal liability are just head-scathingly nonsensical to me.

Look, if you're pulling external dependencies into your project from anywhere, and you don't version pin and hash compare those dependencies every time you build, then you get ZERO security guarantees. Simple as that. You might have some "in a perfect friendly world" expectations, but no guarantees, no recourse and no one else to blame when the world does not conform.

The notion that the author of the package could/should do anything to mitigate that for you is ridiculous. Ignoring many, many plausible coercion/honest mistake scenarios, just consider that a once-reputable maintainer can over time become malicious. That's it. If you have any actual real security requirements, then I'm sorry but you don't get to say "but but but DRY!!!" and call it a day. You are responsible for what software you run in your product.

Re: Backdoor in event-stream library dependency

#392

Post by adamrezich »

joekrill wrote: post #324
thrower123 wrote: post #236

NPM is just a mess, and the whole culture and ecosystem that surrounds it. Micropackaging does make a little bit of sense at least in theory for the web, where code size ought to matter, but in practice it's a complete shitshow, and leads to these insane dependency paths and duplication and complete impossibility to actually keep abreast with updates to dependencies, much less seriously vet them. The insidious threat…

I don't see how this problem is limited to just NPM. This is a problem of any package manager. Or any software distribution system in general, really. Look at all the malware found on the Play Store and the Apple Store. Unless you're willing to meticulously scrape through every bit of code you work with you're at risk. Even if you can, what about the OS software? How about the software running on the chipset? This is…

This; on a long enough timescale, any open-source package manager that maintains popularity will have this problem. npm has this problem now because JavaScript leaves a lot to be desired in terms of base convenience functionality (left-pad), and because of JavaScript's massive popularity that won't be going away anytime soon. This whole thing is hugely educational for people designing new languages with integrated package managers. However, while the lessons are pretty easy to grok, the solutions are going to be harder to come up with. I'm excited to see what kinds of stuff people come up with in response to this.

Re: Backdoor in event-stream library dependency

#393

Post by jrochkind1 »

igolden wrote: post #376
jrochkind1 wrote: post #232

it's kind of impressive this compromise was discovered _at all_. Anyone know the story of how it was? There seems to be a lot of back story before the linked issue begins. I'm interested in who noticed the compromise, when, and how. Because with open source, noticing the compromise is about the _best_ we can expect from a "worst case".

A random, lucky find: https://github.com/remy/nodemon/issues/1442

Interesting. If the malware hadn't buggily triggered a deprecation warning...

Re: Backdoor in event-stream library dependency

#394

Post by Myrmornis »

Is one solution a system where our ssh keys participate in some sort of trust graph like SSL certificates do?

(I expect that question is very naive from the point of view of people who know this area, but I'd be interested to be pointed in the right direction.)

Re: Backdoor in event-stream library dependency

#395

Post by merb »

raesene9 wrote: post #130
michaelmrose wrote: post #105

Earlier quoted context omitted.

Putting it on paper does not make it so. A single lawsuit and you could easily be out thousands even if you win. The legal outcome could vary widely state to state and nation to nation. If putting a blurb in a text file makes you feel safe about being sued for negligence you haven't considered all possible venues. Here is an article about liability waivers https://www.enjuris.com/blog/questions/liability-waivers/

So you reckon that people who publish open source software should be liable for flaws/vulnerabilities in their code? It's a bold assertion, I'd be interested to see if you can provide any case law where it's been tested.

it depends. laziness can actually be used against you. even in european countries.

Re: Backdoor in event-stream library dependency

#396

Post by jpalomaki »

Running the open source projects through organizations like Apache Software Foundation [1] would help. They can have processes for handling abandoned projects and also set guidelines that projects must follow when it comes to including 3rd party packages.

This is not just a security risk. There might be some business implications if somebody would sneak in for example some AGPL licensed software to the dependency chain of a popular package with more permissive license.

[1] https://www.apache.org/

Re: Backdoor in event-stream library dependency

#397

Post by slg »

jrochkind1 wrote: post #373
slg wrote: post #274

Earlier quoted context omitted.

Without locking in to a specific version you are trusting the maintainer in perpetuity. That trust extends to things like reviewing their own dependencies, reviewing pull requests, adding other maintainers, or just flat writing bad code. I don't blame the author any more in this instance than if any of those other possible examples occurred. Security patches are part of my original point regarding why it is bad for a…

And yet, to produce the software that nearly any employer or client in 2018 wants at the price they want, requires using open source dependencies without manually reviewing every diff from every version released. I don't really understand what you are trying to suggest. Yes, whether we realize it or not, we are trusting the maintainers of our dependencies. Sometimes that trust is misplaced. That might lead us to try…

I am generally advocating for being an informed user of open source software. As for something more specific, I would echo the two suggestions from the original author in one of his Github comments:

>1. Pay the maintainers!! Only depend on modules that you know are definitely maintained!

>2. When you depend on something, you should take part in maintaining it.

You can't expect someone to maintain your code for you without you contributing anything in return and if something does go wrong in that situation you have no one to blame but yourself.

Re: Backdoor in event-stream library dependency

#398

Post by merb »

raesene9 wrote: post #68
lmm wrote: post #59

Earlier quoted context omitted.

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…

Even package managers where signing support nominally exists, the take-up is often poor. IIRC rubygems support package signing but almost no-one uses it, so it's effectively useless. We're seeing the same pattern again with Docker. They added support for signing (content trust) but unfortunately it's not at all designed for the use case of packages downloaded from Docker hub, so it's adoption has been poor.

actually when publishing to the biggest java package repository (sonatype) you NEED to sign your packages.

also you can't transfer ownership without giving away your domain or github account. But you can add others to also upload to your name, but if an accident occurs your liable, too.

Re: Backdoor in event-stream library dependency

#399

Post by slg »

WorldMaker wrote: post #378
slg wrote: post #274

Earlier quoted context omitted.

Without locking in to a specific version you are trusting the maintainer in perpetuity. That trust extends to things like reviewing their own dependencies, reviewing pull requests, adding other maintainers, or just flat writing bad code. I don't blame the author any more in this instance than if any of those other possible examples occurred. Security patches are part of my original point regarding why it is bad for a…

A lot of users had it locked to a semver major version or major.minor version, which isn't necessarily trusting the maintainer "in perpetuity", just the current development track. Is a change between maintainers a semver-major breaking change? Several people have suggested that that is a baseline that npm could easily automate/enforce. That would have at least sent a community signal to re-review/re-audit the package…

Does npm currently control versioning to any extent? A quick Google search seemed to show that they only make versioning recommendations with no real rules. If you are operating from the premise that the maintainer is potentially compromised, why would you trust them to stick to the semantic versioning spec?

Re: Backdoor in event-stream library dependency

#400

Post by heartbreak »

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…

The MIT license isn’t as bulletproof as you think it is.
Post reply on HN