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

91–100 of 509 posts

Re: Backdoor in event-stream library dependency

#91

Post by AndrewGaspar »

ocdtrekkie wrote: post #58
tschellenbach wrote: post #26

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

Nobody's saying you should never accept a patch from an unknown person. "Of course, if you just give someone commit rights, then you can't." is the whole point!

Re: Backdoor in event-stream library dependency

#92

Post by kentm »

jwlake wrote: post #20

This is one of the reasons npm packages with a compiled minified dist js files are a bad idea, makes hiding malicious code surprisingly easy.

I'm not sure that it would matter much in practice. I don't think anyone really reads the code for their transitive dependencies.

Re: Backdoor in event-stream library dependency

#93

Post by always_good »

There are a few issues with NPM that make this kind of thing especially easy/lucrative:

- An ecosystem of massive amounts of transitive dependencies increases the number of people you need to trust. If I wanted to attack a project that used NPM, their package.json dependencies would be a really good place to start. Find the least popular transitive dep they use and email the owner to see if you can be a contributor (repeat for all of their xdeps). If they don't immediately give you publishing rights like OP did, then show some chutzpah and make valid commits until they do. While this attack works on any programming language's dep system, it's easier the more transitive deps a project has. People ITT blaming the OP don't understand this attack always works on a long enough timescale. Do you think there isn't someone out there who would make high quality contributions to an xdep of primedice.com (online gambling site) for 5 years to finally get publish access?

- Anything may run during `npm install`. npm install supports an --ignore-scripts argument to not run any scripts during install. This should be the default.

- Unqualified module names make it more desirable to "take over" a package than just publish your own package "npm install /event-stream", so it contributes to an ecosystem of ownership-transfer that's far less likely to exist on, say, https://package.elm-lang.org/ where everything is qualified by a Github username.

- NPM website doesn't show you source code. The github link on the project page is just a convention. I think the NPM website should have a light source code browser of whatever is in the tarball that you download and execute during `npm install`. Bonus points for reproducible builds from that source.

- Developers don't actually review every bit of code they use and execute, especially not transitive deps. And we certainly aren't going to bother to download the tarball from NPM and unpack it to inspect the code of every dep. Most people reading this don't even know how to do that.

I've thought of some ideas to help the situation, like creating a Github shield that verifies that a conventional build script like `npm run publish-build` reproduces the tarballed code on NPM, but then I would just be doing free work for the NPM organization, and it's still just a hack.

Re: Backdoor in event-stream library dependency

#94

Post by eropple »

antocv wrote: post #82

Well this undermines everything dominictarr has done for secure scuttlebutt and other projects, including datproject and its connection to Knight Foundation. "Oops, I just gave the repo to an unkown dude", OK. Sure. Just replace "unkown dude" with "to my colleagues at 5 eyes secret service organization" This kind of mistake is not a mistake, not from a dude like dominic.

Please substantiate your own open source projects at any and all sizes so that we may, too, cast aspersions on your relationships with governmental agencies. I'm sure that will improve things mightily.

This is a community problem based on insufficient incentives and the way that the software development community is content to allow individual labor to replace community efforts and you, as a member of that community, are kinda pissing in the pool right now. If you can look past the initial dismay, this is a time for the software development community to look in the mirror, not to pick up your torches. It's a project that he hasn't touched in years. Why should he care? What are you doing to make him want to?

Re: Backdoor in event-stream library dependency

#95

Post by timkpaine »

AndrewGaspar wrote: post #87
antocv wrote: post #82

Well this undermines everything dominictarr has done for secure scuttlebutt and other projects, including datproject and its connection to Knight Foundation. "Oops, I just gave the repo to an unkown dude", OK. Sure. Just replace "unkown dude" with "to my colleagues at 5 eyes secret service organization" This kind of mistake is not a mistake, not from a dude like dominic.

Seriously, I don't get how the others in this thread don't get this. Nobody's talking about the legalese of the license - he's undermined his _own_ credibility, which is all that really matters in open source. If he's fine with people not trusting his packages in the future, that's fine, but THAT's the trade-off, regardless of how you license the code.

you forget how seriously lazy developers are, remember left-pad?

Re: Backdoor in event-stream library dependency

#96

Post by perfunctory »

M2Ys4U wrote: post #70
raesene9 wrote: post #44

Earlier quoted context omitted.

You may not like it but from a license standpoint, I think you may be incorrect As quoted elsewhere in this thread " THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

There's a difference between legal liability and moral liability.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

Re: Backdoor in event-stream library dependency

#97

Post by [deleted] »

slg wrote: post #7

I 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…

[deleted]

Re: Backdoor in event-stream library dependency

#98

Post by regularfry »

luizfzs wrote: post #40
rdtsc wrote: post #3

Also note the same user owns this library: https://github.com/right9ctrl/node-scrypt I would be very suspicious of that as well and audit anything that library has touched.

I'm not a crypto guy but this change really makes me scratch my head: https://github.com/right9ctrl/node-scrypt/commit/52a1cb792bc...

That just looks like a convenience function to me. Rather than passing 1,2,4,8,16 in as the value of N, you pass in 0,1,2,3,4. Has the benefit that it's not possible to pass in a number that's not a power of 2 (which might not be valid, I don't know how scrypt works).

Re: Backdoor in event-stream library dependency

#100

Post by pmontra »

slg wrote: post #7

I 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…

There should be well known best practices to signal that a repository is not maintained. Example: archiving the repo (it becomes read only). Then somebody forks it and updates the NPM registry with the new repo.
Post reply on HN