> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)

First day with javascript?

Pnpm did this first but I’m glad to see all the others follow suit

For anyone wondering, you need to be on npm >= 11.10.0 in order to use it. It just became available Feb 11 2026

https://github.com/npm/cli/releases/tag/v11.10.0

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

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 :))

lol with mise I used a fourth time unit: https://mise.jdx.dev/configuration/settings.html#install_bef...

min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release

It's wild that none of these are set by default.

I know 90% of people I've worked with will never know these options exist.

If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.

and for yarn berry

    ~/.yarnrc.yml
    npmMinimalAgeGate: "3d"

I think the npm doesn't support end of line comments, so

  ~/.npmrc
  min-release-age=7 # days 

EDIT: Actually maybe it does? But it's weird because

`npm config list -l` shows: `min-release-age = null` with, and without the comment. so who knows ¯\_(ツ)_/¯

Run npm/pnpm/bun/uv inside a sandbox.

There is no reason to let random packages have full access to your machine

Props to uv for actually using the correct config path jfc what is “bunfig”

npm is claiming this doesn’t exist

Good luck with any `npm audit` in a pipeline. Sometimes you have to pull the latest release because the previous one had a critical vulnerability.

The config for uv won't work. uv only supports a full timestamp for this config, and no rolling window day option afaik. Am I crazy or is this llm slop?

> 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

Unless you are Python, where the standard library includes multiple HTTP libraries and everyone installs the requests package anyways.

Few languages have good models for evolving their standard library, so you end up with lots of bad designs sticking around forever. Libraries are much easier to evolve, giving them the advantage in terms of developer UX and performance.

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)

The other thing that keeps coming up is the github-code-is-fine-but-the-release-artifact-is-a-trojan issue. It really makes me question if "packages" should even exist in JavaScript, or if we could just be importing standard plain source code from a git repo.

I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

For a lot of code, I switched to generating code rather than using 3rd party libraries. Things like PEG parsers, path finding algorithms, string sanitizers, data type conversion, etc are very conveniently generated by LLMs. It's fast, reduces dependencies, and feels safer to me.

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.

This is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.

Honestly, you can get pretty far with just Bun and a very small number of dependencies. It’s what I love most about Bun. But, I do agree with you generally. .NET is about as good as I’ve ever seen for being batteries included. I just hate the enterprisey culture that always seems to pervade .NET shops.

What kind of apps do you build / industry etc?

> nearly every other project uses it for some reason instead of fetch (I never understood why).

Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.

> Good news for pnpm/bun users who have to manually approve postinstall scripts.

Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?

Does pnpm block postinstall on transitive deps too or just top-level? We have it configured at work but I've never actually tested whether it catches scripts from packages that get pulled in as sub-dependencies.

Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world.

What is a problem is library quality. Which is downstream of nobody getting paid for it, combined with an optimistic but unrealistic "all packages are equal" philosophy.

> High quality C libraries

> OpenSSL

OpenSSL is one of the ones where there's a ground up rewrite happening because the code quality is so terrible while being security critical.

On the other end, javascript is uniquely bad because of the deployment model and difficulty of adding things to the standard library, so everything is littered with polyfills.

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

I'm not sure why you believe this is more secure than a package manager. At least with a package manager there is an opportunity for vetting. It's also trivial that it did not increase your executable's size. If your executable depends on it, it increases its effective size.

If you're developing for the web your attack surface is quite a bit bigger. Your proposed solution of copying a few files might work but how do you keep track of updates? You might be vulnerable to a published exploit fixed a few months ago. A package manager might tell you a new version is available. I don't know how that would work in your scenario.

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

I don't think this community of professionals is going to come around to a solution which requires marginally more effort.

If no one checks their dependencies, the solution is to centralize this responsibility at the package repository. Something like left-pad should simply not be admitted to npm. Enforce a set of stricter rules which only allow non-trivial packages maintained by someone who is clearly accountable.

Another change one could make is develop bigger standard libraries with all the utilities which are useful. For example in Rust there are a few de facto standard packages one needs very often, which then also force you to pull in a bunch of transitive dependencies. Those could also be part of the standard library.

This all amounts to increasing the minimal scope of useful functionality a package has to have to be admitted and increasing accountability of the people maintaining them. This obviously comes with more effort on the maintainers part, but hey maybe we could even pay them for their labor.

I'd really like to see package managers organized around rings where a very small core of incredibly important stuff is kept in ring 0, ring 1 gets a slightly wider amount of stuff and can only depend on ring 0 dependencies and then ring 2+ is the crapware libraries that infect most ecosystems.

But maybe that's not the right fit either. The world where package managers are just open to whatever needs to die. It's no longer a safe model.

Rust libraries are infrequently used outside of Rust because if you have the option, you'd just use Rust, not the ancient featureless language intrinsically responsible for 70% of all security issues. C libraries are infrequently used in Rust outside of system libc, for the same reason; I go and toggle the reqwest switch to use rustls every time, because OpenSSL is horrendous. This is also why you say 'rarely' instead of 'never', when a few years ago it was 'never'; a few years from now you'll say 'uncommonly', and so on. The reason C libraries are used is because you don't feel like reimplementing it yourself, and they are there; but that doesn't apply more to C libraries than Rust libraries, and the vast majority of crates.io wouldn't be usefully represented in C anyway, or would take longer to bind to than to rewrite. (No, nobody uses libcurl.) Finally, this only happens in NPM, and the Rust libraries you pull in are all high-quality. So this sounds like a bunch of handwaving about nonsense.

no no, please we don't want to get back to dragging files to your project to make them work.

I think you can do copy paste in most languages. But it will be a pain to update when there are improvements / security fixes.

You got a project with 1-2 depencies? Sure. But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs) good luck.

> We have libraries like SQLite, which is a single .c file that you drag into your project

You are just swapping a package manager with security by obscurity by copy pasting code into your project. It is arguably a much worse way of handling supply chain security, as now there is no way to audit your dependencies.

> If you get rid of transitive dependencies, you get rid of the need of a package manager

This argument makes no sense. Obviously reducing the amount of transitive dependencies is almost always a good thing, but it doesn't change the fundamental benefits of a package manager.

> There's so many C libraries like this

The language with the most fundamental and dangerous ways of handling memory, the language that is constantly in the news for numerous security problems even in massively popular libraries such as OpenSSL? Yes, definitely copy-paste that code in, surely nothing can go wrong.

> They also bindings for every language under the sun. Rust libraries are very rarely used outside of Rust

This is a WILD assumption, doing C-style bindings is actually quite common. YOu will of course then also be exposing a memory unsafe interface, as that is what you get with C.

What exactly is your argument here? It feels like what you are trying to say is that we should just stop doing JS and instead all make C programs that copy paste massive libraries because that is somhow 'high quality'.

This seems like a massively uninformed, one-sided and frankly ridiculous take.

If the fat std library is not viable you can only increase security requirements.

Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.

Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.

Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse.

It's what we call in France "la fête du slip".

PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLisp, because I really see the size of my deptree this way.

NPM should have a curation mechanism, via staff review or crowdsourcing, where versions of popular packages are promoted to a stable set, like linux distros do. I would only use curated versions if they had such a thing.

An alternative:

- copy the dependencies' tests into your own tests

- copy the code in to your codebase as a library using the same review process you would for code from your own team

- treat updates to the library in the same way you would for updates to your own code

Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've been doing this from the start, even if I understand why we haven't. The excuses are starting to wear thin though.

This only works for post-install script attacks. When the package is compromised, just running require somewhere in your code will be enough, and that runs with node/java/python and no bwrap.

I wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages.

https://github.com/ashishb/amazing-sandbox

Check also https://github.com/wrr/drop which is a higher-level tool than bwrap. It allows you to make such isolated sandboxes with minimal configuration.

I like the idea of bubblewrap, but my pain point is that it is work to set it up correctly with bind mounts and forwarding necessary environment variables to make the program actually work usefully. Could you share your pip bwrap configuration? It sounds useful.

I think firejail is a much more flexible security sandbox than bwrap. It also comes with pre-defined profiles

> SSH is forwarded via socket

Maybe I misunderstood this point. But the ssh socket also gives access to your private keys, so I see no security gain in that point. Better to have a password protected key.

Do you have a recommendation for something like bwrap but for macos? I've been trying to use bwrap more on my servers when I remember.

AFAIK maven doesn’t support post install logic like npm does. You have to explicitly optin with build plugins. It doesn’t let any arbitrary dependency run code on your machine.

> At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar

I kind of feel like the authors here should want that for themselves, before the community would even realize it's needed. I can't say I've worked on packages that are as popular as axios, but once some packages we were publishing hit 10K downloads or so, we all agreed that we needed to up our security posture, and we all got hardware keys for 2FA and spent 1-2 weeks on making sure it was as bullet-proof we could make it.

To be fair, most FOSS is developed by volunteers so I understand not wanting to spend any money on something you provide for free, but on the other hand, I personally wouldn't feel comfortable being responsible for something that popular without hardening my own setup as much as I could, even if it means stopping everything for a week.

Totally agree.

Also, considering how prevalent TPM/Secure Enclaves are on modern devices, I would guess most package maintainers already have hardware capable of generating/using signing keys that never leave hardware.

I think it is mostly a devex/workflow question.

Considering the recent ci/cd-pipeline compromises, I think it would make sense to make a two phase commit process required for popular packages. Build and upload to the registry from a pipeline, but require a signature from a hardware resident key before making the package available.

Most of axios' functionality has effectively been promoted to a language feature as `fetch`, but the problem is people don't bother to migrate. I've migrated our direct usage of it but it's still pulled in transitively in several parts of our codebase.

Even left-pad is still getting 1.6 million weekly downloads.

Or those people can (fund) separate repackaging and redistribution with more stringent and formalized review process.

Maybe not all users should pull all packages straight from what devs are pushing.

There's no reason we can't have "node package distributions" like we have Linux distributions. Maybe we should stop expecting devs and maintainers and Microsoft to take responsibility for our supply-chain.

We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same.

I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement.

We are now at the stage in software development where we are beginning to recognizing the hazards and developing + mandating use of proper PPE.

A couple of years ago, pip started refusing to install packages outside of a virtualenv. I'm guessing/hoping package managers will start to have an opt-in flag you can set in a system-wide config file, such that they refuse to run outside of a sandbox.

This sounds like satire but isn't - I just make sure the nodejs/npm packages don't exist on my system. I've yet to find a crucial piece of software that requires it. As much as I love that cute utility that turns maps into ascii art, it's not exactly sqlite in terms of usefulness.

> it’s got me nervous to use Python or Node.js these days

My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.

I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.

More like the Trivy incident (which led to the compromise of LiteLLM).

There are ways to limit the blast radius, like running them in ephemeral rootless containers with only the project files mounted.

> Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.

Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.

NextDNS has a setting to block newly registered (<30d) domains.

I was thinking about this as a bull case for human developers. Seems if you're worried enough to do this you're not going to have LLMs write the new code.

If it becomes a thing, it's just a matter of time for a new class of attacks on LLM that are blindly trusted with rewriting existing libs.

Or just lock to a specific version?

Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated.

A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

Or more simply:

    find / -type f -path '*/node_modules/axios/package.json' \
        -exec grep -Pl '"version"\s*:\s*"(1\.14\.1|0\.30\.4)"' {} + 2>/dev/null

Sounds great until trivy images get compromised, like last week.

The ones you hear about are caught quickly, I’m more worried about the non obvious ones. So far none of these have been as simple as changing a true to a false and bypassing all auth for all products or something, and would that be caught by an automated scanner?

Isn't Rust just as susceptible to this issue? For example, how do you deal with Rust's lack of support for HTTP in the standard library? Importing hyper pulls in a couple dozen transitive libraries which exposes you to the exact same kind of threats that compromised axios.

Given how HTTP is now what TCP was during the 90s and almost all modern networked applications needing to communicate in it one way or another, most rust projects come with an inherent security risk.

These days, I score the usability of programming languages by how complete their standard library is. By that measure, Rust and Javascript get an automatic F.

It's mind boggling when a simple Rust app pulls in Serde and with it half a black hole worth of packages to serialize some mundane JSON.

Where would you suggest putting the sensitive credentials?

Not all distributions work with a staging repository, and it's not really intended for this purpose either.

Besides there's always a way to immediately push a new version to stable repositories. You have to in order to deal with regressions and security fixes.

NPM is one big AUR, where anyone can submit arbitrary unverified code. The difference is that AUR is intentionally harder to use to prevent catastrophic one-line installs.

Min release age might just postpone vulnerability to be applied few days later in non trivial cases like this. More I think about it, Odin lang approach of no package manager makes senses. But, for that approach won't work for Javascript as it needs npm package even for trivial things. Even vendoring approach like golang won't work with Javascript with the amount of churn and dependencies.

Is this the first time you have ever thought about the idea of supply chain attacks? This is the first thought 90% of people have and it doesn't work. Too much work to manually verify diffs and LLMs aren't good enough at this yet.

Axios has a long history, and is included in a lot of code, also in indirect dependencies. Just check its npm page: it has 174025 dependents as of this moment, including a lot of new packages (I see openclaw and mcp related packages in the list).

And with LLMs generating more and more code, the risk of copying old setups increases.

> The amount of people still using this instead of fetch.

People are lazy. And sometimes they find old stuff via a google search and use that.

Skills are great attack vector as well.

Yes. Docker breakout is a class of vulnerabilities into itself.

Called it yesterday.

One more reason to use Fetch

Apparently it's possible to create access tokens that bypass 2FA. Might've been this.

https://docs.npmjs.com/creating-and-viewing-access-tokens

Absolutely. If you ever did a npm install on a project using one of the affected axios versions, your entire system may be compromised.

> The malicious versions inject a new dependency, plain-crypto-js@4.2.1, which is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux. The dropper contacts a live command and control server and delivers platform specific second stage payloads. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection.

I strongly recommend you read the entire article.

But also have a regular review of your dependencies to update them when necessary, because as bad as compromised packages may be things do have vulnerabilities occasionally, and upgrading things that are a long way out-of-date can be quite hard.

That maintainer (also the one whose creds got stolen) also has an obvious chatgpt slop profile picture on github.

npx is just a bad command to use.

What do you mean?

Linux has the most powerful native process isolation arsenal at the user disposal.

And some distros use even more isolation mechanisms on top of the ones provided by the kernel like snap and flatpak.

And then you can recreate the entire thing like a spellbook with nix.

Docker works natively in it. Do I need to say more?

Linux is a decade ahead here with regards for security options available to the user.

Slow Russian roulette is still a losing strategy

I second this question. I usually scan our containers with snyk and guarddog, and have wondered about guarddog in particular because it adds so much build time.

> tried to test the LiteLLM hack but the affected packages had been pulled

Hey, I have been part of the archival effect/Litellm issue thread. I think I have stored them in archive.org for preservation purposes

https://web.archive.org/web/20260325073027/https://files.pyt...

(I have also made an archive of the github issue with all the comments manually till a certain point at https://web.archive.org/web/20260325054202/https://serjaimel...)

> Has anyone tested general purpose malware detection on supply chains ? Like clamscan

You could use Trivy! /s

Skipping Node sounds nice. PyPI and RubyGems have had the same mess, and npm gets more headlines because it is huge and churns fast, so you see more fresh landmines and more people stepping on them. Unless you plan to audit every dep and pin versions yourself, you're mostly trading one supply chain mess for another, with a tiny bit of luck and a differnt logo.

Because no other language has ever had supply chain attacks ever, in history. Nope.

https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde...

https://en.wikipedia.org/wiki/Log4Shell

https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-an...

https://about.gitlab.com/blog/gitlab-catches-mongodb-go-modu...

https://www.reversinglabs.com/blog/packagist-php-repo-supply...