Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

551–560 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#551

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

Language churn makes this problem worse.

Frankly inventing a new language is irresponsible these days unless you build on-top of an existing ecosystem because you need to solve all these problems.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#553
post #407
post #350

Earlier quoted context omitted.

What are some examples of batteries-included languages that folk around here really feel productive in and/or love? What makes them so great, in your opinion? (Leaving aside thoughts on language syntax, compile times, tooling etc - just interested in people's experiences with / thoughts on healthy stdlibs)

Go is well known for its large and high quality std lib

Go didn't even have versioning for dependencies for ages, so CVE reporting was a disaster.

And there's plenty of libraries you'll have to pull to get a viable product.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#555
post #157

Earlier quoted context omitted.

For some reason, NPM is the only ecosystem with substantial issues with supply-chain attacks.

Popularity

The number of issues is disproportionately larger than the one for Debian.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#556

(A bit off-topic; half-joking, half-serious) What a great time to be alive! Now, that's exactly why I enjoy writing software with minimal dependencies for myself (and sometimes for my family and friends) in my spare time - first, it's fun, and second, turns out it's more secure.

This only limits the possibility of compromise, it doesn't remove it. Python itself could be compromised, or the package that your linux distro provides could be.

With AI agents the volume and frequency of supply chain attacks is going to explode. I think our entire notion of how to develop and distribute software safely needs to change. I don't have answers; "reflections on trusting trust" explains the difficulties we now face.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#557

Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…

They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far: 1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment. 2. Publishers to official registries should…

> Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot.

How is this enforced when it's pushed via a pipeline?

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#558

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…

Is there a way to do that per repo for these tools ? We all know how user sided configuration works for users (they usually clean it whenever it goes against what they want to do instead of wondering why it blocks their changes :))

pnpm does global + per-repo

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#559

Earlier quoted context omitted.

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

When I worked in Finance our internal Date extension did actually have Workdays that took into account Stock Market and Bank Holidays.

…now imagine a list of instruments, some of which have durations specified in days/weeks/months (problems already with the latter) and some in workdays, and the user just told your app to display it sorted by duration.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#560
post #376

Earlier quoted context omitted.

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

With the notable exception of cross-platform audio.

Not really notable, aiui the only mainstream language with anything like that is JS in the browser

And for good reason. There are enough platform differences that you have to write your own code on top anyway.

Post reply on HN