Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

391–400 of 460 posts

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

#391

Earlier quoted context omitted.

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

Personally, I didn't find a way to create one docker image for each of my project (in a pnpm monorepo) in an efficient way

That’s not really a pnpm problem on the face of it

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

#392
post #65

Earlier quoted context omitted.

Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.

Does it really matter, though? Presumably if you're building something is so you can run it. Who cares if the build script is itself going to execute code if the final product that you're going to execute?

With a scripting language it can matter: If I install some package I can review after the install before running or run in a container or other somewhat protected ground. Whereas anything running during install can hide all trades.

Of course this assumption breaks with native modules and with the sheer amount of code being pulled in indirectly ...

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

#394
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…

I actually loathe those progress trackers. They break emacs shell (looking at you expo and eas). Why not print a simple counter like: ..10%..20%..30% Or just: Uploading… Terminal codes should be for TUI or interactive-only usage.

I feel like not properly supporting widely used escape codes is an issue with the shell, not with the program that uses them

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

#395

Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…

One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…

flatpak is supposed to address this. Running applications in sandbox. But, with almost all applications wanting access to your HOME, because of convenience, sandbox utility is quiet questionable in most cases.

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

#396
post #346
post #54

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

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

Who is requiring you to use large numbers of transitive dependencies? You can always write all the code yourself instead.

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

#397
post #102

Earlier quoted context omitted.

Fully agree. So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option. I also find anything not extensively used has bug…

There is only one Rust application (server) I use enough that I try to keep up and rebuild it from the latest release every now and then. Most of the time new releases mostly bump versions of some of the 200 or so dependencies. I have no idea how I, or the server code's maintainers, can have any clue what exactly is brought in with each release. How many upgrades times 200 projects before there is a near 100% chance…

So why are you upgrading?

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

#398

Earlier quoted context omitted.

Yeah I use Qubes for my "serious" computing these days. It comes with performance headaches, though my laptop isn't the best. I wonder about something like https://secureblue.dev/ though. I'm not comfortable with Fedora and last I heard it wasn't out of Beta or whatever yet. But it uses containers rather than VMs. I'm not a targeted person so I may be happy to have "good enough" security for some performance back.

secureblue creator here :) some corrections: > last I heard it wasn't out of Beta or whatever yet It is > But it uses containers rather than VMs It doesn't use plain containers for app isolation. We ship the OS itself as a bootable container ( https://github.com/bootc-dev/bootc ). That doesn't mean we use or recommend using containers for application isolation. Container support is actually disabled by default via ou…

I keep hearing different things about how well containers can isolate. I guess the "on their own" caveat is the important one. I don't really know how they work.

Hearing not to rely on it from the developer of secureblue is pretty strong case. Thanks.

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

#399
post #283

Are there any package managers that have something like a min-age setting. To ignore all packages that were published less than 24 or 36 hours ago? I’ve run into similar issues before, some package update that broke everything, only to get pulled/patched a few hours later.

npm install actually has a flag to install dependencies as they appeared on a specific point in time. This flag is applied to the entire tree.

What this means is that you can run "npm instal --before (date for 2 days ago)" and it will skip any dependencies newer than that.

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

#400
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…

[dead]
Post reply on HN