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

241–250 of 460 posts

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

#241

Post by eyberg »

evertheylen wrote: post #210
eyberg wrote: post #191

Earlier quoted context omitted.

Containers should not be used as a security mechanism.

I agree with you that VMs would provide better isolation. But I do think containers (or other kernel techniques like SELinux) can still provide quite decent isolation with a very limited performance/ease-of-use cost. Much better than nothing I'd say?

I would kinda disagree with this. The whole 'better than nothing' is what gave a huge chunk of people a false sense of security wrt containers to begin with. The reality is that there is no singular create_container(2). Much of the 'security' is left up to the runtime of choice and the various flags they choose or don't choose to enable. Others in this thread have already mentioned both bubblewrap and podman. The fact that the underlying functionality is exposed very differently through different 'runtimes' with numerous optional flags and such is what leads to all sorts of issues because there simply was no thought to designing these things with security in mind. (We just saw CVE-2025-9074 last week). This is very different than something like the v8 sandbox or gvisor which was designed with certain properties.

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

#242

Post by lxgr »

kbrkbr wrote: post #209
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…

But here's the catch. If you do that in a lot of places, you'll have a lot of extra code to manage. So your suggested approach does not seem to scale well.

There's obviously a tradeoff there.

At some level of complexity it probably makes sense to import (and pin to a specific version by hash) a dependency, but at least in the JavaScript ecosystem, that level seems to be "one expression of three tokens" (https://www.npmjs.com/package/is-even).

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

#243

Post by sheerun »

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…

Secondary reminder that it means nothing as soon as you run any of scripts or binaries

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

#244

Post by christophilus »

evertheylen wrote: post #147
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 do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox? [1]: https://evertheylen.eu/p/probox-intro/

Very interesting. I learned some new things. I didn't know about `--userns` or the flexible "bind everything" network approach!

Here's my script:

https://codeberg.org/chrisdavies/dotfiles/src/branch/main/sr...

What I do is look for a `.podman` folder, and if it exists, I use the `env` file there to explicitly bind certain ports. That does mean I have to rebuild the container if I need to add a port, so I usually bind 2 ports, and that's generally good enough for my needs.

I don't do any ssh in the container at all. I do that from the host.

The nice thing about the `.podman` folder thing is that I can be anywhere in a subfolder, type `gg pod`, and it drops me into my container (at whatever path I last accessed within the container).

No idea how secure my setup is, but I figure it's probably better than just running things unfettered on my dev box.

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

#246

Post by christophilus »

hvb2 wrote: post #99
christophilus wrote: post #61

Earlier quoted context omitted.

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

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.

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

#247

Post by christophilus »

willsmith72 wrote: post #148
christophilus wrote: post #61

Earlier quoted context omitted.

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

sounds like the best way to miss critical security upgrades

Why? If you had a package manager tell you "this is out of date and has vulnerability XYZ", you'd do a "gitpkg update" or whatever, and get the new code, review it, and if it passes review, deploy it.

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

#248

Post by marcosdumay »

skydhash wrote: post #240
imiric wrote: post #228

Earlier quoted context omitted.

That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to inf…

> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software. If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is ab…

It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries.

What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching that flies under the radar of the upstream developers.

Instead, the GPs proposal of vendoring the dependencies solves that problem, without breaking the compilation, and adds another set of issues that may or may not be a problem. I do argue that it's a good option to keep on one's mind to apply when necessary.

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

#249

Post by christophilus »

hardwaregeek wrote: post #183
christophilus wrote: post #61

Earlier quoted context omitted.

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

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.

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

#250

Post by Eji1700 »

christophilus wrote: post #246
hvb2 wrote: post #99

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

> 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 expect my frontend guy to need to know encryption so he can review the form library he's using.

Post reply on HN