5 ms·

I don't see how any of these reasons are why npm is "fundamentally insecure" any more than any other system involving humans.

hayksaakian 9y ago
maybe there should be some type of 2 factor authorization to make sure you can't get in by guessing someone's insecure password, or grabbing it from a leak (due to password reuse).
- bonestamp2 9y ago
  Requiring it would be wise, or at least requiring it if any other packages depend on it. They're going to destroy the ecosystem if they can't secure it. One major blow and nobody will trust it anymore.
stickfigure 9y ago
The npm community has a longstanding habit of depending on dynamic version numbers, eg "^1.2.3". Until the recent advent of package-lock.json, normal builds would pull in "whatever was latest"; any compromised upstream dependency would automatically propagate downstream as fast as their CI systems run. Also, builds are pretty much irreproducible. The maven world, by contrast, is habituated to fixed version numbers for dependencies. A fake release might affect folks downstream that explicitly choose the upgrade, but it won't be automatic. package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought.
- always_good 9y ago
  package-lock.json doesn't do anything for security unless you're going to walk the upgrades of each transitive dependency before you run `npm upgrade` (since each dependency can run arbitrary code while installing). So I wouldn't say it solves any of the security issues, just gives you a commitable snapshot of your deps. One of the many things the npmjs.com website needs to do is provide a code viewer for each version of a package. It's a bit annoying that you have to unpack a tarball just to see the code you're going to be running if you install it. Right now everyone just takes for granted that if a NPM package links to a Github repo, that that's the code you're going to be executing. Nothing is going to solve the explosion of transitive deps though without some sort of cultural change. I don't see that ever happening. I do like the ecosystem of tiny libraries but it's too large of a trade-off for security sensitive applications imo.
- mercer 9y ago
  > package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought. Just the other day I caught myself feeling frustrated that I had to manually add a dependency + version number in my mix.exs (Elixir package manager), just because I got so used to doing 'yarn add <package>'. And that's despite the fact that I for quite a while now I have also been feeling a bit weird about just adding packages to my project for the exact reason discussed here (as well as the 'leftpad' fiasco). It's both fascinating and a bit scary how easy I just do things 'the way everyone does' despite knowing better, and I hope we'll find some solution that could be applied community- or ecosystem-wide.
always_good 9y ago
What makes this a problem is that the NPM ecosystem has so many transitive dependencies. Which is why a left-pad fiasco can even happen in the first place.
vacri 9y ago
Perhaps look at an OS packaging system. Debian has a particularly robust one, and it simply couldn't be brute-forced like this (as it's key-based). Even just simply forcing 2FA would be a significant improvement.

hayksaakian 9y ago

maybe there should be some type of 2 factor authorization to make sure you can't get in by guessing someone's insecure password, or grabbing it from a leak (due to password reuse).

bonestamp2 9y ago
Requiring it would be wise, or at least requiring it if any other packages depend on it. They're going to destroy the ecosystem if they can't secure it. One major blow and nobody will trust it anymore.

stickfigure 9y ago

The npm community has a longstanding habit of depending on dynamic version numbers, eg "^1.2.3". Until the recent advent of package-lock.json, normal builds would pull in "whatever was latest"; any compromised upstream dependency would automatically propagate downstream as fast as their CI systems run. Also, builds are pretty much irreproducible. The maven world, by contrast, is habituated to fixed version numbers for dependencies. A fake release might affect folks downstream that explicitly choose the upgrade, but it won't be automatic. package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought.

always_good 9y ago
package-lock.json doesn't do anything for security unless you're going to walk the upgrades of each transitive dependency before you run `npm upgrade` (since each dependency can run arbitrary code while installing). So I wouldn't say it solves any of the security issues, just gives you a commitable snapshot of your deps. One of the many things the npmjs.com website needs to do is provide a code viewer for each version of a package. It's a bit annoying that you have to unpack a tarball just to see the code you're going to be running if you install it. Right now everyone just takes for granted that if a NPM package links to a Github repo, that that's the code you're going to be executing. Nothing is going to solve the explosion of transitive deps though without some sort of cultural change. I don't see that ever happening. I do like the ecosystem of tiny libraries but it's too large of a trade-off for security sensitive applications imo.
mercer 9y ago
> package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought. Just the other day I caught myself feeling frustrated that I had to manually add a dependency + version number in my mix.exs (Elixir package manager), just because I got so used to doing 'yarn add <package>'. And that's despite the fact that I for quite a while now I have also been feeling a bit weird about just adding packages to my project for the exact reason discussed here (as well as the 'leftpad' fiasco). It's both fascinating and a bit scary how easy I just do things 'the way everyone does' despite knowing better, and I hope we'll find some solution that could be applied community- or ecosystem-wide.

always_good 9y ago

What makes this a problem is that the NPM ecosystem has so many transitive dependencies. Which is why a left-pad fiasco can even happen in the first place.

vacri 9y ago

Perhaps look at an OS packaging system. Debian has a particularly robust one, and it simply couldn't be brute-forced like this (as it's key-based). Even just simply forcing 2FA would be a significant improvement.