Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

291–300 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#291
post #11

Earlier quoted context omitted.

If he can do as he pleases, can't GitHub as well?

They can and they did, but it still feels malicious because they intentionally reverted the maintainer's latest version, which is the author's will on their creation. It's a bit like me going to my bank to close the account and instead they throw me out and keep my money. Honestly I don't understand why microsoft did anything at all. Can't people just pin a version?

doesn't npm have policies for packages to follow semvar? I could see why they would have policies to rollback broken minor versions that are distributed via npm.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#292
post #221
post #179

Earlier quoted context omitted.

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 ver…

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…

Go does this well. It chooses the minimum viable version that satisfies the constraints for each package.

The minor security updates are solved well by periodically running security linters and scanners. There's even a recent GitHub feature for it. That will alert you that you need to update a package.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#293

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

after an initial kneejerk reaction, i've realized that this is a really complicated issue to think about.

the future is exhausting sometimes.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#294

Here'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?

I prefer to look at the code, decide if A. it's worth it, B. it wouldn't be funner/better to just clone it as a 'plugin' in my own code, and C. it looks like it has a good team/support around it.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#295

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

I don't understand why. It's his code to break if he wants. But I guess when you use a social media service to host your code these are expected and normal results.

> It's his code to break if he wants.

This is a library, not standalone software. Breaking it means breaking the code of every software which uses that library.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#296

Earlier quoted context omitted.

None of these points have any legal standing, from a copyright perspective. https://news.ycombinator.com/item?id=29868199

You are technically correct. The best kind of correct! In practical terms, it depends on the license used. Since most licenses used in open source will prevent you from making these kind of requests, this consequence isn't likely to have any practical implications.

You are assuming that the true rights holders of all the code in the package actually agreed to the given license. Someone unrelated to the package development can still claim it includes an illegally-copied, unlicensed version of their code.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#297
The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects).

We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software development, and minimum industry standards, so software can be certified to have the bare minimum of quality and safety processes.

Things like an upstream dependency breaking can be caught well before it makes it into downstream projects. But you need the process in place to catch it. We all know what we're supposed to be doing, but few people actually do it, for all sorts of reasons (no time, no money, didn't think it was important, didn't know how to do it, etc). I think we should have regulation to require it, and an actual body that regulates how this is done, just like in every other "real" engineering discipline.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#299
post #145

Earlier quoted context omitted.

You're using a VCS I presume? Why not just rollback?

you mean roll back package-json.lock or package.json? yeah, but thats not really what i want. maybe my process is crazy here, but this is how i update dependencies: on a somewhat regular basis, as time allows, i run npm update to bring all my dependencies to the lastest version. then i test (including thorough manual testing / qa), commit, and release with updated dependencies. if some update is broken and i don't ha…

I'm confused. You're looking for a way to go back to the last good version. By your methodology wouldn't that be before you last updated? Or are you looking for a curated service?

A reasonable maintainer semvers their packages.

You shouldn't update to the latest version if you want to minimize the likelihood of issues. That's what stable releases are for

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#300
post #175

Should 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.

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
Post reply on HN