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

311–320 of 460 posts

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

#311

Post by wat10000 »

chuckadams wrote: post #266
wat10000 wrote: post #224

Earlier quoted context omitted.

Time for everybody's favorite engineering answer: it depends! You have to weigh the cost/benefit tradeoff. But you have to do it in full awareness of the costs, including potential costs from packages being taken down, broken, or subverted. In any case, for an external dependency, 100 lines is way too low of a benefit. I'm not trying to be effective, I'm just lamenting. Maybe being sarcastic isn't a very effective wa…

Naw, sarcasm totally works... ;) I'd say it all depends -- there's that word again -- on what those 100 LOC are expressing. I suppose one could still copy/paste such a small amount of code, but I'd rather just check in some subset of vendored dependencies. Or maybe just pin the dependency to a commit hash (since we can't depend on version tags being immutable). Something actionable beyond peer pressure at any rate.

There are definitely 100-line chunks of code I wouldn't want to rewrite from scratch. They also tend not to be the sort of thing that needs a lot of updates, so a copy/paste job ought to do the job.

The big advantage with a dependency manager is that you don't have to find all of the dependency's dependencies, figure out the right build settings, etc. That's super helpful when it's huge, but it's not really doing anything for you when it's small.

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

#312

Post by jen20 »

hvb2 wrote: post #261
3036e4 wrote: post #180

Earlier quoted context omitted.

Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.

So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke? Like how xz was attacked, everyone pointed at that and no one said they didn't vet their dependencies. That's the whole point, you attack a dependency that everyone relies on because it's been good and stable. That's how these pyramids build up over time. So spoiler, it's not unlikely one of…

> So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke?

Yes, absolutely. It's the bare minimum for people offering commercial products.

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

#313

Post by rcxdude »

skydhash wrote: post #131
exDM69 wrote: post #107

Earlier quoted context omitted.

The system package manager and the language package/dependency managers do a very different task. The distro package manager delivers applications (like Firefox) and a coherent set of libraries needed to run those applications. Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library, have libs with different compile time options enabled (or they need separate pa…

But I don’t really want your version of the application, I want the one that is aligned to my system. If some feature is really critical to the application, you can detect them at runtime and bailout (in C at least). Most developers are too aggressive on version pinning. > Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library They do, but most distro only supp…

Maybe you want that, but I generally want the version of the application that the devs have tested the most. I've dealt with many issues due to slight differences between dependency versions, and I'd rather not provoke them. (That said, I do like debian for boring infrastructure, because they can keep things patched without changing things, but for complex desktop apps, nah, give me the upstream versions please. And for things I'm developing myself the distro is but a vehicle for a static binary or self-contained folder)

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

#314

Post by mixedbit »

I'm afraid that open source software supply chain attacks could be much more prevalent than what we are currently aware of. There is a significant market for zero-day exploits, with organizations like the NSA having teams dedicated to collecting and weaponizing them. But finding and exploiting an unintentional zero-day vulnerability is way more difficult than adding an intentional exploitable bug or backdoor to some of the myriad widely used open source dependencies. Of course, if you do it right, you don't land on the HN front page.

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

#315

Post by rcxdude »

teddyh wrote: post #306
coldpie wrote: post #106

Earlier quoted context omitted.

> If you can’t run on $current_debian, that’s very much a you problem. This is a reasonable position for most software, but definitely not all, especially when you fix a bug or add a feature in your dependent library and your Debian users (reasonably!) don't want to wait months or years for Debian to update their packages to get the benefits. This probably happens rarely for stable system software like postgres and n…

Something I have seen that recently have become much more common is the software upstream authors providing a Debian repository for the latest versions of their software, including backports for old Debian releases.

Yes, mainly because such repositories don't have to follow debian's policies, and so it's a lot easier to package a version that vendors in dependencies in a version/configuration you're willing to support (and it's better to point users there than at an official debian version because if debian breaks something you'll be getting the bug reports no matter how much people try to tell users to report to the distribution first)

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

#316

Post by rcxdude »

skydhash wrote: post #260
marcosdumay wrote: post #248

Earlier quoted context omitted.

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

> 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. That is not what it's being asked. As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as…

>As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1).

That's provided by any competent build system. If you want to build it differently, with a different set of requirements, that's up to you to figure out (and fix when it breaks).

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

#317

Post by homebrewer »

shermantanktop wrote: post #281
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…

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 can be used to run npx, or anything else really — just shove move symblinks into the beginning of your $PATH, each referencing the script above. Run any of them and it's automatically restricted from accessing e.g. your ~/.ssh

https://wiki.archlinux.org/title/Bubblewrap

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

#318

Post by rcxdude »

skydhash wrote: post #279
imiric wrote: post #272

Earlier quoted context omitted.

There's no guarantee that software/library vX.Y.Z packaged by distro A will be identical in behavior to one packaged by distro B. Sure, distro maintainers have all sorts of guidelines, but in reality, mistakes happen, and there can be incompatibilities between the version a developer has been testing against, and one the end user is using. Relying on feature flags is a pie in the sky solution, and realistically devel…

But why do you care that much about how the user is running your code? Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you? You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code?…

Developers would generally like their application to work. Especially in the hands of non-technical users. If you're going to take things apart and take responsibility for when something breaks, go ham, but when devs find that their software is broken for many users because a widely-used distribution packaged it wrong, then it's kind of a problem because a) users aren't necessarily going to understand where the problem is, and b) regardless, it's still broken, and if you want to make something that works and have empathy for your users, it's kind of an unpleasant situation even if you're not getting the blame.

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

#319

Post by smj-edison »

Hilift wrote: post #146
0xbadcafebee wrote: post #64

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…

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

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

#320

Post by secureblue »

orblivion wrote: post #189
fsflover wrote: post #28

Earlier quoted context omitted.

> I do most of my coding in a VM now Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.

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 our selinux policy restricting userns usage (this can be toggled though, of course). Containers on their own don't provide sandboxing. The syscall filtering for them is extremely weak. Flatpak (which sandboxes via bubblewrap: https://github.com/containers/bubblewrap) can be configured to be reasonably good, but we still encourage the use of VMs if needed. We provide one-click tooling for easily installing virt-manager (https://en.wikipedia.org/wiki/Virt-manager) if desired.

In short though, secureblue and Qubes aren't really analogous. We have different goals and target use cases. There is even an open issue on Qubes to add a template to use secureblue as a guest: https://github.com/QubesOS/qubes-issues/issues/9755

Post reply on HN