This is bound to happen from time to time. We should invent some tools to nuke the affected code from orbit.
Backdoor in event-stream library dependency
171–180 of 509 posts
Re: Backdoor in event-stream library dependency
#172Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…
Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work.
If this is an indictment of anything, it's an indictment of the entire NPM ecosystem -- it's been the wild wild west for years; haphazardly using whatever NPM install gives you is baked into the culture.
Sure, Dominic is an active participant in that culture but it seems to me that it is impossible to have a largely unmoderated volunteer system with as many packages are actively used without things like this happening.
Keep in mind, this is a case where the system worked, more or less -- an observant user caught the issue, and made a public issue of it. Who knows how many packages have slipped by like this?
Re: Backdoor in event-stream library dependency
#173Can I ask a simple question not being a javascript guy? Should this be considered a security vulnerability in need of mitigation, ie should I try and identify all the places this/these packages may used in our production code, and ...do something?
Re: Backdoor in event-stream library dependency
#174> Now we have to run a background check when someone wants to help? The problem is in the tools. I don't agree with this comment, really. But -- there's almost always room for improvement w/tools. IIUC this unpacks encrypted JS bytecode and then executes it? Is there any way to statically know whether this could happen? "var newModule = new module.constructor;" ... newModule['_compile']() From what terribly little I…
Maybe something that would actually run it in a sandbox and say, catch the calls to AES256 decryption and flag for human review would do the job?
Re: Backdoor in event-stream library dependency
#175Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…
I would rather see it as if contributors gain _trust_ based on their contributions, which is not necessarily the same as authority.
Re: Backdoor in event-stream library dependency
#176I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…
There's a similar effort in the Python / Django world called Jazzband (https://jazzband.co/). This model will probably become more and more necessary as maintainers need to move on from projects for whatever reason. Having a safe place to transfer a project to with a formal process (announcement of the change, code review before acceptance, etc.) would certainly help combat this issue.
Re: Backdoor in event-stream library dependency
#177Earlier quoted context omitted.
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?
If you run a business where you have convinced people to give you access to their house to do some chore and you sell your business and your copy of their keys to a criminal it could be morally problematic. A car is merely a fungible vehicle the customer would have been no better or worse off had the robber been driving a different car. This would be an apt analogy for just giving / selling a code base. Had it been d…
He was doing this for free and releasing it under an open source license.
In your analogy the business would be performing the chores for free and telling the users that the business is not responsible for any damage related to the access granted by the key. I don't think most people would sign up for that without a business relationship.
Re: Backdoor in event-stream library dependency
#178I see a lucrative business opportunity in alerting users when pwned/vulnerable NPM packages are used in their projects. Maybe something like this exists already?
GitHub does it for Ruby Gems.
Re: Backdoor in event-stream library dependency
#179Earlier quoted context omitted.
The people with legal liability to the end-users, I expect, are the developers that made use of this library without properly vetting all changes to it.
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 of that service.
Re: Backdoor in event-stream library dependency
#180Well 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…
antocv, like many of us values security over feelings. If you want to run maybe insecure code to help be supportive of someone, go for it. His point is valid though and you can ignore it at your own risk.