Slashdot Mirror
Erroneous 'Spam' Flag Affected 102 npm Packages (npmjs.org)
There was some trouble last weekend at the world's largest package repository. An anonymous reader quotes the official npm blog:
On Saturday, January 6, 2018, we incorrectly removed the user floatdrop and blocked the discovery and download of all 102 of their packages on the public npm Registry. Some of those packages were highly depended on, such as require-from-string, and removal disrupted many users' installations... Within 60 seconds, it became clear that floatdrop was not a spammer -- and that their packages were in heavy use in the npm ecosystem. The staffer notified colleagues and we re-activated the user and began restoring the packages to circulation immediately. Most of the packages were restored quickly, because the restoration was a matter of unsetting the deleted tombstones in our database, while also restoring package data tarballs and package metadata documents. However, during the time between discovery and restoration, other npm users published a number of new packages that used the names of deleted packages. We locked this down once we discovered it, but cleaning up the overpublished packages and inspecting their contents took additional time...
In cases where the npm staff accepts a user's request to delete a package, we publish a replacement package by the same name -- a security placeholder. This both alerts those who had depended on it that the original package is no longer available and prevents others from publishing new code using that package name. At the time of Saturday's incident, however, we did not have a policy to publish placeholders for packages that were deleted if they were spam. This made it possible for other users to publish new versions of eleven of the removed packages. After a thorough examination of the replacement packages' contents, we have confirmed that none was malicious or harmful. Ten were exact replacements of the code that had just been removed, while the eleventh contained strings of text from the Bible -- and its publisher immediately contacted npm to advise us of its publication.
They're now implementing a 24-hour cooldown on republication of any deleted package names -- and are also updating their review process. "As a general rule, the npm Registry is and ought to be immutable, just like other package registries such as RubyGems and crates.io... However, there are legitimate cases for removing a package once it has been published. In a typical week, most of the npm support team's work is devoted to handling user requests for package deletion, which is more common than you might expect. Many people publish test packages then ask to have them deprecated or deleted. There also is a steady flow of requests to remove packages that contain contain private code that users have published inadvertently or inappropriately."
In cases where the npm staff accepts a user's request to delete a package, we publish a replacement package by the same name -- a security placeholder. This both alerts those who had depended on it that the original package is no longer available and prevents others from publishing new code using that package name. At the time of Saturday's incident, however, we did not have a policy to publish placeholders for packages that were deleted if they were spam. This made it possible for other users to publish new versions of eleven of the removed packages. After a thorough examination of the replacement packages' contents, we have confirmed that none was malicious or harmful. Ten were exact replacements of the code that had just been removed, while the eleventh contained strings of text from the Bible -- and its publisher immediately contacted npm to advise us of its publication.
They're now implementing a 24-hour cooldown on republication of any deleted package names -- and are also updating their review process. "As a general rule, the npm Registry is and ought to be immutable, just like other package registries such as RubyGems and crates.io... However, there are legitimate cases for removing a package once it has been published. In a typical week, most of the npm support team's work is devoted to handling user requests for package deletion, which is more common than you might expect. Many people publish test packages then ask to have them deprecated or deleted. There also is a steady flow of requests to remove packages that contain contain private code that users have published inadvertently or inappropriately."
This seems as good a place to leave my NPM story. Or I could just link to the bug.
The short version is if you use NPM to install dependencies, it will install your dependencies and whatever they depend on. If you run it again, it will install your dependencies and then DELETE anything they depend on.
Why would you repeat the install? Well, if your dependencies change (e.g., you update a dependency or add a new one), you would then repeat the install to get the new dependencies. Except you can't do this without blowing away the entire existing install due to this bug.
It gets somewhat worse - starting in NPM 5, they introduced a lock file. Anyone familiar with other package managers should know what a lock file is and why they're important. If the lock file exists, it will never install indirect dependencies (probably).
Basically, if anyone doubted that NPM was run by sloppy idiots, note that both bugs are still open and have been for months.
You are in a maze of twisty little relative jumps, all alike.