npm 5.7.0 takeaways: “We will make it even clearer to users when we publish a pre-release build”
Version 5.7.0 of npm caused quite a stir but the team reacted fast and released 5.7.1 less than a day later. We talked with Laurie Voss, co-founder and COO of npm about this issue and what npm is doing to make sure this doesn’t happen again. Laurie also revealed that there will be a clear indication if new versions are pre-release builds or stable releases from now on.
JAXenter: There was an issue with npm’s pre-release build 5.7.0 which caused quite a stir. What was it and how many people did it affect?
Laurie Voss: A pre-release build of npm, version 5.7.0, included a change to how npm creates directories on a developer’s file system. Shortly after we published 5.7.0 to the `next` distribution channel late in the evening of Wednesday 21st February, we learned that this change could unwantedly change ownership on some system files under a highly specific set of circumstances:
- if the user was running one of a handful of specific Linux distributions
- if the user invoked `npm` as `sudo` — i.e., they manually elevated their permissions
- if the user used npm’s `update` feature with the `global` flag
On the morning of Thursday the 22nd, we published version 5.7.1, which reverted the directory-creating patch.
Our logs tell us that fewer than 4000 developers used `npm update` to request 5.7.0‚ which is fewer than 0.6% of the developers who downloaded this release. (It is far more common to use the `install` command.) Of those 4000, the number who did so using one of the affected Linux distributions, and did so as sudo, is surely smaller, we estimate in the dozens. (On Thursday, the registry received more than 200 million download requests.)
JAXenter: What are the key takeaways from this incident and what are you doing to make sure it doesn’t happen again?
It’s even better to hunt down the dangerous parts of our product and build in proper protections so none of our users can actually hurt themselves with them.
We have already planned changes to how `update` behaves and is documented, and we will now make it even clearer to users, when we publish a pre-release build of npm, “Hey, this is pre-release software. Use this carefully.”
There are error messages in the product that read, verbatim, “I hope you know what you’re doing.” Even if this risks offending more senior developers, or at least making them roll their eyes, it may be that we need more of that kind of language. That being said, it’s even better to hunt down the dangerous parts of our product and build in proper protections so none of our users can actually hurt themselves with them. Warning language takes a lower priority than proper function in the first place.
JAXenter: Was there anything that users could have done to prevent the problem?
Laurie Voss: Almost no developers encountered the issue. It was shipped in 5.7.0, and reverted in 5.7.1 less than a day later; this was never included in the `latest` build that an average developer would install.
JAXenter: Some people claim they didn’t know this is a pre-release. Does this mean npm blog posts will indicate whether it’s a pre-release or a stable release from now on?
Laurie Voss: Absolutely. Already, our GitHub release notes for an update indicate that it’s a pre-release build, but starting this week, we will emphasize this when release notes are syndicated to npm’s blog. In addition, a project has been underway this year to improve npm’s documentation overall so that it’s easier for users to discover npm features, such as release tagging, and better understand how they work.
JAXenter: In light of recent events, how important is it to keep backups?
Laurie Voss: Responsible backup hygiene is fundamental to professional operations work. Regardless of anything that happens with specific tools, everyone should have backups for their systems, and verify that they’ve worked. Good backups are a basic responsibility of those tasked with maintaining an organization’s services.
JAXenter: This issue is a clear reminder that there’s a delicate balance between making npm more powerful and making it safer for developers. How important is the role of the community in the future of open source development?
Laurie Voss: The community is essential to open source software development. We have just thirty employees, but we also have a community of over ten million developers who can review our committed code, submit suggestions to our docs, and contact us — as they did on Wednesday night — when they spot a bug.
On top of this, in the last year, the fastest-hiring team at npm has been our support department. We take care of everyone in the community, not just customers of our paid products because it keeps the ecosystem safe and it’s the right thing to do.