Why do I have the sneaking suspicion that someone is going to “solve” this with blockchain?
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
711–720 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#712Try to look at it from another point of view. Marak is fed up of all these billion dollar companies (and other small projects) using his code, he has some financial problems and so he decides to teach them a lesson. I sympathize and for sure if I were responsible for a big company and I was using an open source component/project I would donate something. We all have to rethink of how the open source funding is suppos…
Maybe OSS projects should start with a different default license than MIT
There is no default license. You are the one to pick and choose and commit it to your repo.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#713Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…
I think it’s a bad stunt that outlines an issue with mega corps using oss and blindly updating their packages. Or anyone blindly updating their packages really. But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.
GitHub is private property, and they have the right to eject anyone from their property for any reason or even no reason at all.
And the code is open-source under the MIT license, so GitHub can do with it as they see fit.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#714Earlier quoted context omitted.
The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…
> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fault of the person deliberately updating their package to break other people's software.
Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#715Earlier quoted context omitted.
> I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one…
Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You…
> This sounds increasingly like security theater.
It does help. Quite a bit.
Each layer (e.g. firewall rules that require that all internet access go through a proxy), adds non-trivial amount of work for the hacker to get anything useful done.
1. best case - hacker will give up.
2. good case - you have more time to notice and react.
How much layer cost you, how much does it cost for hacker to overcome it.
Things to remember:
1. Not all hackers are nation states. Most are not.
2. We must accept that no security measure is absolute even against script kidies. Given enough time and luck/misfortune js sandbox will do "rm /sensitive/file".
Recent Log4shell example shows that one can follow all best practices and still get bit in unexpected way.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#716Earlier quoted context omitted.
> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fault of the person deliberately updating their package to break other people's software.
Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.
It’s one side of the coin.
The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff.
It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#717Earlier quoted context omitted.
I'm not entirely versed in NPM politics, but: 1) GitHub and npm are supposed to be separate things. There might be stuff in that GH account that affects other ecosystems. By all means block the npm account, but that should be it. 2) in the end, one is responsible for the packages one pulls. We keep relearning that lesson over and over, because global package repositories made us lazy.
> GitHub and npm are supposed to be separate things. Is that going to be true forever? I would assume not. There is already much deeper integration between github and npm than there was a few years ago, and Github seems to be going fairly deeply into CI and distribution.
If that's the case, people will have to start practicing account hygiene...
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#718It's funny how so many people bitch about "responsibility" or point out that "well, aws & co. are allowed to use the code because loicense"
Have any of these keyboard-warriors ever read a FOSS license? There's a huge fucking disclaimer at the bottom in all caps saying "this code does whatever use at your own risk".
So what? Is the author bound to the moral implications that their users assume the code actually works, but it's totally okay for amazon to completely disregard the open source ideal of "give and take" because the license technically allows them to?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#719Earlier quoted context omitted.
The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging systems. And even then you need a way to source exactly that version without relying on the original author's cooperation. Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a wh…
That's what .lock files do though.
Not sure if that is even enough, at least in NPM the .lock files work on semantic versions, not commits. I'm not sure if NPM enforces you to change the semantic version with each commit.
And even if all of that works, you still run head first into the issue once you inevitably upgrade the dependencies.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#720Earlier quoted context omitted.
My parents always taught me not to take donuts from unknown people, especially when they're free. It's common sense and corpos take all fault for taking an easy fix to save their own developer hours at someone's else expense. Now, when it turns out there are consequences to this, corpos aren't that happy.
With that argument, you might as well say that open-source/free software shouldn't exist.
My argument is that you shouldn't automatically trust it just because it's free. You shouldn't rely your entire infrastructure, and, perhaps, life, on it. If you do, there is no one at fault but you, because you passed all the responsibility to someone you have no control over. You are not entitled to protection and safety from the side of developer just because you said you rely on them - they are not going to carry your burden when it's not their job to do so.
Either you stay cautious, in which case you maintain your own forks for your own business or reinvent the wheel, so you don't rely on others that much, or you admit that you can't just reject this dependency - in which case it becomes either a public infrastructure, or a "donut business" on its own, and both should be financed as such. Take Linux as example, Linux is backed up by corporations and financing because everyone understands how crucial Linux is for our living. People took all the necessary steps to guarantee that kernel dev team is not going to disappear at any moment.
This is not the first and not the last time this happened. For some reason people think that open-source devs owe them something just because they had the right to bring their projects into existence. Javascript environment especially suffers from it because of unknown obsession of people to depend on packages which contain 1-2 lines of code at best, packages that can disappear at any moment.
Faker dev acted maliciously, but no one could guarantee that he wouldn't. No one was there to care about his mental state, or his wallet contents, and only relatively small companies and few people donated to his project, something he worked on for over a decade.
Sure, you can blame him all the way you want, but that won't undo the damage. If you rely on something maintained by an individual, you have to take into account that this individual is an actual human, this human actually exists and like any other human he is a subject of free will and uncertain futures, and whatever risks come with it. If you don't, this is what happens to you.