Hacker News Reader

A resource access model for dependencies doesn't make much sense to me, there's basically only 2 things you want to gate access for libraries: filesystem and network. And it's all-in. A library that needs network access may be legit today and after an update start exfiltrating data to a different url. It seems easier to grep for fs and network calls in the library code than any of that.

View on HN

Restricting a process to only be able to access opt-in list of directories underneath the project directory would be useful. Assuming one uses a venv, and all the dependencies are contained there. Then one might want some data folder. And have at least prevented dels from scraping user-wide secrets.

You're describing a chroot jail. key there is "process". Dealing with processes permissions is the OS's job.

A if a language wants to deal in library's security it should strive to make static analysis possible. Eg: the language guarantees that network and filesystem calls can only be done with a single function, statically so I can audit that leftpad indeed doesn't make network calls .

Reply on news.ycombinator.com