This is one reason why you don't depend on trivial libraries you can roll in-house and maintain yourself. Shame on people perpetuating the "depending on is-array or left-pad is totally fine" ideology.
Backdoor in event-stream library dependency
221–230 of 509 posts
Re: Backdoor in event-stream library dependency
#222Move 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)
Would it be possible to put compromised package in Debian repository? Or has something like this happened in the past?
Re: Backdoor in event-stream library dependency
#223I 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…
Node could implement something like an "ethical transfer of responsibility for packaging" clause for their code of conduct. I'd like to see that.
I'd also like to see something like StavrosK mentioned in his comment[1] about https://codeshelter.co made a part of this. When a maintainer gets an email for a long-dormant project of theirs, the maintainer needs options. One of those should probably be to yield the package back to the community. A "code shelter" is one way of doing that.
Then the question of, "How do we vet maintainers at scale?" comes up. All I really know is it'd take a financial & human capital investment in Node community infrastructure to make it happen.
I think it's in Node's best interest to do so. These highly prolific maintainers like dominictarr are prime targets for black hats. Overworked, underpaid, huge product portfolio they manage. Who among us wouldn't be grateful for the interest & help?
So Node should invest in fixing this.
Re: Backdoor in event-stream library dependency
#224Earlier quoted context omitted.
Liability is very often not exclusive in law, and, in particular, tends to flow the whole way up supply chains. With nothing being sold you probably aren't dealing with strict product liability upstream, but exposure of end users is reasonably foreseeable so there's no immediately obvious blanket reason for ruling out upstream negligence liability to end users. The idea that the party most proximate to end users is e…
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.
Re: Backdoor in event-stream library dependency
#225Earlier quoted context omitted.
You can, but it's opt-in. At least once with every new project I go "gah, dammit!" because I forget to check in a lockfile, but I sleep better at night. I do not know if NPM lockfiles are transitive, though. Guess I'd better go looking...
As far as I know, you can pin your versions (something I always recommend), but those packages can always pull in other dependencies with version bumps. And NPM in particular encourages a massive plethora of micropackages, so the dependency tree gets extremely large.
Do they? I'm not 100 percent sure about the npm package lock (because I don't typically use it), but I'm fairly sure that yarn's lockfile will lock the full dependency tree, including the dependencies of your dependencies. I believe npm's package lock will as well, but I'd have to double check that.
Re: Backdoor in event-stream library dependency
#226Earlier 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.
I think browsers show how to migrate away from insecure defaults successfully. The client software should start showing big obvious warnings. Later stages should add little inconveniences such as pop-ups and user acknowledgement prompts, eg. 'I understand that what I'm doing is dangerous, wait 5 seconds to continue'. The final stage should disable access to unsigned packages without major modifications to the default settings.
Re: Backdoor in event-stream library dependency
#227Looks like the sleuths on github just found out it targets a bitcoin wallet called `copay-dash`
https://github.com/dominictarr/event-stream/issues/116#issue...
Re: Backdoor in event-stream library dependency
#228I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.
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.
If you're using auto-updating external packages, aren't you effectively giving the package author commit access to your derivative project too?
Re: Backdoor in event-stream library dependency
#229This isn’t about Dominic, this is about using node for anything secure (for example, somehow people use node in cryptocurrency projects)
If you have any security requirements whatsoever, and you are using node, you need to do your own audits of the (hundreds of) packages you use. If that’s not practical then node isn’t practical
Re: Backdoor in event-stream library dependency
#230A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc?
Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?