It would be nice if we could pin libraries to a particular maintainer, as well as a version.
Backdoor in event-stream library dependency
101–110 of 509 posts
Re: Backdoor in event-stream library dependency
#102"Hey! This random piece of software I found under the table at the pub does not have my best interests at heart?! My feelings are hurt!"
Re: Backdoor in event-stream library dependency
#103Unpinned 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.
How does this work practically when the vuln exists only in the minified version of the code?
Re: Backdoor in event-stream library dependency
#104Well, it would not happen if people used Elm :)
Re: Backdoor in event-stream library dependency
#105Earlier quoted context omitted.
The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.
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…
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
Re: Backdoor in event-stream library dependency
#106Earlier quoted context omitted.
The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.
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…
End-users are harmed and are not licensees, and so, even if the license disclaimers are effective (boilerplate disclaimers are often broader than the law of some jurisdictions will give effect to) the claims they would have for negligence would not be covered (and would not be transferred to downstream maintainers, who likely have concurrent liability, absent a indemnity clause as well as a disclaimer in the license.)
So, while I don't think the upthread claim was about the maintainer having legal responsibility, I don't think it would be entirely wrong, even with the license text, if it did.
Re: Backdoor in event-stream library dependency
#107I 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…
No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.
then we might want to question why the community sees silently pulling in updates as "best practice". Is it?
Seems like a double-edged sword.
Re: Backdoor in event-stream library dependency
#108> 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…
That doesn't look that far off from what you'll see in generated code, e.g. something like babel could easily output the lines you've pasted.
The rest of it is extremely dodgy, of course.
Re: Backdoor in event-stream library dependency
#109Earlier quoted context omitted.
I'm not a crypto guy but this change really makes me scratch my head: https://github.com/right9ctrl/node-scrypt/commit/52a1cb792bc...
Yes, that looks dodgy - a 64-bit 'N' being renamed 'logN', and its value changed to `1` left shifted by its prior self? I think there's a good bet that's just zeroing it out.
It's just doing 2^logN...
Re: Backdoor in event-stream library dependency
#110I 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…
No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.
A reasonable position -- and obviously better in this case -- but in general I'm not sure most people agree. The overwhelming majority of the time maintainers are not malicious.