GitLab discovers widespread NPM supply chain attack • Hacker News Board

Re: GitLab discovers widespread NPM supply chain attack

#251

Post by __turbobrew__ » Sat, Nov 29, 2025, 5:50 PM UTC

mcny wrote: post #86

febusravenga wrote: post #75

Earlier quoted context omitted.

this, this, this All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile. And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…

Yubikey/TouchID

Re: GitLab discovers widespread NPM supply chain attack

#252

Post by jazzypants » Sat, Nov 29, 2025, 7:37 PM UTC

bakkoting wrote: post #250

jazzypants wrote: post #237

Earlier quoted context omitted.

I'm sorry, but this is just incorrect. Have you ever heard of ljharb[0]? The NPM ecosystem is rife with polyfills[1]. I don't know how you can make a distinction on which libraries would be used for "local scripting" as I don't think many library authors make that distinction. [0] - TC39 member who is self-described as "obsessed with backwards compatibility": https://github.com/ljharb [1] - Here's one of many article…

Yes. I'm on TC39 as well, and I've talked to Jordan about this topic. It's true that there are a few people who publish packages on npm including polyfills, Jordan among them. But these are a very small fraction of all packages on npm, and none of the compromised packages were polyfills. Also, he cares about backwards compatibility _with old versions of node_; the fact that JavaScript was originally a web language, a…

Fair enough. Thank you for the clarification, and I apologize for not recognizing your status as a TC39 member.

Re: GitLab discovers widespread NPM supply chain attack

#253

Post by brabel » Sat, Nov 29, 2025, 9:09 PM UTC

gruez wrote: post #227

brabel wrote: post #224

Earlier quoted context omitted.

Bullshit. The public key can be obtained by several easy means, like visiting the publisher website or social network site like GitHub which is common. That verifies the identity just as well as any certificate! But with much less trouble.

How are you still missing the "real identity" part? A bitcoin address might be easily verifiable, but isn't anyone's idea of "real identity".

Real identity is impossible to establish beyond any doubt, and a certificate is no better than a key on a website, in fact it's essentially the exact same thing.

Re: GitLab discovers widespread NPM supply chain attack

#254

Post by AmbroseBierce » Sun, Nov 30, 2025, 4:51 AM UTC

bakkoting wrote: post #205

AmbroseBierce wrote: post #65

Microsoft should just bite the bullet and make a huge JS standard library and then send GitHub notifications to all the project maintainers who are using anything that could be replaced by something from there suggesting them to do such replacement. This would likely significantly reduce the number of supply chain attacks on the npm ecosystem.

If you look at the list of compromised packages, very few of them could reasonably be included in a standard library. It's mostly project-specific stuff like `@asyncapi/specs` or `@zapier/zapier-sdk`. The most popular generic one I see is `get-them-args`, which is a CLI argument parser - which is something Node has in the form of `util.parseArgs` since v16.17.0.

Well they clearly lacked marketing? Pretty sure a red text in npm every time that package was installed that says "hey we have a better way to do this with node alone" would have made a dent in the library usage, but they didn't do anything of the sort.

Re: GitLab discovers widespread NPM supply chain attack

#255

Post by bitfilped » Sun, Nov 30, 2025, 6:48 AM UTC

sigmoid10 wrote: post #141

qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore…

Containers don't help much when you deploy malware into your systems, containers are not and never will be security tools on Linux, they lack many needed primitives to be able and pull off that type of functionality.

Re: GitLab discovers widespread NPM supply chain attack

#256

Post by bitfilped » Sun, Nov 30, 2025, 6:50 AM UTC

naikrovek wrote: post #233

nyrikki wrote: post #217

Earlier quoted context omitted.

You seem to have a misunderstanding of what namespaces accomplished on plan9, or that it was extending Unix concepts and assembling them in another way. As someone who actually ran plan9 over 30 years ago I ensure that if you go back and look at it, the namespaces were intended to abstract away the hardware limitations of the time, to build distributed execution contexts of a large assembly of limited resources. And…

Kubernetes is an operating system on top of an operating system. Its complexity is insane. The base OS should be providing a lot/all of these features by default. Plan9 is as you describe out of the box, but what I want is what plan9 might be if it were designed today and could be with a little work. Isolation would not be terribly difficult to add to it. The default namespace a process gets by default could limit it…

Because containers on Linux will never be able to provide this, they are fundamentally insecure from the kernel layer up, adding another OS stack on top (k8s) will never address the underlying mess that Linux containers are fundamentally.

Re: GitLab discovers widespread NPM supply chain attack

#257

Post by wasmainiac » Sun, Nov 30, 2025, 10:19 AM UTC

sigmoid10 wrote: post #141

qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore…

Why distro do you run? Python is a part of the os in many cases ?

It’s a fair angle your taking here, but I would only expect to see it on hardend servers.

Re: GitLab discovers widespread NPM supply chain attack

#258

Post by tinodb » Sun, Nov 30, 2025, 9:21 PM UTC

internet_points wrote: post #223

sakisv wrote: post #123

Earlier quoted context omitted.

The way I solve the plain text problem is through a combination of direnv[1] and pass[2]. For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey. Next to the `./creds` dir…

but if you `cd project && npm install compromised-package` then compromised-package's setup script can still read your env vars, right?

Yes, but I guess that is still much better than that it can read all your .env files on your machine

Re: GitLab discovers widespread NPM supply chain attack

#259

Post by naikrovek » Sun, Nov 30, 2025, 10:59 PM UTC

bitfilped wrote: post #256

naikrovek wrote: post #233

Earlier quoted context omitted.

Kubernetes is an operating system on top of an operating system. Its complexity is insane. The base OS should be providing a lot/all of these features by default. Plan9 is as you describe out of the box, but what I want is what plan9 might be if it were designed today and could be with a little work. Isolation would not be terribly difficult to add to it. The default namespace a process gets by default could limit it…

Because containers on Linux will never be able to provide this, they are fundamentally insecure from the kernel layer up, adding another OS stack on top (k8s) will never address the underlying mess that Linux containers are fundamentally.

Thank you.

OS-level isolation needs to be a thing. And it needs to be on by default.

Re: GitLab discovers widespread NPM supply chain attack

#260

Post by Balinares » Mon, Dec 01, 2025, 5:35 PM UTC

magnetometer wrote: post #77

Balinares wrote: post #51

Earlier quoted context omitted.

As far as I understand, NPM packages are not self-contained like e.g. Python wheels and can (and often need to) run scripts on install . So just installing a package can get you compromised. If the compromised box contains credentials to update your own packages in NPM, then it's an easy vector for a worm to propagate.

Python wheels don't run arbitrary code on install, but source distributions do. And you can upload both to pypy. So you would have to run pip install --only-binary :all: to only install wheels and fail otherwise.

Fair point -- I was only thinking wheels, but you are right.

Would source distributions work as a vector for automated propagation, though? If I'm not mistaken, there's no universal standard for building from source distributions.