[dead]
OpenAI's response to the Axios developer tool compromise
41–50 of 68 posts
Re: OpenAI's response to the Axios developer tool compromise
#42Earlier quoted context omitted.
Forcing everyone to use ourFetch is rubbish, but forcing everyone to use axios is clean and elegant? You might want to elaborate just a little more.
ourFetch is more likely to be buggy, unmaintained, undocumented and nobody knows it well because the guy who wrote it left the org 2 years ago and so you have to waste time reading and maintaining it yourself. Axios is something where you get most of that work done for you by the community for free, and a lot of people know it. As long as you don’t get pwned due to it. Oh and you will actually find community packages…
> In this case it’s a relatively small dependency so it’s not the end of the world, but it’s the exact same principle.
An alternative world-view is: "A little copying is better than a little dependency," from https://go-proverbs.github.io
Does become subjective about what "small" and "little" are though.
Re: OpenAI's response to the Axios developer tool compromise
#43Earlier quoted context omitted.
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.
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.
Re: OpenAI's response to the Axios developer tool compromise
#44I’m a web dev, I never made publicly accessible desktop app, so please forgive my ignorance, but:
> At that time, a GitHub Actions workflow we use in the macOS app-signing process downloaded and executed a malicious version of Axios (version 1.14.1)
So if I understand this correctly their GH Actions is free to upgrade the package just like that? Is this normal practice or it’s just shifting blame?
Re: OpenAI's response to the Axios developer tool compromise
#45> Out of an abundance of caution we are taking steps to protect the process that certifies our macOS applications are legitimate OpenAI apps.
What did I just read?
Re: OpenAI's response to the Axios developer tool compromise
#46> Out of an abundance of caution we are taking steps to protect the process that certifies our macOS applications are legitimate OpenAI apps. What did I just read?
I'd assume they're retiring their old codesign certificates and rolling new ones, hopefully on a HSM or sth
Re: OpenAI's response to the Axios developer tool compromise
#47Whatever. If you are still using OpenAI products, shame on you.
Re: OpenAI's response to the Axios developer tool compromise
#48Earlier quoted context omitted.
ourFetch is more likely to be buggy, unmaintained, undocumented and nobody knows it well because the guy who wrote it left the org 2 years ago and so you have to waste time reading and maintaining it yourself. Axios is something where you get most of that work done for you by the community for free, and a lot of people know it. As long as you don’t get pwned due to it. Oh and you will actually find community packages…
> In this case it’s a relatively small dependency so it’s not the end of the world, but it’s the exact same principle. An alternative world-view is: "A little copying is better than a little dependency," from https://go-proverbs.github.io Does become subjective about what "small" and "little" are though.
I also agree with this!
I think the ideal model would be being able to depend on upstream code, but being able to review ALL of the actual code changes when pulling in new dependency versions (with a nice UI) and being able to vendor things and branch off with a single command whenever you need it, so you don't have to maintain it yourself by default but it's trivial when you want to.
It's actually surprising that in regards to front end development the whole shadcn approach hasn't gotten more popular. Or anywhere else for that matter, focusing on making code way more easy to maintain, to compile/deploy, with less complexity along the way.
Re: OpenAI's response to the Axios developer tool compromise
#49Earlier quoted context omitted.
ChatGPT in general recommends axios over fetch. (At least it did about 2 months ago)
This is why people still need to know how to write code and why it is asinine to have an LLM write code without a human reading it. Good developers should know what good code looks like and push back when what they're fed is wrong.
[deleted]
Re: OpenAI's response to the Axios developer tool compromise
#50I’m a web dev, I never made publicly accessible desktop app, so please forgive my ignorance, but: > At that time, a GitHub Actions workflow we use in the macOS app-signing process downloaded and executed a malicious version of Axios (version 1.14.1) So if I understand this correctly their GH Actions is free to upgrade the package just like that? Is this normal practice or it’s just shifting blame?
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.