Even if you trust Microsoft's cloud engineering on the backend, this is a system that does not appear to follow even the most basic principles of privilege and isolation? I'm not sure why you would even try to build "supply-chain security" on top of this.
All keys on geodistributed smartcards held by maintainers tied to a web of trust going back 25 years with over 5000 keys.
https://stagex.tools/packages/core/uv/
Though thankful for clients that let individual maintainers work on stagex part time once in a while, we have had one donation ever for $50 as a project. (thanks)
Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI.
I am annoyed.
Didn't the acquisition only happen a few weeks ago? Wouldn't it be more alarming if OpenAI had gone in and forced them to change their build process? Unless you're claiming that the article is lying about this being a description of what they've already been doing for a while (which seems a bit outlandish without more evidence), it's not clear to me why you're attributing this process to the parent company.
Don't get me wrong; there's plenty you can criticize OpenAI over, and I'm not taking a stance on your technical claims, but it seems somewhat disingenuous to phrase it like this.
Unpaid volunteer hackers provide their work for free under licenses designed for the purpose of allowing companies like OpenAI to use their work without paying or contributing in any form. OpenAI wants to make the most money. Why would they spend any time or money on something they can get for free?
[0] https://docs.github.com/en/actions/how-tos/secure-your-work/...
- Asfaload is accountless(keys are identity) while sigstore relies on openid connect[1], which will tie most user to a mega corp
- Asfaload ' backend is a public git, making it easily auditable
- Asfaload will be easy to self host, meaning you can easily deploy it internally
- Asfaload is multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected
- validating a download is transparant to the user, which only requires the download url, contrary to sigstore [2]
So Asfaload is not the only solution, but I think it has some unique characteristics that make it worth evaluating.
All the axios releases had attestations except for the compromised one. npm installed it anyway.
SPOF. I'd suggest use automatic tools to audit every line of code no matter who the author is.
There's also a spec of the approach at https://github.com/asfaload/spec
I'm looking for early testers, let me know if you are interested to test it !
Almost every time I bump into uv in project work, the touted benefit is that it makes it easier to run projects with different python versions and avoiding clashes of 3rd dependencies - basically pyenv + venv + speed.
That sends a cold shiver down my spine, because it tells me that people are running all these different tools on their host machine with zero sandboxing.
ps. I feel like I've been doing python so long that my workflows have routed around a lot of legit problems :)
To be clear though, we only use uv in the builder stage of our docker builds, there is no uv in the final image.
And that doesn't prevent me from running it into a sandbox or vm for an additional layer of security.
A PR to be able to use a relative timestamp in pip was merged just last week
I don't even love Nix, it's full of pitfalls and weirdnesses, but it provides so much by-default immutability and reproducibility that I sometimes forget how others need to rediscover this stuff from first principles every time a supply chain attack makes the news.
You mean statically-compiled binaries and hash pinning? Those have been around a bit longer than Nix :-)
The advices here are really solid and actionable, and I would suggest any team to read them, and implement them if possible.
The scary part with supply chain security is that we are only as secure as our dependencies, and if the platform you’re using has non secure defaults, the efforts to secure the full chain are that much higher.
Unfortunately, Nix is also not how most people function. You have to do things the Nix way, period. The value in part comes from this strong opinion, but it also makes it inherently niche. Most people do not want to learn an entire new language/paradigm just so they can get this feature. And so it becomes a chicken and egg problem. IMHO, I think it also suffers from a little bit of snobbery and poor naming (Nix vs. NixOS vs. Nixpkgs) which makes it that much harder to get traction.
https://reproducible.nixos.org
It is still good at that but the difference to other distros is rather small:
Unfortunately I have to agree with the sibling comment that it suffers from poor naming and the docs are very hard to grok which makes it harder to get traction.
I really hate the idea of `it's all sales at the end of the day` but if Nix could figure how to "sell" itself to more people then we would probably have less of those problems.