Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenAI's response to the Axios developer tool compromise

openai.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: OpenAI's response to the Axios developer tool compromise

#61

Post by internetter »

interstice wrote: post #43
internetter wrote: post #11

Earlier quoted context omitted.

Any sufficiently competent typescript developer can build out an adhoc wrapper (that just inherits the type definition and passes along whatever it is passed after altering it however needed) in under a hour. It doesn't scale in the sense that you don't expose a configuration, but config as code is king. (Source: have built out much more scuffed variants of this than the one I just described like https://github.com/b…

Ah yes ad hoc, the best way to write fundamental utilities underpinning every fetch your app makes.

Wrapping fetch is not rocket science

Re: OpenAI's response to the Axios developer tool compromise

#62

Post by nurettin »

ipaddr wrote: post #22
nurettin wrote: post #8

Earlier quoted context omitted.

When the vulnerability was announced, it took me two minutes to one-shot convert an entire legacy project from axios to fetch (it already wrapped api calls neatly), react cra to vite, update all dependencies, convert to deep imports to reduce bundle size and get zero npm warnings while fetching coffee. There is just no excuse to use it.

Move from a tested library where when a vulnerability is discovered everyone in the world is made aware to an untested one shot llm output that if a vulnerability is discovered will never come to light . What's the reason to switch to something less stable short/long term? Because its older and newer code is always better?

That's like saying rpad is well tested. Axios isn't exactly rocket science, it is trivial to replace. So much so that even a SOTA llm does it reliably. I'd say good riddance.

Re: OpenAI's response to the Axios developer tool compromise

#63

Post by [deleted] »

danscan wrote: post #4

Axios, like Express, is something I'm shocked to see used in any modern codebase. I loved both in the 2010s. In JS/TS-land there are much simpler and better options these days. Depending on Axios suggests the devs don't know how to use fetch. I can't think of another reason it would be a necessary dependency

[deleted]

Re: OpenAI's response to the Axios developer tool compromise

#64

Post by tracker1 »

sampullman wrote: post #9
jwilliams wrote: post #5

Earlier quoted context omitted.

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

I drag a tiny fetch wrapper around with error/json handling, timeouts and basic interceptor support. It doesn't cover everything axios does but it's nice enough and I haven't had to touch it in a couple years. For reference: https://github.com/sampullman/fetch-api/blob/main/lib/fetchA...

I often do similar... though most of the time the past couple years, I'm generating the client from OpenAPI integration on the backend that uses fetch as its' base.

Re: OpenAI's response to the Axios developer tool compromise

#66

Post by anothereng »

PufPufPuf wrote: post #36
sdevonoes wrote: post #34

Using TS/JS in the backend is irresponsible in 2026. We have better languages and ecosystems

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

any ecosystem that doesnt encourage bunch of useless dependencies is better than one who does

Re: OpenAI's response to the Axios developer tool compromise

#68

Post by tmzt »

eranation wrote: post #57
tlb wrote: post #56

Earlier quoted context omitted.

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.

I chuckled, but in all seriousness, thankfully those individuals and companies who often discover these attacks listen in on every new npm push and analyze it relatively fast. The time to detect is sometimes in minutes in recent months, less than the process of getting npm to remove the packages. Not always but looking at recent ones and advances in latest SOTA models make detection easier than ever. It might change…

If that type of scanning works and discovers these attacks, why not make it part of the publishing process?
Post reply on HN