5 ms·

So many people here seem to be missing the point by assigning blame to npm or node or whatever specifically. This situation could happen with packages in any

So many people here seem to be missing the point by assigning blame to npm or node or whatever specifically. This situation could happen with packages in any language.

abecedarius 8y ago
In e.g. E a module gets no authority to do anything but compute. You have to pass it the wallet explicitly.
- mdpopescu 8y ago
  This doesn't help as much as you think. Just as with the users, where if they want to see dancing rabbits they will accept everything and enter every password until they see dancing rabbits, in software the devs will try everything, including passing the wallet to an untrusted package, to make the damn thing work.
lugg 8y ago
Could. Yes. But many orders of magnitude less likely. This is why languages have standard libraries. It prevents the dependency hell we have with node.
- jononor 8y ago
  Reduces, not prevents.
  - lugg 8y ago
    Prevents vs acts to prevent. Sorry, I misspoke. Fact is. Nobody builds a standard library to reduce dependency hell. They do it to eliminate it. The standard library uptake, quality and efficiency is all intertwined sure and developers can always go shoot themselves in the foot anyway but, wait, I'm sorry, did you have a point?
    - jononor 8y ago
      No standard library contains everything most people need, and sometimes the stdlib version is not the preferred. Look for instance at Python. Lot of people use requests instead of urllib for HTTP client. No-one uses the HTTP server. Until 3.x no support for async IO or event loops, so we have Twisted/gevent/eventlet, mostly incompatible. My is only that there are painpoints around dependencies event with a stdlib.
simmons 8y ago
I agree 100%. I don't happen to use npm/Node, but I'm terrified that this could happen in the language/package ecosystems that I do use. I don't think that throwing wide-ranging functionality into the standard library is the answer, but I think with a bit of tooling it might be feasible to provide a "trusted" tier of packages that have been signed off on by code reviewers. Instead of every vendor needing to vet every dependency in their product, the work could be spread around. When a vendor finds they absolutely must have the functionality provided by a package in the untrusted "playground" (or whatever), they might be motivated to sponsor a review to upgrade it.

So many people here seem to be missing the point by assigning blame to npm or node or whatever specifically. This situation could happen with packages in any language.

abecedarius 8y ago

In e.g. E a module gets no authority to do anything but compute. You have to pass it the wallet explicitly.

mdpopescu 8y ago
This doesn't help as much as you think. Just as with the users, where if they want to see dancing rabbits they will accept everything and enter every password until they see dancing rabbits, in software the devs will try everything, including passing the wallet to an untrusted package, to make the damn thing work.

lugg 8y ago

Could. Yes. But many orders of magnitude less likely. This is why languages have standard libraries. It prevents the dependency hell we have with node.

jononor 8y ago
Reduces, not prevents.
- lugg 8y ago
  Prevents vs acts to prevent. Sorry, I misspoke. Fact is. Nobody builds a standard library to reduce dependency hell. They do it to eliminate it. The standard library uptake, quality and efficiency is all intertwined sure and developers can always go shoot themselves in the foot anyway but, wait, I'm sorry, did you have a point?
  - jononor 8y ago
    No standard library contains everything most people need, and sometimes the stdlib version is not the preferred. Look for instance at Python. Lot of people use requests instead of urllib for HTTP client. No-one uses the HTTP server. Until 3.x no support for async IO or event loops, so we have Twisted/gevent/eventlet, mostly incompatible. My is only that there are painpoints around dependencies event with a stdlib.

simmons 8y ago

I agree 100%. I don't happen to use npm/Node, but I'm terrified that this could happen in the language/package ecosystems that I do use. I don't think that throwing wide-ranging functionality into the standard library is the answer, but I think with a bit of tooling it might be feasible to provide a "trusted" tier of packages that have been signed off on by code reviewers. Instead of every vendor needing to vet every dependency in their product, the work could be spread around. When a vendor finds they absolutely must have the functionality provided by a package in the untrusted "playground" (or whatever), they might be motivated to sponsor a review to upgrade it.