As with every other human institution, the issue is "trust", or "civilization" as Bruce Scheneier has pointed out.
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
171–180 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#172i would pay for a service that runs an NPM mirror of a "last known good" version of packages to avoid this kind of thing. just keep all my dependencies a few weeks behind NPM to give things like this a chance to get caught, and let me continue blindly updating. every time something like this happens, the reaction in the comments is the same: well you should test your dependencies. and yeah, i do that before release,…
You're using a VCS I presume? Why not just rollback?
The replies here (and on twitter) really are making me realize a lot of the hurt that will possibly stem from marak's actions really were ripe to happen given the sheer number of javascript developers who don't understand at all what they're doing.
IT people for some reason tend not to be great at introspection which tells me this won't be fixed because this is more than just one asshole dude, this is a systemic issue with js and web development as a whole. This sort of thing would be really hard to accomplish in Linux for example because of the mentality they adopted early on when Linus had his first burn out moment, but the fact that even after leftpad nothing has changed really shows how systemically broken web dev is.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#173Imagine they introduced something worse. Could any developer explain to a manager why you needed to import this package? "Why do we need colors there?", "Why can't we make that colored ourself?"
At my last job we (InfoSec) had the devs fill out "ownership" forms for when they want to include something third-party into the product. Other than forcing the team to do due diligence on the third-party it also made them responsible for keeping it secure and them the people "at fault" if something went wrong due to it. While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful convers…
At my current job I'm trying to establish the same. Have to say, the recent news are water on my mills!
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#174I run locate and found both colors and faker on my laptop as dependencies of Postman. Color's license is MIT. Faker's is custom but basically MIT too.
The maintainer has every right to change his mind and/or stop maintaining those packages at any time. However the outcome (Fortune 500 companies using his work for free) is consistent with the choice of the license. With insight that was a mistake to start with. Maybe a FOSS license plus a commercial one would have bought him money but maybe those packages wouldn't become as popular as they are now. Everybody should dual license for mutual protection.
Finally, breaking other FOSS projects and not only commercial ones is not the nicest way to complain against companies not paying him. Furthermore, honest question, did he ask them for those money?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#175Should 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 couldn't help but think the same thing. Seems like an incredibly immature way to handle it. He could have easily set an end date and state nothing will be maintained beyond that date. It's not a good look.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#176Why not just change the license to GPLv3 for the upcoming version?
The truth is that it become a race to the bottom with a lot of open source projects, specially the ones that are not hard to replicate.
If the author made the project GPL, someone else would create a similar library with a more permissive license, which would end up taking the market and making the original library irrelevant.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#177GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
On what basis?!
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#178AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…
Sure. But that works both ways.
If you're not going to support the development in any way, then you don't get to have an opinion on what should be done or complain about bugs.
Honestly, even then, I think we're stretching it. Maybe at the surface it seems like it should be that way, but this isn't just some tiny package that a few companies are using. We're talking about tens of millions of downloads every week. This package has essentially gone and become public infrastructure, much like log4j.
The companies relying on it should realize as much and understand that it's in their best interest to ensure that the package keeps on being maintained.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#179Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…
Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context.
Pegging to a specific version limits exposure. Syncing these packages to your own on-prem/isolated environment limits it further. Deploying all changes to a test/staging environment where they're reviewed first limits it even more.
I mean yeah if your build process takes @latest of all your packages and then pushes it right into production, that opens you up to a lot of risk. It's also incredibly stupid for anything beyond a personal project (and probably even those).
This doesn't strike me as a weakness in package management, it strikes me as a weakness in doing package management wrong.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#180My sense is that it’s time to evolve licensing such that wealthy major consumers of packages that have become somewhat essential are naturally paying a licence fee. The problem is not in what the code does it’s a problem with the agreement for use.
When you publish free software you give it away as a gift. That's the point. Expecting compensation for a gift is the error.
Free as in freedom is not the same as free as in beer.
This model where someone develops something for free and then those that benefit the most don't contribute back isn't sustainable. I don't know if the packages owner was conscious about it but this was a political act and hopefully the impact will be positive.
From where we are we have two options: (1) companies find a way to make open source financially rewarding; (2) companies use their own crap instead.