Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

Post reply on HN
Print view View original

341–350 of 460 posts

Re: Malicious versions of Nx and some supporting plugins were published

#341

Post by TheTaytay »

homebrewer wrote: post #211
inbx0 wrote: post #125

Periodic 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…

I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…

Very cool. Hadn't heard of this before. I appreciate you posting it.

Re: Malicious versions of Nx and some supporting plugins were published

#342

Post by emmanueloga_ »

emmanueloga_ wrote: post #298

I wonder if anyone use https://verdaccio.org/ to vendor packages? In theory for each package one could: * npm install pkg * npm pack pkg * npm publish --registry= https://verdaccio.company.com * set .npmrc to "registry= https://verdaccio.company.com/ when working with the actual app. ...this way, one could vet packages one by one. The main caveat I see is that it’s very inconvenient to have to vet and publish each pa…

I just found that someone posted a showHN for an utility to solve this issue [1].

I think this reinforces the idea that is something that could be built into verdaccio.

--

1: https://news.ycombinator.com/item?id=44891786

Re: Malicious versions of Nx and some supporting plugins were published

#343

Post by conception »

homebrewer wrote: post #317
shermantanktop wrote: post #281

Earlier quoted context omitted.

This is trading one distribution problem (npx) for another (bubblewrap). I think it’s a reasonable trade, but there’s no free lunch.

Not sure what this means. bubblewrap is as free as it gets, it's just a thin wrapper around the same kernel mechanisms used for containers, except that it uses your existing filesystems instead of creating a separate "chroot" from an OCI image (or something like it). The only thing it does is hiding most of your system from the stuff that runs under it, whitelisting specific paths, and optionally making them readonly…

It means that someone just has to compromise bubblewrap instead of the other vectors.

Re: Malicious versions of Nx and some supporting plugins were published

#345

Post by marshray »

magackame wrote: post #221
cedws wrote: post #185

Earlier quoted context omitted.

Cargo.toml does not contain the source code of dependencies nor transient dependencies.

Welp, `cargo tree`, 100 nights and 100 coffees then it is

Yes!

I sometimes set up a script that runs several variations on 'cargo tree', as well as collects various stats on output binary sizes, lines of code, licenses, etc.

The output is written to a .txt file that gets checked-in. This allows me to easily observe the 'weight' of adding any new feature or dependency, and to keep an eye on the creep over time as the project evolves.

Re: Malicious versions of Nx and some supporting plugins were published

#346

Post by rom1v »

coldpie wrote: post #54
f311a wrote: post #11

People 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 feel that Rust increases security by avoiding a whole class of bugs (thanks to memory safety), but decreases security by making supply chain attacks easier (due to the large number of transitive dependencies required even for simple projects).

Re: Malicious versions of Nx and some supporting plugins were published

#347

Post by christophilus »

0cf8612b2e1e wrote: post #262
christophilus wrote: post #63

Earlier quoted context omitted.

Similar, but in a podman container which shares nothing other than the source code directory with my host machine.

I would love if some experts could comment on the security profile of this. It sounds like it should be fine, but there are so many gotchas with everything that I use full VMs for development. One immediate stumbling block- the IDE would be running in my host, which has access to everything. A malicious IDE plugin is a too real potential vector.

I run the ide (neovim) in the container along with npm, cargo, my dev / test databases, etc. It’s a complete environment (for me).

Re: Malicious versions of Nx and some supporting plugins were published

#348

Post by thayne »

coldpie wrote: post #54
f311a wrote: post #11

People 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…

> 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.

Re: Malicious versions of Nx and some supporting plugins were published

#349

Post by marshray »

smj-edison wrote: post #319
Hilift wrote: post #146

Earlier quoted context omitted.

50% of impacted users the vector was VS Code and only ran on Linux and macOS. https://www.wiz.io/blog/s1ngularity-supply-chain-attack "contained a post-installation malware script designed to harvest sensitive developer assets, including cryptocurrency wallets, GitHub and npm tokens, SSH keys, and more. The malware leveraged AI command-line tools (including Claude, Gemini, and Q) to aid in their reconnaissance effort…

I'm a little confused about the sudo part, do most people not have sudo behind a password? I thought ~/.bashrc ran with user permissions...

My personal belief is that users should not be required type their password into random applications, terminals, and pop-up windows. Of course, login screens can be faked too.

So my main user account does not have sudo permissions at all, I have a separate account for that.

Re: Malicious versions of Nx and some supporting plugins were published

#350

Post by cozzyd »

conception wrote: post #343
homebrewer wrote: post #317

Earlier quoted context omitted.

Not sure what this means. bubblewrap is as free as it gets, it's just a thin wrapper around the same kernel mechanisms used for containers, except that it uses your existing filesystems instead of creating a separate "chroot" from an OCI image (or something like it). The only thing it does is hiding most of your system from the stuff that runs under it, whitelisting specific paths, and optionally making them readonly…

It means that someone just has to compromise bubblewrap instead of the other vectors.

sure but surely one gets bubblewrap from their distro, and you have to trust your distro anyway.
Post reply on HN