Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Not just network permissions, opting into what local directories it can see. Allow it to see absolutely nothing but its own directory and temp. I don't have a good answer on a good method to override this when necessary. Ideally never, but realistically some form of whitelist.

npm-audit is good for post-disaster cleanup, but it's too late to prevent anything.

View on HN

> Not just network permissions, opting into what local directories it can see.

Well, one way I personally do this for my own stuff is with Docker. The problem is that I don't think it's reasonable to expect every developer to run in Docker - at least until it's at least as easy as the atlernative.

Maybe I just haven't taken the time to learn Docker well enough but the blocker that stopped me from doing this last time is how much my dev environment (VSCode and other tools) depend on my node package and its dependencies being accessed from a certain spot for import autocomplete, intellisense, etc.

When I develop locally using Docker, I live link my code directory into the container. I.E.

docker run -v "$PWD":/some/app/location ...

My editor doesn't know I'm using Docker. You can change your workflow when you want to deploy to a container registry, etc.

Aha!! So all code is executed in the container but all the code is stored locally so all my local tools see it normally. Yes on the surface that seems like the approach I need.

Consider vagrant.

This was the blocker for me to use it on my local machine as well. How can we fix this? Is there a way to do it without updating every tool to explicitly special-case docker?

Dev machines are one thing, but there is no reason our CI tools should ever expose credentials in a way that is accessible to any build or test step. Build and test steps should be sandboxed to take input and produce an artifact, which is then uploaded to wherever in a completely separate sandbox.

Reply on news.ycombinator.com