3 ms·

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Li

by nine_k 6mo ago

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.

vsgherzi 6mo ago
Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.
- nine_k 6mo ago
  There's no silver bullet, but getting an exploit into xz took extraordinary effort, a long time, and bespoke code, because it needed to slip under the radar of actual humans reading the code. A shai hulud-style attack won't work with any reasonable Linux distro, like it does with npm.
- kelvinjps10 6mo ago
  but it was caught with the existing release model, where first it goes to testing where many people before reaching the production systems in the stable release. for example debian
ljm 6mo ago
The community decided it's too much effort to vet code before publishing it so here we are. (I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies) I landed on the 'yes, you should know what code you are getting involved with' side.
- baq 6mo ago
  'yes, you should' needs to be reconciled with 'it's f*g expensive' and 'risk is low'. nowadays, 'risk is low' isn't true anymore and it's actually cheaper to have a robot spit out a reimplementation of the 5.4% of what you need out of your dependencies instead of auditing the 100%.
jadbox 6mo ago
Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.
- spartanatreyu 6mo ago
  This is exactly why I love Deno so much, it has a standard lib AND a security model that's secure by default.
devttyeu 6mo ago
Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.
- nine_k 6mo ago
  > comes out to ~$200 in tokens every time BTW a curated mirror of <whatever ecosystem> packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org. Docker does something vaguely similar for Docker images, for free though.
  - AgentME 6mo ago
    People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).
    - nine_k 6mo ago
      Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit.
  - chickensong 6mo ago
    https://www.chainguard.dev/ https://www.chainguard.dev/
- voxl 6mo ago
  It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.
slopinthebag 6mo ago
Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years? Idk about Python, I refuse to use that language for other reasons.
- pier25 6mo ago
  It makes more sense to attack packages in NPM since it's by far the most popular package manager.
  - gitaarik 6mo ago
    Yeah indeed, you can move to a less popular ecosystem and have less risk. Back in the day when I moved from PHP ecosystem to Python, that was a big improvement. But with NPM I feel mixed; there's a lot of crap, but there's also genuinely good stuff. So you have to be a bit more conscious and alert when you make decisions on packages etc. With more mature ecosystems you have that problem less, and you don't have to spend so much time on package research and can rely more on the community. But still there's always a risk there too, so you have to stay alert.
hans-l 6mo ago
[dead]
TZubiri 6mo ago
Just writing the actual code that you are being paid to write
- vinyl7 6mo ago
  The only correct answer
chuckadams 6mo ago
> Abandon NPM in exchange for what? Cargo? Go get? Pip install? pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed.
m4rtink 6mo ago
Distro packages maintained and (hopefully audited on update) by separate maintainers ?

by nine_k 6mo ago

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.

vsgherzi 6mo ago

Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.

nine_k 6mo ago
There's no silver bullet, but getting an exploit into xz took extraordinary effort, a long time, and bespoke code, because it needed to slip under the radar of actual humans reading the code. A shai hulud-style attack won't work with any reasonable Linux distro, like it does with npm.
kelvinjps10 6mo ago
but it was caught with the existing release model, where first it goes to testing where many people before reaching the production systems in the stable release. for example debian

ljm 6mo ago

The community decided it's too much effort to vet code before publishing it so here we are. (I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies) I landed on the 'yes, you should know what code you are getting involved with' side.

baq 6mo ago
'yes, you should' needs to be reconciled with 'it's f*g expensive' and 'risk is low'. nowadays, 'risk is low' isn't true anymore and it's actually cheaper to have a robot spit out a reimplementation of the 5.4% of what you need out of your dependencies instead of auditing the 100%.

jadbox 6mo ago

Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.

spartanatreyu 6mo ago
This is exactly why I love Deno so much, it has a standard lib AND a security model that's secure by default.

devttyeu 6mo ago

Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.

nine_k 6mo ago
> comes out to ~$200 in tokens every time BTW a curated mirror of <whatever ecosystem> packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org. Docker does something vaguely similar for Docker images, for free though.
- AgentME 6mo ago
  People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).
  - nine_k 6mo ago
    Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit.
- chickensong 6mo ago
  https://www.chainguard.dev/ https://www.chainguard.dev/
voxl 6mo ago
It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.

slopinthebag 6mo ago

Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years? Idk about Python, I refuse to use that language for other reasons.

pier25 6mo ago
It makes more sense to attack packages in NPM since it's by far the most popular package manager.
- gitaarik 6mo ago
  Yeah indeed, you can move to a less popular ecosystem and have less risk. Back in the day when I moved from PHP ecosystem to Python, that was a big improvement. But with NPM I feel mixed; there's a lot of crap, but there's also genuinely good stuff. So you have to be a bit more conscious and alert when you make decisions on packages etc. With more mature ecosystems you have that problem less, and you don't have to spend so much time on package research and can rely more on the community. But still there's always a risk there too, so you have to stay alert.

hans-l 6mo ago

[dead]

TZubiri 6mo ago

Just writing the actual code that you are being paid to write

vinyl7 6mo ago
The only correct answer

chuckadams 6mo ago

> Abandon NPM in exchange for what? Cargo? Go get? Pip install? pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed.

m4rtink 6mo ago

Distro packages maintained and (hopefully audited on update) by separate maintainers ?