You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Suggestion: add standard methods to limit APIs dependencies can use #92
I believe it might help to allow packages to set limits on which APIs can be accessed by the dependencies. This way, packages that do not need access to abusable resources such as FS access, networking and native bindings (those can access everything else) can be restricted from using them, reducing the impact in the event of packages whose job is mostly data processing (most body processors, utilities such as lodash) being compromised.
I believe the implementation does not need to be granular, and that with simply restricting access of a dependency (and all its childs).
While this is probably not the ideal way to implement sandboxing, I believe that some sandboxing method would be helpful.
I believe this has a overlap area with the scope, because being able to use dependencies without a fault in one of them causing a massive failure improves the maintainability of projects in my opinion.
Having to check if the dependencies are safe for usage is a maintainer problem.
Think, for example, of all the maintainers who, for example, got affected by the event-stream problem and had to immediately take action of replacing the dependency.
This feature would give the maintainer a reasonable time to make the change, without having anyone's security at risk.
Activity
boneskull commentedon Dec 13, 2018
I think this is probably out-of-scope
wesleytodd commentedon Dec 13, 2018
I agree that this is out of scope for this group.
I believe Ryan Dahl talked about this in his Deno presentation with flags to allow process access to certain api's, interesting stuff.
io4 commentedon Dec 13, 2018
I believe this has a overlap area with the scope, because being able to use dependencies without a fault in one of them causing a massive failure improves the maintainability of projects in my opinion.
Having to check if the dependencies are safe for usage is a maintainer problem.
Think, for example, of all the maintainers who, for example, got affected by the event-stream problem and had to immediately take action of replacing the dependency.
This feature would give the maintainer a reasonable time to make the change, without having anyone's security at risk.
mcollina commentedon Dec 13, 2018
This would be useful, but it's mainly a node core feature. As such, it is out of scope.
Most of the discussion is happening in nodejs/node#22112 and nodejs/security-wg#457.
I'm closing this issue to reduce noise, but please join the discussion on the two links I posted above.