Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
51–60 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#52Earlier quoted context omitted.
But if the API offered a function called .countBy but then renamed that function to be .countAllBy, now I can't run my application anymore, causing my service to go down if I upgrade the version without testing it, is that a DoS now?
no. is it really that complex of a concept that intent of a change matters too, and introducing an endless loop to cause trouble to users is different from a legitimate API change that does a useful thing?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#53Earlier quoted context omitted.
Why would the developer of any software that comes explicitly without warranty be hold responsible for downstream breakages? It's not as if one could force people to upgrade to newer versions and they can always keep depending on the old releases.
In this case, the developer's behavior was malicious: they intentionally caused damage. This is very different than some good faith change that breaks stuff downstream. Sure, the license says "no warranty". But github can decide that they won't tolerate vandals on their platform. It would be within their right to revert the bad change from the git database they hold, go back to the last good change and lock the devel…
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#54Earlier quoted context omitted.
Why would the developer of any software that comes explicitly without warranty be hold responsible for downstream breakages? It's not as if one could force people to upgrade to newer versions and they can always keep depending on the old releases.
From the point of view of GH the license is irrelevant, what they see is that a project they host is in practice being use to distribute malware.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#55Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#56Here'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…
To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them
You also can't unpublish once a single person has downloaded the package, I believe.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#57My 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.
Expecting compensation for a gift is the error.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#58Here'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…
To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#59Anyone knows what the author meant by the "LIBERTY LIBERTY LIBERTY" message? It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#60Here'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…
To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them