The episode underscored the fact that dependencies between NPM modules remain an unsolved problem — and 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 rename his module named “
kik” after receiving a note from a lawyer at the company that makes the Kik mobile messenger product. (The makers of Kik have since published their discussion of events.)
Disgusted with the way the owners of NPM appeared favor Kik 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, those projects no longer installed from NPM.
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 — such as 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 long-standing limitations. Developer Resi Respati noted several limitations in his analysis of the
left-pad case, chief among them 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 sneaking in and doing something untoward. A discussion is currently under way, 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, 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 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, that 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.