Hacker News

"April 10, 2026"

I don't blame you, took me awhile to find the date.

> Depending on Axios suggests the devs don't know how to use fetch.

You could equally say that using fetch means that the developers don't know how to use axios.

They do the same thing, except axios does it a little better, when it doesn't pwn you.

Axios predates the availability of fetch in node by 2 years, and fetch has never caught up with axios so there was no reason to switch to fetch, unless you need to run on both client and server then of course you use fetch.

I wouldn't go that far. Right tool for the job as always. Axios offers a lot over fetch for all but the simplest use cases plus you get to take advantage of the ecosystem. Need offline, axios-cache-interceptor already exists. Sure you can do all of those things with fetch but you need more to go with it taking you right back to just using axios. Also is no one annoyed that you can't replay fetch like the xhr? Same with express: solves a problem reliably.

If you want a fully built out network layer, with auth, logging, monitoring, policies, etc, then `fetch` doesn't really help. Axios and other libraries provide much more for building that sort of framework.

I do "just use fetch" nowadays -- but I have to say, axios definitely has better ergonomics than fetch, especially for calling APIs.

> Axios, like Express, is something I'm shocked to see used in any modern codebase

I am totally with you on axios; but why is express shocking, and what do you expect to see in its place? Fastify? Hono? Node:http?

Because your fetch most likely mishandle errors, lack retries, fail on redirects and is unnecessary verbose for both people and agents.

What's wrong with Express?

What’s wrong with express?

Annoyingly, fetch does not support progress events and HTML / XML Document parsing, which are both supported by XMLHttpRequest, which Axios is based on.

ChatGPT in general recommends axios over fetch. (At least it did about 2 months ago)

jQuery is still useful too. May you never work in heathcare / government / defense where you need to support legacy browsers far past their expiration date.

They used a GitHub action with a floating tag (I guess @latest or non SHA pinned e.g. @v4) that I’m assuming in turn had its latest version bringing latest axios.

That GitHub action used to sign their Mac apps.

So they assume the certificate used to sign is compromised.

The risk is not to existing app, but theoretically someone could give you a copy of a malicious OpenAI binary, sign it with the compromised certificate, and impersonate OpenAI. Unlikely, but not impossible.

I'd assume they're retiring their old codesign certificates and rolling new ones, hopefully on a HSM or sth

I believe you understand correctly. And yes, it’s both a bad practice and shifting blame. But it’s not an uncommon practice sadly.

They mention it toward the end:

> The root cause of this incident was a misconfiguration in the GitHub Actions workflow, which we have addressed. Specifically, the action in question used a floating tag, as opposed to a specific commit hash, and did not have a configured minimumReleaseAge for new packages.

Some preventive actions everyone should take:

1. pin GitHub actions to SHAs (GitHub sadly doesn’t enforce immutable tags, it’s opt in only, but commits are practically non-repeatable, minus sha collision), also even if an action it’s not compromised directly, the latest version might be using a compromised dependency, so by taking the latest of one you get the latest (compromised) of the other. Pinning just prevents auto updates like this.

2. do npm ci instead of npm install (the first will be using a lock file the other may take the latest depending on how your package.json defines dependencies)

3. have a min release age (e.g. min-release-age=7 in .npmrc) most recent SSC attacks were removed from npm within hours. Adding a delay is similar to a live broadcast “bleep” delay.

At this point I feel Github is getting Wordpress'd.

It has become so critical and ubiquitous that it has become a huge target for attackers.

Of course, when everyone sets min-release-age=7, supply chain attacks won't get noticed until 7 days later. So you should set min-release-age=14 and be safe forever.

Nice ad you got there. How do I define request interceptors with fetch? Axios does it.

The real issue is the cancer practice in our software development industry of updating dependencies for the sake of updating.

Deps should be updated when you need some features or bugfixes from the new versions; not just when DependaBot prompts you to do it.

I see value in DependaBot and things like that only to check that your module still passes your CI with upgraded dependencies (and if not, then it's worth looking at the failure, to be prepared for the updgrade in the future).

Other ecosystems have better protections against compromised packages? I don't see it.