In completely unrelated news, Deno completed its second milestone two weeks ago and there’s now basic support for creating servers and reading files.
Backdoor in event-stream library dependency
21–30 of 509 posts
Re: Backdoor in event-stream library dependency
#22Unpinned 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.
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.
Re: Backdoor in event-stream library dependency
#23I 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…
It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer:
> he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years.
That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership.
Perhaps there should be some sort of escrow jail for new maintainers where all changes are reviewed. Certainly better vetting needs to take place.
Re: Backdoor in event-stream library dependency
#24Get ready for more of these type of attacks as time goes by, and they won't all be as obvious as this one.
Supply chain attacks are increasingly being seen as a good vector and there are thousands of unmaintianed Open source libraries buried in the dependencies of popular projects.
Also worth noting that package security solutions, which check for known vulnerabilities, are unlikely to solve this kind of problem unless they track "known good" package versions and alert when things change.
Re: Backdoor in event-stream library dependency
#25I 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…
> Isn't adding another potentially unknown maintainer generally better for the community than a project dying?
No. If it's someone involved in the project for years you feel you can trust then sure, go ahead, but someone coming along being like "sup, commit rights plz" then something's just wrong with you of you agree. If that person were serious about it they could still fork it and maybe msg users of the old version about it.
Sure those people could still mess up by just switching over without checking the new fork, or having good reasons to switch like bug fixes or new features, but at least you as the author of the original lib did your part to prevent any messups.
Re: Backdoor in event-stream library dependency
#26I'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.
Re: Backdoor in event-stream library dependency
#27It looks like no one is even sure what the code actually does? Or am I misreading that thread.
[deleted]
Re: Backdoor in event-stream library dependency
#28It looks like no one is even sure what the code actually does? Or am I misreading that thread.
You read it right
Re: Backdoor in event-stream library dependency
#29I 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 end, I built something to "solve" this, a project called Code Shelter[1]. It's a community of vetted maintainers that want to help maintain abandoned FOSS projects, so if you want your project to live on but don't want to do it yourself, you just add it there and you can be reasonably sure that nothing like this will happen to it.
Of course, you have to get a large enough pool of trusted maintainers that someone will be interested in each project, but it's still better than blindly adding people. I can't fault the maintainer of that project, since trusting people is usually fine, but it's too bad this happened to him. The commenters are acting a bit entitled too, but I guess it's the tradeoff of activity vs security.
Re: Backdoor in event-stream library dependency
#30I 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…
It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…
It is irresponsible if you believe--and I don't say this pejoratively or to caricature the argument--that somebody takes upon themselves a responsibility when they open-source software. I used to think this was the case, but less and less often I find this to be true. In a practical sense it becomes a free-rider problem and people with money aren't stepping up.
In the absence of accepted responsibility from (monied) consumers, the way responsibility is ultimately taken on has to be either to affirmatively take it on (as public service to the community) or to pay for it. Which is a sticky problem because it's hard to pay for it and it's invariably not presented effectively in terms of building a business case. Existing solutions, not to put too fine a point on it, suck at building that case. OpenCollective, the remnants of Gittip/Gratipay, etc. - incentives don't align to put money where it needs to go, and J. Random Consumer often suffers the most for it.
I have a pretty strong idea about how to solve it for-reals. At the moment, though, it's a time/money problem for me; I'm not in a place to chase the kind of (relatively small) funding that the problem probably requires. If anyone else is interested in this problem space, please feel free to email me directly; I'd be happy to chat with you and I'm very interested in seeing this done well.