4 ms·

My impression is this is really just to have some sort of comparable feature to deno. You may think this somehow is more of a vulnerability, but the reality is

My impression is this is really just to have some sort of comparable feature to deno. You may think this somehow is more of a vulnerability, but the reality is the npm registry is already fairly insecure, we've seen npm packages get hijacked regularly. This also adds less dependence on npm, and maybe with all the packages that get hijacked there, this could be a reasonable move.

junon 5y ago
I'd really argue "regularly" is a bit much. It happens rarely and moving to URIs is only shifting the problem. I'd also argue the claim npm is insecure. How would you improve its security over what's there now? Lastly, there isn't really a dependence on npm at all. You were always able to 1) put URIs into package.json, and 2) make your own package manager. Node does not require npm to work. It just looks in node_modules by default, which npm uses to manage packages for you. They are completely decoupled. URI imports, on the other hand, have a lot of security problems and surface area and will probably face a load of criticism going forward.
- dmitryminkovsky 5y ago
  > How would you improve its security over what's there now? Automated builds on NPM servers based on code in public repos, like Docker has (had?). The least they could do is require packages to be signed.
  - junon 5y ago
    How exactly does that help?
    - potatoz2 5y ago
      Controlled builds based on public repos prevents a malicious person (original author or not) from invisibly pushing a packages that doesn’t correspond to public sources. Signing packages prevents account takeovers from publishing bad packages. The remaining security problem is the author themselves coupled with too few eyes on public repos.
      - junon 5y ago
        I fail to see how controlled builds would have prevented Marak pushing a patch release that broke everyone. Most malicious package activity I've seen has been at the hands of the original maintainers to begin with. The last thing can't be solved technologically.
- mrozbarry 5y ago
  Yeah, a bit of hyberbole, but I think my point is it's been proven to be relatively simple, or at least simple in theory. I think npm could improve security with two steps: 1) all packages must be user-or-organization/package-name, and 2) all packages need to be signed with a key. Have namespaced-by-default packages at least will give a path for developers to trust an author or source. Signed packages would give developers the means to trust a key. All systems that allow public packages to be published are going to have inherit security flaws, and the best security I think we can give is trust. It's easy to invalidate a key, and it's easy to flag a namespace as untrustworthy. While there is no "dependence" on npm, most package managers ship node with npm, and the typical flow for a node app, according to most tutorials and community documentation, is to use npm. Even most of the tools a developer would use with node are npm-centric (documentation almost never recommends cloning the repository, just npm install). So I'd agree, decoupled in reality, but is perceived as reality among tutorials and the community.

junon 5y ago

I'd really argue "regularly" is a bit much. It happens rarely and moving to URIs is only shifting the problem. I'd also argue the claim npm is insecure. How would you improve its security over what's there now? Lastly, there isn't really a dependence on npm at all. You were always able to 1) put URIs into package.json, and 2) make your own package manager. Node does not require npm to work. It just looks in node_modules by default, which npm uses to manage packages for you. They are completely decoupled. URI imports, on the other hand, have a lot of security problems and surface area and will probably face a load of criticism going forward.

dmitryminkovsky 5y ago
> How would you improve its security over what's there now? Automated builds on NPM servers based on code in public repos, like Docker has (had?). The least they could do is require packages to be signed.
- junon 5y ago
  How exactly does that help?
  - potatoz2 5y ago
    Controlled builds based on public repos prevents a malicious person (original author or not) from invisibly pushing a packages that doesn’t correspond to public sources. Signing packages prevents account takeovers from publishing bad packages. The remaining security problem is the author themselves coupled with too few eyes on public repos.
    - junon 5y ago
      I fail to see how controlled builds would have prevented Marak pushing a patch release that broke everyone. Most malicious package activity I've seen has been at the hands of the original maintainers to begin with. The last thing can't be solved technologically.
mrozbarry 5y ago
Yeah, a bit of hyberbole, but I think my point is it's been proven to be relatively simple, or at least simple in theory. I think npm could improve security with two steps: 1) all packages must be user-or-organization/package-name, and 2) all packages need to be signed with a key. Have namespaced-by-default packages at least will give a path for developers to trust an author or source. Signed packages would give developers the means to trust a key. All systems that allow public packages to be published are going to have inherit security flaws, and the best security I think we can give is trust. It's easy to invalidate a key, and it's easy to flag a namespace as untrustworthy. While there is no "dependence" on npm, most package managers ship node with npm, and the typical flow for a node app, according to most tutorials and community documentation, is to use npm. Even most of the tools a developer would use with node are npm-centric (documentation almost never recommends cloning the repository, just npm install). So I'd agree, decoupled in reality, but is perceived as reality among tutorials and the community.