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

281–290 of 460 posts

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

#281

Post by shermantanktop »

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…

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

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

#282

Post by theteapot »

pdw wrote: post #157
exDM69 wrote: post #91

Earlier quoted context omitted.

The same applies to any Makefile, the Python script invoked by CMake or pretty much any other scriptable build system. They are all untrusted scripts you download from the internet and run on your computer. Rust build.rs is not really special in that regard. Maybe go build doesn't allow this but most other language ecosystems share the same weakness.

Right, people forget that the xz-utils backdoor happened to a very traditional no-dependencies C project.

xz-utils has a ton of build dependencies. The backdoor implant exploited a flaw in an m4 macro build dep.

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

#283

Post by andix »

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.

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

#284

Post by jerf »

christophilus wrote: post #249
hardwaregeek wrote: post #183

Earlier quoted context omitted.

That’s called the original Go package manager and it was pretty terrible

I think it was only terrible because the tooling wasn't great. I think it wouldn't be too terribly hard to build a good tool around this approach, though I admittedly have only thought about it for a few minutes. I may try to put together a proof of concept, actually.

If you're working in Go, you don't need to put together a proof of concept. Very basic project tooling in conjunction with "go mod vendor", which takes care of copying in the dependencies in locally, will do what you're talking about. Go may not default to this operation, but using it this way is fairly easy.

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

#285

Post by skydhash »

Eji1700 wrote: post #250
christophilus wrote: post #246

Earlier quoted context omitted.

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.

> Why is that unrealistic? Because the vast majority of development is done by people with a very narrow focus of skills on an extreme deadline, and you actually comfortable with compression, networking, encryption, IO, and all the other taken for granted libraries that wind up daisy chained together? Because if you are, great, but at the same time, that's not the job description for like 90% of coding jobs. I don't…

Why would a form library have encryption? That's a red flag for me.

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

#286

Post by skydhash »

f311a wrote: post #206
dakiol wrote: post #112

Earlier quoted context omitted.

Easier solution: you don’t need a progress bar.

It runs indefinitely to process small jobs. I could log stats somewhere, but it complicates things. Right now, it's just a single binary that automatically gets restarted in case of a problem.

Why not print on stdout, then redirect it to a file?

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

#287

Post by imiric »

skydhash wrote: post #271
imiric wrote: post #258

Earlier quoted context omitted.

Right. Build and runtime dependencies are a separate matter. But for runtime dependencies, it's easier for developers to supply an OCI image, AppImage, or equivalent, with the exact versions of all dependencies baked in, than to support every possible package manager on every distro, and all possible dependency and environment permutations. This is also much easier for the user, since they only need to download and r…

> it's easier for developers to supply an OCI image, AppImage, or equivalent, with the exact versions of all dependencies baked in, than to support every possible package manager on every distro, No developer is being asked to support every distro. You just need to provide the code and the requirement list. But some developer made the latter overly restrictive. And tailor the project to support only one release proce…

> No developer is being asked to support every distro.

You mentioned $current_debian above. Why Debian, and not Arch, Fedora, or NixOS? Supporting individual Linux distros is a deep rabbit hole, and smaller teams simply don't have the resources to do that.

> You just need to provide the code and the requirement list.

That's not true. Even offering a requirements list and installation instructions for a distro implies support for that distro. If something doesn't work properly, the developer can expect a flood of support requests.

> `apt install` is way easier than the alternative and more secure.

That's debatable. An OCI image, AppImage, or even Snap or Flatpak package is inherently more secure than a system package, and arguably easier to deploy and upgrade.

> There's no burden because no one does it.

Not true. Search Debian packages and you'll find thousands of language-specific libraries. Many other distros do the same thing. NixOS is probably the most egregious example, since it literally tries to take over every other package manager.

> You have dev version for libraries because you need them to build the software that is being packaged.

Eh, are the dev versions useful for end users or distro maintainers? If distro maintainers need to build the software that's being packaged, they can use whatever package manager is appropriate for the language stack. An end user shouldn't need to build the packages themselves, unless it's a build-from-source distro, which most aren't.

My point is that there's no reason for these dependency trees to also be tracked by distro package managers. Every modern language has their own way of managing dependencies, and distros should stay out of it. The only responsibility distro package managers should have is managing runtime dependencies for binary packages.

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

#288

Post by woollysammoth »

0cf8612b2e1e wrote: post #264
fwip wrote: post #255

Earlier quoted context omitted.

Pet peeve - it's free rein, not free reign. It's a horse riding metaphor.

Bah, well I have been using that incorrectly my entire life. A monarchy/ruler metaphor seems just as logical.

There's a term "eggcorns" for these logical misinterpretations - https://en.wikipedia.org/wiki/Eggcorn

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

#289

Post by andix »

> "These versions have since been removed from NPM as of 10:44 PM EDT"

If you're ever writing a post like that, please use UTC, standard time formats (RFC, 24h format) and add the date.

"10:44 PM EDT" is something I need to look up to understand what it means (EDT is not a well knows abbreviation outside of North America). Also all my timestamps in GitHub (when the post was created, updated) show up in my local time (which I can easily map to UTC in my head, but not to EDT).

EDT is -0400, so it's 18:44:00Z. Edit: totally messed up the calculation, it's actually 02:44:00Z on the next day. Just proving my point.

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

#290

Post by mirekrusin »

norskeld wrote: post #200
chrisweekly wrote: post #160

Earlier quoted context omitted.

pnpm is not only more secure, it's also faster, more efficient wrt disk usage, and more deterministic by design.

It also has catalogs feature for defining versions or version ranges as reusable constants that you can reference in workspace packages. It was almost the only reason (besides speed) I switched a year ago from npm and never looked back.

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