The last 3 points before the conclusion should be top 3, in fact they should just have their own section "How we stop node packages being a footgun". Security is not the "last concern."
Given the state of node package security of recent times even the crappiest in terms of features, fancyness and speed alternative to npm is much preferred if it actually solves some (if not all) high profile security concerns so everyone can sleep at night.
It's certainly a good step forward in other areas but I have to wonder what yarn does about "random dependency randomly building garbage" or why yarn doesn't just address all code that accesses "fs" and anything else into using a "safe" version (ie. error when reading anything outside, sending network packages, etc, unless explicitly granted). The "2" at the end feels more chilling then hype when major security concerns are not either addressed or their solutions clearly explained. If you do happen to do this, you've made a poor explanation of it.
why yarn doesn't just address all code that accesses "fs" and anything else into using a "safe" version (ie. error when reading anything outside, sending network packages, etc, unless explicitly granted)
We want to do that, but it's impossible (or at the very least a completely different project) unless Node first implements proper builtin sandboxes. Even if we were preventing accesses to require('fs'), there is a bazillion ways to escape any "security" measure we could have.
Personally I would be more then happy with a "secure mode" that simply breaks any sort of "fancy" code people might have and requires explicit "whitelist" approval in package.json and very clear looking code for any sensitive such as imports, fs access, network access or global object access, etc.
Simple Checklist:
Does package access global object in any way? Blocked, no other checks necessary.
Does a import or require use anything that doesn't look like a regular dumb string? Blocked.
Every low-level network / filesystem / process-spawn package is replaced with an alias version that has some basic whitelist controls on it's sensitive methods.
There's no need to be flexible when implementing something like this. People need to adapt to the secure system until we have a better "flexible" secure system not the other way around. I would drop even high profile packages if it meant peace of mind.
I don't see any sort of node "sandboxing" making any difference in this regard and if the work in Dino is anything to go by, node level sandboxing is pretty stupid in practice with out user space assumtions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The last 3 points before the conclusion should be top 3, in fact they should just have their own section "How we stop node packages being a footgun". Security is not the "last concern."
Given the state of node package security of recent times even the crappiest in terms of features, fancyness and speed alternative to npm is much preferred if it actually solves some (if not all) high profile security concerns so everyone can sleep at night.
It's certainly a good step forward in other areas but I have to wonder what yarn does about "random dependency randomly building garbage" or why yarn doesn't just address all code that accesses "fs" and anything else into using a "safe" version (ie. error when reading anything outside, sending network packages, etc, unless explicitly granted). The "2" at the end feels more chilling then hype when major security concerns are not either addressed or their solutions clearly explained. If you do happen to do this, you've made a poor explanation of it.
We want to do that, but it's impossible (or at the very least a completely different project) unless Node first implements proper builtin sandboxes. Even if we were preventing accesses to
require('fs'), there is a bazillion ways to escape any "security" measure we could have.Personally I would be more then happy with a "secure mode" that simply breaks any sort of "fancy" code people might have and requires explicit "whitelist" approval in package.json and very clear looking code for any sensitive such as imports, fs access, network access or global object access, etc.
Simple Checklist:
There's no need to be flexible when implementing something like this. People need to adapt to the secure system until we have a better "flexible" secure system not the other way around. I would drop even high profile packages if it meant peace of mind.
I don't see any sort of node "sandboxing" making any difference in this regard and if the work in Dino is anything to go by, node level sandboxing is pretty stupid in practice with out user space assumtions.