Any practical tips for hardened security when programming? Don't want to be exposed to npm/pip/cargo installing password/browser cookie stealers. What worries me is the little to no isolation between the dev environment and the rest of the OS for day to day use.
Malicious versions of Nx and some supporting plugins were published
371–380 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#372There is a lot of discussion in the comments about using VMs for dev work. I too try to at least use containers whenever I can but it's sometimes not very practical. Better than nothing.
99% of the threat model is software trying to extract data. Either for myself (e.g. blackmail) or to learn about me and attack others (impersonation for scams, fraud, blackmail against others) or to access systems I have access to (tokens, API keys, online banking)
Currently I am playing around with local LLMs on a Mac. The whole field is moving so fast that it is impossible not to rely on recent releases to quickly try new features. Unfortunately there is no way to access the Mac GPU in VMs.
So right now to have at least a tiny bit of separation I have the local LLM tools set up on a separate local Mac user that I can then ssh into and use to expose a web server usable from my main (dev) account.
This of course is far from perfect but at least a little better than before. I fully expect supply chain attacks on AI tooling and perhaps even malicious LLM models to happen at some point. That target is too juicy.
Setting this up I was a bit irritated by some of the defaults of macos for multi user setups.
- All mac software is usually installed to the global /Applications folder. Homebrew needs a workaround to work across multiple users
- By default all files of a local mac user can be read by all other non admin local mac users. Only Apple-created folders like Documents, Desktop etc. are locked down
If you want to store files outside of those Apple-created folders, perhaps because you sync Documents with icloud and want to store project repos and larger files, perhaps because you have ssh and github configs, dotfiles etc. in your home dir, then they are all by default readable by other non admin users.
This is not to say that this is a huge issue that can't be fixed (just need to remove default permissions for group 'staff' yourself) but it is interesting that this is the default.
The concept of multiple local users seems to be completely ignored by users and by Apple, and has been mostly unchanged for decades. There are tiny improvements such as Apples permissions dialog when an application accesses Desktop, Documents or Downloads for the first time. But this seems pretty useless all things considered.
Why is it not more common to have stronger local separation? I don't need and don't want total iOS-level sandboxing (and lack of file system) but why isn't there a little more progress on the computer side of things?
I agree that VM-level isolation with good usability and little performance loss would be a great thing. But this is aiming for perfection in a world pressured by more and more supply chain attacks as well as more automated (read: AI controlled) computer use.
As an 80% "OS-native" solution it would be great if I could easily use local users for different project files _and_ stream GUIs across users (to work seamlessly from one main account). Then we could probably avoid the majority of security risks in every day computer use for developers and other "computer workers" alike.
--
I skipped over that last part but this is the real blocker. It should be possible by now to easily stream a "remote" (local, different user) application UI into my current users window management with full support for my many screens, resolutions, copy/paste and shortcuts. All while having zero quality loss or performance overhead if done locally.
I don't want remote desktop, I want remote application UI. This is not a new idea (X11 forwarding)
Here's a fun thought:
AI workflows and agents have surprised us all. We see them clicking and typing and changing files on our machines. If the OS-makers don't come up with appropriate mechanisms then we will somehow end up recreating a new form of OS. It is already starting with AI-focussed browsers or ChatGPT as an entry point to delegate "browse the web for me". It will be web based with compute happening on VMs in the background, probably billed like a SaaS and disappoint all of us wanting to preserve the ideal of personal computers. Eventually it will make desktop OS's irrelevant and we all end up working with a form of chromebook
Re: Malicious versions of Nx and some supporting plugins were published
#373Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
Why the same advice doesn't apply to `setup.py` or `build.rs`? Is it because npm is (ab)used for software distribution (eg. see sibling comment: https://news.ycombinator.com/item?id=45041292 ) instead of being used only for managing library-dependencies?
It should, and also to Makefile.PL, etc. These systems were created at a time when you were dealing with a handful of dependencies, and software development was a friendlier place.
Now you're dealing with hundreds of recursive dependencies, all of which you should assume may become hostile at any time. If you neither audit your dependencies, nor have the ability to sue them for damages, you're in a precarious position.
Re: Malicious versions of Nx and some supporting plugins were published
#374Earlier quoted context omitted.
Is that realistic though? What you're proposing is letting go of abstractions completely. Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself? That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.
Yes. I would review any changes to any 3rd party libraries. Why is that unrealistic? Regarding the language itself, I may or may not. Generally, I pick languages that I trust. E.g. I don't trust Google, but I don't think the Go team would intentionally place malware in the core tools. Libraries, however, often are written by random strangers on the internet with a different level of trust.
Good for you, but sadly, most people are not like you. Or don't have the opportunity to be like you.
Re: Malicious versions of Nx and some supporting plugins were published
#375Re: Malicious versions of Nx and some supporting plugins were published
#376Earlier quoted context omitted.
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…
> This is a bad direction, and we need to turn back now. I don't deny there are some problems with package managers, but I also don't want to go back to a world where it is a huge pain to add any dependency, which leads to projects wasting effort on implementing things themselves, often in a buggy and/or inefficient way, and/or using huge libraries that try to do everything, but do nothing well.
It's a tradeoff. When package users had to manually install dependencies, package developers had to reckon with that friction. Now we're living in a world where developers don't care about another 10^X dependencies, because the package manager will just run the scripts and install the files, and the users will accept it.
Re: Malicious versions of Nx and some supporting plugins were published
#377Earlier quoted context omitted.
I think you're misunderstanding. "go build" of arbitrary attacker controlled go code will not lead to arbitrary code execution. If you do "git clone attacker-repo && cargo build", that executes "build.rs" which can exec any command. If you do "git clone attacker-repo && go build", that will not execute any attacker controlled commands, and if it does it'll get a CVE. You can see this by the following CVEs: https://pk…
But `go generate` can, and that is required to build some go projects. It is also somewhat common for some complicated projects to require running a Makefile or similar in order to build, because of dependencies on things other than go code.
The culture around "go generate" is that you check in any files it generates that are needed to build.
In fact, for go libraries you effectively have to otherwise `go get` wouldn't work correctly (since there's no way to easily run `go generate` for a third-party library now that we're using go modules, not gopath).
Have you actually seen this in the wild for any library you might `go get`? Can you link any examples?
Re: Malicious versions of Nx and some supporting plugins were published
#378People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…
I'm actually really frustrated how hard it's become to manually add, review and understand dependencies to my code. Libraries used to come with decent documentation, now it's just a couple lines of "npm install blah", as if that tells me anything.
Re: Malicious versions of Nx and some supporting plugins were published
#379Earlier quoted context omitted.
It doesn't have to be a deliberate 'attack', Claude can just do something absurdly inappropriate that wasn't what you intended. You're absolutely right! I should not have `rm -rf /bin`d!
I would say this is a feature, not a bug. Terminal and Bash or any shell can do this, if the user sucks. I want Claude Code to be able to do anything and everything, that's why it's so powerful. Sure, I can also make it do bad stuff, but that's like any tool. We don't ban knives because sometimes they kill people, because they're useful.
I would say it's neither, it's complacent misuse by the user. As you allude to we generally already are, but non-deterministic & especially 'agentic' AI makes the stakes/likelihood of it going wrong so much higher.
Don't use an MCP server with permission (capability) to do more than you want, regardless of whether you think you're instructing the AI tool do the bad thing it's technically capable of.
Don't run AI tools with filesystem access outside of something like a container with only a specific whitelist of directory mounts.
Assume that the worst that could happen with the capability given will happen.
Re: Malicious versions of Nx and some supporting plugins were published
#380Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
Looks like pnpm 10 does not run lifecycle scripts of dependencies unless they are listed in ‘onlyBuiltDependencies’.