Earlier quoted context omitted.
This is really interesting, thanks for sharing. Great food for thought. Being tightly coupled with MS already, did you ever explore .NET?
We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun…
Axios compromised on NPM – Malicious versions drop remote access trojan
791–800 of 894 posts
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#792I've been advocating to minimize the number of dependencies for some time now. Once you've maintained an open source project for several years, you start to understand the true cost of dependencies and you actually start to pay attention to the people behind the libraries. Popularity doesn't necessarily mean reliable or trustworthy or secure.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#793Earlier quoted context omitted.
The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is und…
please! nobody uses Xpath (coz json killed XML), it RDF (semantic web never happened, and one ever 10years is not fast), schema.org (again, nobody cares), PNG: no change in the last 26 years, not fast. the HTML "living standard" :D completely optional and hence not a standard but definition.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#794Earlier quoted context omitted.
Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.
It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#795"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…
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#796Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#797Earlier quoted context omitted.
There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes things like new file formats. 2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.). 3. Things like data structures, graphics APIs…
"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted . Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangero…
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#798Earlier quoted context omitted.
Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages. If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.
This is only true if you aren’t internally mirroring those packages. Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#799PSA: 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 :))