ashishb

5 ms·

61.
by ashishb 6mo ago
I only said it is a defense-in-depth measure. I definitely want to know how is it worse than running npm directly on the host
62.
by ashishb 6mo ago
So the worst case is that you are back to running npm on your host. Right?
63.
by ashishb 6mo ago
Compared to what? Which one is superior? Running npm on your dev machine? Or running npm inside Docker? I would always prefer the latter but would love to know what your approach to security is that's better than running npm inside Do
64.
by ashishb 6mo ago
What makes you think that? Your cab see the commit history ~10% of code is written by agents. Rest was all written by me. Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.
65.
by ashishb 6mo ago
I do. It wasn't obvious that that's what you were referring to. If you use it regularly then that's great.
66.
by ashishb 6mo ago
I wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages. https://github.com/ashishb/amazing-sandbox
67.
by ashishb 6mo ago
Run npm/pnpm/bun/uv inside a sandbox. There is no reason to let random packages have full access to your machine
68.
by ashishb 6mo ago
> Why? Just open your entire editor/whatever inside a limited namespace and that's it no? How will that prevent `npm run dev` or `uv run python` from accessing files outside your current directory?
69.
by ashishb 6mo ago
> That is very inconvenient. All executions (especially of random third-party code) inside the containers are not inconvenient at all for me. Infact, I even open-sourced my setup - https://github.com/ashishb/amazing-
70.
by ashishb 6mo ago
Rather than being hopeful why not start running 'uv' inside sandbox? Why does your python package (cli/Web server/library) need full access to your full disk at the time of execution?
71.
by ashishb 7mo ago
> docker run super-evil-oci-container 1. That super evil OCI container still needs to find a vulnerability in Docker 2. You can run Docker in rootless mode e.g. Orbstack runs without root
72.
by ashishb 7mo ago
> Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root. Inside the sandbox but not on my machine. Show me how it can access an unmounted directory. > Have you solved for publishin
73.
by ashishb 7mo ago
> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain. Not really. I try to capture the most common ones for caching [1], but if I mi
74.
by ashishb 7mo ago
I wrote this[1] for myself last year. It only gives access to the current directory (and a few others - see README). So, it drastically reduces the attack surface of running third-party Python/Go/Rust/Haskell/JS code on
75.
by ashishb 7mo ago
> This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Not really. You should lim
76.
by ashishb 7mo ago
> We need to start working in full sandboxes with defence in depth that have real guardrails Happily sandboxing almost all third-party tools since 2025. `npm run dev` does not need access to my full disk.
77.
by ashishb 7mo ago
> It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive. Not really. Let's say I am running `~/src/project1 $ litellm` Why do
78.
by ashishb 7mo ago
I am happily running all third-party tools inside the Amazing Sandbox[1]. I made it public last year. 1 - https://github.com/ashishb/amazing-sandbox
79.
by ashishb 7mo ago
> I don't think it would help here, they were stealing credentials So, stealing credentials in the current directory and in all other directories are the same thing?
80.
by ashishb 7mo ago
> The sandbox will need internet access (to update data) and you will need to send code to test into it; so compromise already equals leaking all your code, without even breaking the sandboxing Compromising all code in one directory is b
81.
by ashishb 7mo ago
I always run such tools inside sandboxes to limit the blast radius.
82.
by ashishb 7mo ago
> Have mypy/pyright/pryefly/ty type errors break CI. Only if types are present. > If you're starting a new project, there's no reason you shouldn't. Most dependencies would still be untyped.
83.
by ashishb 7mo ago
And you can never mandate that optional type checking in a big enough team. You can even see popular FOSS Python packages that have very limited type checking.
84.
by ashishb 7mo ago
I built something similar for myself that works on both Linux and Mac OS https://github.com/ashishb/amazing-sandbox
85.
by ashishb 7mo ago
How do it work inside `myFunction1` which is invoked by `myFunction`? Does `myFunction1` needs to be async as well?
86.
by ashishb 7mo ago
Context cancellation (and it's propagation) is one of the best features in Go. Is there any equivalent in major popular languages like Python, Java, or JS of this?
87.
by ashishb 7mo ago
Reminder to always run all npm commands inside a sandbox. I wrote amazing-sandbox[1] for myself after seeing how prolific these attack vectors have become in recent years. 1 - https://github.com/ashishb/amazing-sandbox
88.
by ashishb 8mo ago
One really common that myth this article busts is about child care. "Child care is virtually free in Vienna and extremely expensive in Zurich, but the Austrians and the Swiss have the same fertility rate."
89.
by ashishb 8mo ago
New Yorker has a detailed article on this phenomenon that's a great read. It busts many common myths. https://www.newyorker.com/magazine/2025/03/03/the-population...
90.
by ashishb 8mo ago
That's why I wrote my own sandbox. Everyone hand waives these concerns. Further, I don't know why docker is weak security on Linux. Are you telling me that one can exploit docker?

More ›