I think there'd be a lot of reliance on all these fundamental components working correctly (and prohibiting other components i.e. "We're using this curl library at a basic level and exposing a safe interface through this protected library but somehow blocking calls from code outside the library") which might have serious repercussions for code reuse.
There are ways you can instruct an OS to block calls to certain library functions/memory ranges (i.e. remove and grant elevations privileges) but I think such a system would need to be designed from the ground up. If you can still `require(lib/reallyOldCurl)` then your protections might allow linters to be able to mark packages as unsafe, but I think it'd be extremely difficult to block access without an extremely fundamental design intent.
I appreciate your reply quite a bit though as I was envisioning the restrictions being defined on a universal package level (aka lpad is given no disk access) rather than being delegated to the consuming developer.
There are ways you can instruct an OS to block calls to certain library functions/memory ranges (i.e. remove and grant elevations privileges) but I think such a system would need to be designed from the ground up. If you can still `require(lib/reallyOldCurl)` then your protections might allow linters to be able to mark packages as unsafe, but I think it'd be extremely difficult to block access without an extremely fundamental design intent.
I appreciate your reply quite a bit though as I was envisioning the restrictions being defined on a universal package level (aka lpad is given no disk access) rather than being delegated to the consuming developer.