GitHub 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?
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
191–200 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#192Earlier quoted context omitted.
There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.
Stale libraries are more likely to contain known security vulnerabilities.
You’re free to update as you like. It’s entirely possible to audit your local packages.
Letting maintainers update your projects is a convenient feature. If it is a liability in your use case you can work around it. Yes it will take more effort, but your use case justifies it.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#193Earlier quoted context omitted.
look at diffs?
Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
Fortunately the problem could become more tractable if something like SES / Endo takes off:
"Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies."
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#194i 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?
Rollback what? You can't rollback someone else's dependencies.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#195GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
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 thought it was hacked, which is almost reasonable.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#196Earlier quoted context omitted.
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?
Who are you to decide what is useful/legitimate or not? As a user of $ExampleLibrary, I surely know best what's useful rather than the maintainer.
> Who are you to decide what is useful/legitimate or not?
Common sense.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#197Earlier quoted context omitted.
Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.
*I revoke my comment. Child comment is correct.
That's not true.
The first line of NPM install's documentation[0] says(emphasis mine):
> This command installs a package, and any packages that it depends on. If the package has a *package-lock or shrinkwrap file, the installation of dependencies will be driven by that*, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm shrinkwrap.
What does happen is: if you have added a new package in package.json it will be installed based on the semver pattern specified there, or if you run npm install some-package@^x.y.z the same thing happens. Further, if you modify package.json by changing the semver pattern for an existing package that will also cause this behaviour.
Running `npm install` in a package that already has a package-lock.json will simply install what's in package-lock.json. `npm install` only changes the lock file to add/remove/update dependencies when it detects that package.json and package-lock.json disagrees about the specified dependenices and their semver patterns e.g. having foo@^2.3.1 in package.json and foo@1.8.3 in package-lock.json will cause foo to be update when running `npm install`.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#198Earlier quoted context omitted.
Not only does it require more steps, it also has to meet the following criteria[1]: * no other packages in the npm Public Registry depend on * had less than 300 downloads over the last week * has a single owner/maintainer So while your point is taken that unpublishing is possible under some circumstances, it is not for popular packages that are in use today. [1] https://docs.npmjs.com/policies/unpublish
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.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#199Earlier quoted context omitted.
> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
> If NPM gets a DMCA takedown request they will absolutely have to fulfill it. Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown? I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder withou…
> I don't think you can make a DMCA request on behalf of a copyright holder without their permission
Tell that you Youtube's copyright trolls
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#200i 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?
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 have time to fix it then yeah, i can roll back. but the point is to be on relatively up-to-date version of as much as possible, so if something is broken then it turns into a game of trying to figure out which library it was that broke things. i don't want to just not update any dependencies because something is broken.