121–130 of 308 posts
Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…
Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/
There are so many vectors for this attack to piggyback off from. If I had malicious intentions, I would probably typo squat popular plugins/lsps that will execute code automatically when their editor runs. A compromised neovim or vscode gives you plenty of user permissions, a full scripting language, ability to do http calls, system calls, etc. Most LSPs are installed globally, doesn't matter if you downloaded it via…
Running `npm` inside Docker does not solve this problem. However, running `npm` inside Docker does not make this problem worse either.
That's why I said running `npm` inside Docker reduces the attack surface of the malicious NPM packages.
Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…
It's no different anywhere else. I just downloaded jj (rust), it installed 470+ packages When I downloaded wan2gp (python) it installed it install 211 packages.
NPM is a terrible ecosystem, and trying to defend its current state is a lost cause. The energy should be focused on how to fix that ecosystem instead of playing dumb telling people "it's all ok, look at other, also poorly designed, systems".
Don't forget that Rust's Cargo got heavily inspired by NPM, which is not something to brag about.[0]
> "Rust has absolutely stunning dependency management," one engineer enthused, noting that Rust's strategy took inspiration from npm's.
[0]https://rust-lang.org/static/pdfs/Rust-npm-Whitepaper.pdf
Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/
I use sandbox-run: https://github.com/sandbox-utils/sandbox-run
The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...
Earlier quoted context omitted.
Don't do development on your local machine. Full stop. Just don't. Do development, all of it, inside VMs or containers, either local or remote. Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling. This has the added benefit of…
That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.
Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/
> alias npm=... I use sandbox-run: https://github.com/sandbox-utils/sandbox-run The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...
Thanks. You are right, running inside Docker won't always work for local commands. But I am not even using local commands.
Infact, I have removed `yarn`, `npm`, and several similar tools already from my machine.
It is best to run them inside Docker.
> I use sandbox-run: https://github.com/sandbox-utils/sandbox-run
How does this work if my local command is a Mac OS binary? How will it run inside Docker container?
Earlier quoted context omitted.
That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.
> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run. Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier? - Switch all projects to `pnpm`? That means switching CI, and deployment processes as well - Change the way *you* run `npm` on your machine and let your colleagues know to do the same I find the second…
Earlier quoted context omitted.
rpm and dpkg both provide mechanisms to run scripts on user machines (usually used to configure users and groups on the user machine), so this aspect is not an NPM-specific. Rust has the same thing with build.rs (which is necessary to find shared C libraries for crates that link with them) so there is a legitimate need for this that would be hard to eliminate. Personally, I think the issue is that it is too easy to c…
rpm and dpkg generally install packages from established repos that vet maintainers. It's not much but having to get one or two other established package authors to vouch for you and having to have some community involvement before you can publish to distro repos is something.
Earlier quoted context omitted.
No. I am literally describing bog standard use of an ordinary VCS/SCM where the code for e.g. Skia, sqlite, libpng, etc. is placed in a "third-party/" subdirectory. Except I'm deliberately using the words "admit" and "depository" here instead of "commit" and "repository" in keeping with the theme—of the widespread failure of people to use SCMs to manage the corresponding source code required to build their product/pr…
Yeah, people invented the concept of packages and package management because they couldn’t conceive of vendoring (which is weird considering basically all package managers make use of it themselves) and surely not because package management has actual benefits. Maybe in a perfect world, we’d all use a better VCS whose equivalent of submodules actually could do that job. We are not in that world yet.
Earlier quoted context omitted.
Does the lockfile not solve this?
not really, because you can't easily see what changed when you get a new version. When you check in the third_party repo to your VSC, then when you get a new version, everything that changed is easily visible `git diff` before you commit the new changes. With a lockfile, the only diff is the hash changed.
Go-style vendoring does dump everything into a directory but that has other downsides. I also question how effectively you can audit dependencies this way -- C developers don't have to do this unless there's a problem they're debugging, and at least for C it is maybe a tractible problem to audit your entire dependency graph for every release (of which there are relatively few).
Unfortunately IMHO the core issue is that making the packaging and shipping of libraries easy necessarily leads to an explosion of libraries with no mechanism to review them -- you cannot solve the latter without sacrificing the former. There were some attempts to crowd-source auditing as plugins for these package managers but none of them bore fruit AFAIK (there is cargo-audit but that only solves one part of the puzzle -- there really needs to be a way to mark packages as "probably trustworthy" and "really untrustworthy" based on ratings in a hard-to-gamify way).