News

After npm JavaScript Package Fiasco, Firm Changes Policy, Says 'We're Sorry'

• By David Ramel
• March 30, 2016

It's been a tough week for npm Inc., the company that runs the popular npm node package manager for Node.js that lets JavaScript developers easily incorporate pre-built modules into their projects.

Last Tuesday, a squabble about the naming rights of one such module led to a chain of events that resulted in thousands of JavaScript builds instantly breaking around the globe, causing disruptions and angst for many developers (including this reporter).

Although the outage was short-lived -- fixed in about 2-1/2 hours -- it raised many questions about the company's policies regarding the rights of contributing developers to "unpublish" their modules. In a spat about the naming rights of one such module named kik (which resulted in a company called Kik Interactive Inc. threatening legal action), the module's creator, Azer Koçulu, un-published all his modules, removing them from the registry. One of those modules, left-pad, was especially crucial in that it was used in other popular services such as Babel, which caused the thousands of breakages.

That led npm Inc. to take the "unprecedented" step of "un-un-publishing" the module to get things working again. The whole thing caused a social media furor in which many people attacked the company's management and policies. Koçulu explained his side of things in a Medium post titled "I've Just Liberated My Modules." Kik the company also posted its side of the story. npm Inc. also blogged about its take on the events.

The whole fiasco resulted in a blog post yesterday by npm Inc. titled "changes to npm's unpublish policy" (apparently the company has a thing about capitalization) in which it offered a mea culpa:

One of Node.js' core strengths is the community's trust in npm's registry. As it's grown, the registry has filled with packages that are more and more interconnected.

A byproduct of being so interdependent is that a single actor can wreak significant havoc across the ecosystem. If a publisher unpublishes a package that others depend upon, this breaks every downstream project that depends upon it, possibly thousands of projects.

Last Tuesday's events revealed that this danger isn't just hypothetical, and it's one for which we already should have been prepared. It's our mission to help the community succeed, and by failing to protect the community, we didn't uphold that mission.

We're sorry.

Under a new policy, developers can unpublish their wares if they're less than 24 hours old. If a package is older than that, a series of steps have to be taken involving the company's support staff. "If you contact support, they will check to see if removing that version of your package would break any other installs," the company said. "If so, we will not remove it. You'll either have to transfer ownership of the package or reach out to the owners of dependent packages to change their dependency."

There is also now a provision to replace removed packages with a "security placeholder package."

As if that whole situation wasn't bad enough, since last week's event, news has emerged about a "package install scripts vulnerability" in which "it is possible for a maliciously written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user."

That, along with the package publishing kerfuffle, will likely lead to increased debate about the dangers of relying on third-party dependencies in your coding projects.

How it all plays out in the end remains to be seen.