The whole episode underscored the fact that interdependencies between NPM modules remain an unsolved problem — and that legal pressure on software developers can have repercussions far beyond the obvious.
How the chain broke
Developer Azer Koçulu, with dozens of modules registered in his name on NPM, stated he had been advised to remove his module named "
kik " after receiving a warning letter from a lawyer at the company that makes the Kik mobile messenger product. In disgust at the way the owners of NPM appeared to be on Kik’s side, and no longer wanting to share his work there, Koçulu removed — "unpublished" — all of his modules from NPM.
"[I] apologize … if your stuff just got broken due to this," he wrote. Koçulu suggested that those who relied on dependencies with one of his modules point instead to a version now hosted on GitHub .
Unfortunately, many people weren’t able to take that advice immediately. One of the missing modules,
left-pad missing , those projects no longer installed from NPM.
The left-pad module on NPM was eventually " un-unpublished " and assigned to a new owner (developer Cameron Westlake). Dependent projects once again became installable. But the damage had been done, and for many NPM users the episode served as a reminder that NPM has fragilities that need addressing.
The damage(s) done
Two big issues have reared their heads in the wake of these events. First, copyright and trademark challenges in the software world can do immediate and widespread damage.
Few provisions exist for dealing with a package that suddenly goes missing from a public software repository. It’s typically left to whoever installs the software to deal with extraordinary circumstances — e.g., when a repository is taken offline by a spurious DMCA request .
This leads directly into the second issue: Package handling on NPM is fraught with many long-standing limitations. Developer Resi Respati noted several limitations in his analysis of the left-pad case, a chief one being the way the NPM namespace is global — all packages share the same namespace and are registered on a first-come first-served fashion. (GitHub, by contrast, employs a username/project namespacing system.)
Unpublishing a package in NPM frees up its name for someone else to use, meaning there’s no guard against another package of the same name being sneaked in that does something untoward . A discussion is currently underway, to add signing and certification to Node.js package handling, but has yet to produce a working solution.
Picking up the pieces
At least one project exists as an alternate way to perform package management for Node. The ied project proposes several changes intended to solve some of the issues described above. Packages are identified by their SHA-1 checksums, and not merely by a package name, which guarantees that packages are unique and can’t be confused with (or arbitrarily substituted for) each other. Semantic versioning is also supported, so that a specific version of a package can be fetched.
The design of the early Internet assumed that trust exists between all parties, an assumption that was fine for a closed-ended, academic environment. But as the Internet went public, t hat assumption has turned into a time bomb, as criminal attackers learned to leverage obsolete protocols or exploit limitations in existing ones .
In the same way, many of the unquestioned assumptions about how NPM works — and, more generally, how public software repositories work — may have their biggest tests ahead of them.