Developers who rely on NPM, the JavaScript package registry created by the Node.js ecosystem, experienced a shock earlier this week when a small package removed from NPM unexpectedly caused many others to stop working.
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, with a mere 17 lines of code, was required by numerous major JavaScript projects, such as Babel. Without left-pad, 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 — 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.
Unfortunately, it isn’t likely these improvements will find their way to a larger audience — not so long as most Node.js and JavaScript developers continue to depend on NPM as their default.
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.
[Source:- Javaworld]
