Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab discovers widespread NPM supply chain attack

about.gitlab.com

Post reply on HN
Print view View original

121–130 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#121

Post by jackwilsdon »

tuzemec wrote: post #119
austin-cheney wrote: post #117

Are there any good alternatives to ESLint? ESLint is now my only dev dependency with hundreds of dependencies of its own.

Biome: https://biomejs.dev/ Also the whole ecosystem around OXS looks very promising: https://oxc.rs/

Both of those have over >400 dependencies each [0] [1] but just in Rust instead - there hasn't been a Rust supply chain attack yet but is this any better? [2]

Admittedly you're not normally downloading the dependencies to your machine as you're often using pre-built binaries, but a malicious package could still run if a version was shipped with it.

[0]: https://github.com/biomejs/biome/blob/93182ea8e9d479fd0187ce...

[1]: https://github.com/oxc-project/oxc/blob/65bd5584bfce0c7da90f...

[2]: https://users.rust-lang.org/t/yet-another-npm-supply-chain-a...

Re: GitLab discovers widespread NPM supply chain attack

#122

Post by sierra1011 »

wonderfuly wrote: post #67

I'm a victim of this. In addition to concerns about npm, I'm now hesitant to use the GitHub CLI, which stores a highly privileged OAuth token in plain text in the HOME directory. After the attacker accesses it, they can do almost anything on behalf of me, for example, they turned many of my private repos to public.

I'm also a victim of this. Last time I try and install Backstage.

Have you wiped your laptop/infected machine? If not I would recommend it; part of it created a ~/.dev-env directory which turned my laptop into a GitHub runner, allowing for remote code execution.

I have a read-only filesystem OS (Bluefin Linux) and I don't know quite how much this has saved me, because so much of the attack happens in the home directory.

Re: GitLab discovers widespread NPM supply chain attack

#123

Post by sakisv »

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…

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` directory, I have an `.envrc` which includes some lines that read the encrypted files and store their values in environment variables, like so: `export CLOUDFLARE_API_TOKEN=$(pass creds/cloudflare/api_token)`.

Every time that I `cd` into that project's directory, direnv reads and executes that file (just once) and all these are stored as environment variables, but only for that terminal/session.

This solves the problem of plain-text files, but of course the values remain in ENV and something malicious could look for some well known variable names to extract from there. Personally I try to install things in a new termux tab every time which is less than ideal.

I'd like to see if and how other people solve this problem

[1]: https://direnv.net/ [2]: https://www.passwordstore.org/

Re: GitLab discovers widespread NPM supply chain attack

#124

Post by sensanaty »

louiskottmann wrote: post #53
torben-friis wrote: post #40

Earlier quoted context omitted.

One factor is that node's philosophy is to have a very limited standard library and rely on community software for a ton of stuff. That means that not only the average project has a ton of dependencies, but also any given dependency will in turn have a ton of dependencies as well. there’s multiplicative effects in play.

This is my take as well. I've never come accross a JS project where the built-in datastructures were exclusively used. One package for lists, one for sorting, and down the rabbit hole you go.

I think this is mostly historical baggage unfortunately. Every codebase I've ever worked in there was a huge push to only use native ES6 functionality, like Sets, Maps, all the Iterable methods etc., but there was still a large chunk of files that were written before these were standardized and widely used, so you get mixes of Lodash and a bunch of other cursed shit.

Refactoring these also isn't always trivial either, so it's a long journey to fully get rid of something like Lodash from an old project

Re: GitLab discovers widespread NPM supply chain attack

#126

Post by mikkupikku »

> "This creates a dangerous scenario. If GitHub mass-deletes the malware's repositories or npm bulk-revokes compromised tokens, thousands of infected systems could simultaneously destroy user data."

Pop quiz, hot shot! A terrorist is holding user data hostage, got enough malware strapped to his chest to blow a data center in half. Now what do you do?

Shoot the hostage.

Re: GitLab discovers widespread NPM supply chain attack

#127

Post by Flere-Imsaho »

zx8080 wrote: post #95

Everyone wanted to centralise as much as possible to save every cent. No wonder what it got us all into. Enjoy it while saving your cent!

Also layer upon layer of abstractions - to the point where no single person understands the stack from top to bottom.

Perhaps there is a light at the end of the tunnel: with AI coding assistance, the whole application can be written from scratch (like the old days). All the code is there, not buried deep within someone else's codebase.

Re: GitLab discovers widespread NPM supply chain attack

#128

Post by kubafu »

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…

Same story from a month ago. The moment I saw the sheer number of dependencies artillery wanted to pull I gave up.

Re: GitLab discovers widespread NPM supply chain attack

#129

Post by brabel »

jackwilsdon wrote: post #121
tuzemec wrote: post #119

Earlier quoted context omitted.

Biome: https://biomejs.dev/ Also the whole ecosystem around OXS looks very promising: https://oxc.rs/

Both of those have over >400 dependencies each [0] [1] but just in Rust instead - there hasn't been a Rust supply chain attack yet but is this any better? [2] Admittedly you're not normally downloading the dependencies to your machine as you're often using pre-built binaries, but a malicious package could still run if a version was shipped with it. [0]: https://github.com/biomejs/biome/blob/93182ea8e9d479fd0187ce...…

Wow that’s terrifying.

Re: GitLab discovers widespread NPM supply chain attack

#130

Post by brabel »

gruez wrote: post #15
yupyupyups wrote: post #10

Something helpful here would be to enable developers to optionally identify themselves. Not Discord-style where only the platform knows their real identity, but publically as well.

So, EV code signing certificates? Windows has that, and it'll verify that right in the OS. Git for instance, shows as being signed by CN = Johannes Schindelin O = Johannes Schindelin S = Nordrhein-Westfalen C = DE Downside is the cost. Certificates cost hundreds of dollars per year. There's probably some room to reduce cost, but not by much. You also run into issues of paying some homeless person $50 to use their ide…

You don’t need certificates , just use PGP keys like Maven.
Post reply on HN