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

421–430 of 460 posts

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

#421

Post by johnisgood »

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.

This is such a defeatist perspective. You could say this about anything ad nauseum. I think bubblewrap (or firejail) is less likely to be a successful target.

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

#422

Post by johnisgood »

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

You will need something stronger than caffeine.

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

#423

Post by johnisgood »

cozzyd wrote: post #385
duped wrote: post #208

Earlier quoted context omitted.

Do you review the 10k+ lines of generated bash in ./configure, too?

./configure shouldn't be in your repo unless it's handwritten

Pretty much. It is called "autotools" for a reason.

Theoretically you should be able to generate the configuration scripts through "autoconf" (or autoreconf), or generate Makefile.in for configure from Makefile.am using "automake", etc.

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

#424

Post by amelius »

f311a wrote: post #207
amelius wrote: post #110

Earlier quoted context omitted.

And do you know what type of code the LLM was trained on? How do you know its sources were not compromised?

Why do I need to know that if I'm an experienced developer and I know exactly what the code is doing? The code is trivial, just print stuff to stdout along with escape sequences to update output.

In this case, yes, but where do you draw the line?

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

#425

Post by ifwinterco »

johnisgood wrote: post #418
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…

At this point why not just avoid npm (and friends) like the plague? Genuinely curious.

I work for a company that needs to ship software so my salary can get paid

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

#426

Post by ifwinterco »

eitau_1 wrote: post #213
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…

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?

For simple python libraries setup.py has been discouraged for a long time in favour of pyproject.toml for exactly this reason

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

#427

Post by Nathanba »

dvfjsdhgfv wrote: post #304
mirekrusin wrote: post #290

Earlier quoted context omitted.

workspace protocol in monorepo is also great, we're using it a lot.

OK so it seems too good now, what are the downsides?

A few years ago it didn't work in all cases when npm did. It made me stop using it because I didn't want to constantly check with two tools. The speed boost is nice but I don't need to npm install that often.

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

#428

Post by aragilar »

oulipo2 wrote: post #365
theamk wrote: post #356

Earlier quoted context omitted.

Not "instead", it's "in addition to". Your classical defense-in-depth.

No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised. But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

How? bubblewrap isn't something someone has randomly uploaded to npm, it has well known maintainers and a well organised release process (including package signing). Which is easier to do: upload a package to npm and get people to use it, or spend 2+ years trying to become a maintainer of bubblewrap or one of its dependencies to compromise it.

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

#429

Post by aragilar »

oulipo2 wrote: post #364
homebrewer wrote: post #211

Earlier quoted context omitted.

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…

Will this work on osX? and for pnpm?

No, bubblewrap uses linux namespaces. You can use for (almost) whatever software you want.

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

#430

Post by dns_snek »

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…

Whenever I read this well-meaning advice I have to ask: Do you actually read hundreds of thousands of lines of code (or more) that NPM installed?

Because the workflow for 99.99% of developers is something resembling:

1. git clone

2. npm install (which pulls in a malicious dependency but disabling post-install scripts saved you for now!)

3. npm run (executing your malicious dependency, you're now infected)

The only way this advice helps you is if you also insert "audit the entirety of node_modules" in between steps 2 and 3 which nobody does.

Post reply on HN