OpenAI is growing fast, pivoting is only to be expected. It would normally be something HN folk would typically value and encourage on startups.
They have clearly been lacking focus and now finally they seem to be working towards a narrower direction, which is usually highly valued by investors.
This article doesn't explore the depth of the decisions and only regurgitate what you may find your neighbor complaining about on X but with a better stylesheet.
Of course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security scanners in the dependency world.
That's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?
Writing down specs for technical projects is a transformational skill.
I've had projects that seemed tedious or obvious in my head only to realize hidden complexity when trying to put their trivial-ness into written words. It really is a sort of meditation on the problem.
In the most important AI assisted project I've shipped so far I wrote the spec myself first entirely. But feeding it through an LLM feedback loop felt just as transformational, it didn't only help me get an easier to parse document, but helped me understand both the problem and my own solution from multiple angles and allowed me to address gaps early on.
So both this and litellm went straight to PyPI without going to GitHub first.
Is there any way to setup PyPI to only publish packages that come from a certain pattern of tag that exists in GH? Would such a measure help at all here?
Yes: if you use a Trusted Publisher with PyPI, you can constrain it to an environment. Then, on GitHub, you can configure that environment with a tag or branch protection rule that only allows the environment to be activated if the ref matches. You can also configure required approvers on the environment, to prevent anyone except your account (and potentially other maintainers you’d like) from activating the environment.
If they have compromised the token wouldn't that mean the developer is compromised and such access can be used to just put "curl whatever" into the build and publish that payload on pypi?
On debian, all builds happen without internet access. So whatever ends up on the .deb file is either contained on the dependencies or in the orig tarball.
Is anything similar done for builds that create artifacts for pypi, so that a certain correspondence between binary file and sources exists? Or is there unrestricted internet access so that what actually ends up on pypi can come from anywhere and vetting the sources is of little help?
That’s a nice property of centralized package management systems; I don’t think anything exactly like that exists for PyPI. The closest thing would be a cryptographic attestation.
(If I wanted to taxonomize these things, I say that the Debian model is effectively a pinky promise that the source artifacts correspond to the built product, except that it’s a better pinky promise because it’s one-to-many instead of many-to-many like language package managers generally are. You can then formalize that pinky promise with keys and signatures, but at the end of the day you’re still essentially binding a promise.)
Depends on what you mean by “this.” If you mean build provenance, yes, if you mean transmuting PyPI into the kind of trust topology that Debian (for example) has, no.
(I think PEP 740 largely succeeds at providing build provenance; having downstream tooling actually do useful things with that provenance is harder for mostly engineering coordination reasons.)
Don't have the token on your hands. Use OICD ideally, or make sure to setup carefully as a repository secret. Ensure the workflow runs in a well permission read, minimal dependency environment.
The issue with OICD is that it does not work with nested workflows because github does not propagate the claims.
They stacked the deck. If v2 was still rule inference + spatial reasoning, a bit like juiced up Raven's progressive matrices, then v3 adds a whole new multi-turn explore/exploit agentic dimension to it.
Given how hard even pure v2 was for modern LLMs, I'm not surprised to see v3 crush them. But that wouldn't last.
