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

401–410 of 460 posts

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

#401

Post by 0xbadcafebee »

marshray wrote: post #349
smj-edison wrote: post #319

Earlier quoted context omitted.

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

My personal belief is that users should not be required type their password into random applications, terminals, and pop-up windows. Of course, login screens can be faked too. So my main user account does not have sudo permissions at all, I have a separate account for that.

I'm lazy, so I have sudo and 1P/op gated by biometric. If for some reason biometric doesn't work (which happens a lot in Ubuntu... sigh...) I have a long alt-password that works instead. Otherwise I never type passwords, I only get them from 1P, because they're all complex and unique so I wouldn't remember them anyway. If I get a prompt I wasn't expecting, I cancel it.

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

#402

Post by 0xbadcafebee »

awirth wrote: post #390
madeofpalk wrote: post #353

Earlier quoted context omitted.

gh cli is such a ticking time bomb. Anything can just run `gh auth token` and get a token that probably can read + write to all your work code.

These tokens never expire , and there is no way for organization administrators to get them to expire (or revoke them, only the user can do that), and they are also excluded from some audit logs. This applies not just to gh cli, but also several other first party apps. See this page for more details: https://docs.github.com/en/apps/using-github-apps/privileged... After discussing our concerns about these tokens with…

That is crazy. See, this is what I'm talking about. It shouldn't even be possible to have services that sensitive with auth tokens that can't expire.

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

#403

Post by lrvick »

oulipo2 wrote: post #366
lrvick wrote: post #359

Earlier quoted context omitted.

Downloading binaries as part of an installation of a scripting language library should always be assumed to be malicious. Everything must be provided as source code and any compilation must happen locally.

Sure, but then you need to have a way to whitelist

The whitelist is the package-lock.json of the hashes of libraries you or a security reviewer you trust has reviewed.

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

#404

Post by thayne »

TheDong wrote: post #377
thayne wrote: post #327

Earlier quoted context omitted.

But `go generate` can, and that is required to build some go projects. It is also somewhat common for some complicated projects to require running a Makefile or similar in order to build, because of dependencies on things other than go code.

The culture around "go generate" is that you check in any files it generates that are needed to build. In fact, for go libraries you effectively have to otherwise `go get` wouldn't work correctly (since there's no way to easily run `go generate` for a third-party library now that we're using go modules, not gopath). Have you actually seen this in the wild for any library you might `go get`? Can you link any examples?

> Have you actually seen this in the wild for any library you might `go get`?

Not for a library, but I have for an executable. Unfortunately, I don't remember what it was.

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

#405

Post by kalaksi »

ajross wrote: post #203
skydhash wrote: post #71

Earlier quoted context omitted.

The thing is, system based package managers require discipline, especially from library authors. Even in the web world, it’s really distressing when you see a minor library is already on its 15 iteration in less that 5 years. I was trying to build just (the task runner) on Debian 12 and it was impossible. It kept complaining about rust version, then some libraries shenanigans. It is way easier to build Emacs and ffmp…

Indeed, it seems insane that we're pining for the days of autotools, configure scripts and the cleanly inspectable dependency structure. But... We absolutely are.

Disagree. And why wouldn't dep structure be cleanly inspectable.

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

#406

Post by uto »

I observed a VS Code plugin compromise itself after running: "npx exec nx@latest --version".

Is it really that easy to get infected, or am I missing a more dangerous step it took? If this behavior is common, doesn’t it mean you could be exposed even without using a vulnerable plugin version, since it auto-runs @latest scripts just to check the version?

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

#407

Post by trw55 »

tiagod wrote: post #143
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…

Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.

Same for bun, which I find faster than pnpm

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

#408

Post by antihero »

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 wonder how many other packages are going to be compromised due to this also. Like a network effect.

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

#409

Post by mirekrusin »

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?

Downside is that you have to add "p" in front, ie. instead of "npm" you have to type "pnpm". That's all that I'm aware of.

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

#410

Post by azangru »

arminiusreturns wrote: post #216
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…

As a linux admin, I refuse to install npm or anything that requires it as a dep. It's been bad since the start. At least some people are starting to see it.

> As a linux admin, I refuse to install npm or anything that requires it as a dep. It's been bad since the start.

As a front-end web developer, I need a node package manager; and npm comes bundled with node.

Post reply on HN