GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
Was it a paid or "free" account?
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
671–680 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#672Earlier quoted context omitted.
I don't think he cares at this point. I think this is a person that has been driven to the absolute end of their patience. If he's really barely been getting by, then I can only imagine the sheer frustration he must be feeling. Not only are there swathes of fortune 500 companies which depend on his package but don't contribute a dime, but he also had a company with millions of dollars in funding look at his idea and…
His twitter page complaining that his github got locked-up suggests he cares. I am not unsympathetic, but only because, I am starting to see this more as an effort to undermine open source as a movement/cause.
Then again he seems quite proud of getting banned from Github in 2013 for "creating a script that forced people to watch a library that [he] created": https://youtu.be/varf6oWaFtU?t=202
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#673Earlier quoted context omitted.
marak has a documented history of mental illness and downright odd behavior. Talented dev and troubled individual. There's a pretty concise video covering what went down with some history here: https://www.youtube.com/watch?v=R6S-b_k-ZKY
Quoted post unavailable.
No post body was provided.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#674Earlier quoted context omitted.
"inspired" my ass. It's a fork, not keeping the licence terms. https://news.ycombinator.com/item?id=27254092
seems like he has a history of this (HN 2010): https://news.ycombinator.com/item?id=1448309
You may also enjoy "Jim deletes the tenth grade":
https://web.archive.org/web/20081020082418/http://www.jimbas...
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#675This guy again? Last time I seen something posted they were being looked into for bomb making after some kind of fire.
https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
The irony is that the guy was once banned on here for spamming their startup Nodejitsu
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#676Here'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…
I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?
In browser land, the less code you ship, the better. Removing dead js code is hard, because of its dynamic nature and using common js imports making it harder for treeshaking algorithms.
So, people had incentive to write and use smaller packages.
Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#677Earlier quoted context omitted.
How about using dependencies but pinning the version and only updating if you know what the update contains? 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.
> only updating if you know what the update contains People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.
Or we get a culture where upstream writes in more detail what an upstream is supposed to contain and downstream verifies that the update indeed does what they write. If this leads to fewer updates overall, I have no problem with that.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#678GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
If that is true it's an outrageous overreaction by GH. Are they now gatekeeping the kinds of code changes you can make to your own repo?
The maintainer was already temp-banned from GH around 2013 for "creating a script that forced people to watch a library that [he] created", whatever that means: https://youtu.be/varf6oWaFtU?t=202
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#679Earlier quoted context omitted.
> GitHub rarely takes action against accounts well, this just made the Hacker News front page a few minutes ago :-D https://news.ycombinator.com/item?id=29870151
DMCA notices have to be complied with else Github can get heavily penalized. This isn't Github's choice. DMCA is an entirely different beast, and it's not Github's fault that whole system is broken.
> DMCA is an entirely different beast, and it's not Github's fault that whole system is broken.
Microsoft and co. probably have the leverage to move that needle a little if they really wanted to.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#680Earlier quoted context omitted.
How about using dependencies but pinning the version and only updating if you know what the update contains? 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'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 can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.