Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

971–980 of 1001 posts

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

#971

Post by newaccount74 »

Siira wrote: post #969
rezonant wrote: post #954

Earlier quoted context omitted.

I'm very familiar with the GPL, I just meant folks would rather find non-GPL alternatives. For a library that wraps a few ANSI terminal codes to enable color and provides a bunch of fake data for testing, I think finding alternatives (or just writing them yourself) wouldn't be hard.

I guess the OP means that it would be too late to replace the AGPL code if the company has already published a version including it. My unexpert opinion agrees with the OP.

I seriously doubt that courts would side with someone who tricks people into downloading code with a different license.

Especially since changing the license of a project from MIT to AGPL doesn't suddenly revoke your rights that you had under the MIT license -- only new code would be affected by the license change.

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

#972

Post by CRConrad »

zaroth wrote: post #602
JimDabell wrote: post #593

Earlier quoted context omitted.

> Packages are literally remote code exec vulns in the hands of package authors Something mentioned in this article caught my eye: > While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me pe…

This seems like irresponsible speculation and insinuating that Marek is about to commit a felony? I’d rather skip the character assassination based on hypothetical future actions please, and focus on what’s actually happened.

> This seems like irresponsible speculation and insinuating that Marek is about to commit a felony?

No, it's speculation that Marek didn't do any of this, but that instead his account was hacked. You either responded to the wrong comment by mistake, or totally misunderstood the one you replied to.

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

#973

Post by 5ESS »

say, instead of making the new version of his program cease to function for everybody entirely, he decided that the new version of his program was no longer going to be free, and if users wanted to utilize the newest version they must pay a fee. Say he introduced code instead that checked if a license was purchased for the software, and if so the program works, and if not the program halts. Would this have been considered a "malicious" act as well? Is it wrong these days to charge money for your hard work?

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

#974

Post by CRConrad »

cmckn wrote: post #917
sibit wrote: post #816

Earlier quoted context omitted.

As someone who does front-end JS stuff and uses a bunch of packages here is why I do it: I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. I also don't like how bloated a bunch of the "popular" packages are.…

> I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describ…

> Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing.

Exactly what I thought. Fascinating how they can have missed this obvious solution.

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

#975

Post by cerved »

umvi wrote: post #288
cerved wrote: post #269

Earlier quoted context omitted.

Your source code obviously

In this case, the problem isn't in your own source code, it's in someone else's source code.

but package.json and package_lock.json presumably are

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

#977

Post by slingnow »

newaccount74 wrote: post #821
heurisko wrote: post #762

Earlier quoted context omitted.

> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

This just seems like willful ignorance and has very little to do with package managers. If you were interested in looking at the code, a quick google search or running `--help` would go pretty far.

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

#978

Post by hinkley »

DominikD wrote: post #804

Unsurprisingly the majority of comments here focus on "how to prevent my free dependencies from breaking" instead of "can we have a systemic way of supporting developers that maintain critical software".

It's almost as if showy acts of violence/shock don't engender constructive attention.

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

#979

Post by prepend »

marcus_holmes wrote: post #842
prepend wrote: post #832

Earlier quoted context omitted.

The package ecosystem is growing and there’s more good packages each year. 10 years isn’t 30, but it’s still a long time to show success. That’s there’s only been a few problems like this despite millions of users is a sign of strength. I hedge by pinning yo specific versions and keeping my own package manager (RStudio) to keep mirrors if the packages I scan. That the packages are open source means they are easier to…

Success != sustainability. If a thing has an expiry date that is >10 years, then you're not going to see any problems for 10 years. That doesn't mean the expiry date doesn't exist, or that the thing won't hit it. It can be wildly successful for all those years and then hit the expiry date and stop immediately.

It’s not necessarily the same, but it’s a good co-signal. And definitely useful for refuting emotional, data less calls that the sky is falling.

I’ll take a decade of success as a sign of sustainability over a package maintainer losing their shit as a sign of h sustainability.

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

#980

Post by CRConrad »

evouga wrote: post #556
sillysaurusx wrote: post #195

Earlier quoted context omitted.

This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…

For a long time I've owned a premium GitHub account and would roll my eyes at colleagues who insisted on using GitLab, as I felt that GitHub had a clearly superior user experience. I have to say, though, that every time in recent memory that GitHub has popped up in the news, it's for something that's made me sigh. The only thing still keeping me one of their customers is the painfulness of transferring over all of my…

> The only thing still keeping me one of their customers is the painfulness of transferring over all of my existing repositories.

What's so painful about "git clone"?

Oh, you mean you've locked yourself into GH by using some of their proprietary extensions, that isn't present in vanilla git?

But how is this even possible? Whenever someone dares claim that Microsoft never abandoned its old "EEE" strategy ("Extend" being the middle of the three Es), legions of HNers always rush to defend them and praise their conversion to Good Guys!

Post reply on HN