alt Hacker NewsOpen Source Security at Astral
Comments
The only binaries of uv in the world you can get that were full source bootstrapped from signed package commits to signed reviews to multi-signed deterministic artifacts are the ones from my teammates and I at stagex.
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.
FYI it was actually William Woodruff (the article author) and his team at Trail of Bits that worked with PyPI to implement Trusted Publishing.
One (amongst other) big problem with current software supply chain is that a lot of tools and dependencies are downloaded (eg from GitHub releases) without any validation that it was published by the expected author. That's why I'm working on an open source, auditable, accountless, self hostable, multi sig file authentication solution. The multi sig approach can protect against axios-like breaches. If this is of interest to you, take a look at https://asfaload.com/
The open source ecosystem has come very far and proven to be resilient. And while trust will remain a crucial part of any ecosystem, we urgently need to improve our tools and practices when it comes to sandboxing 3rd party code.
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.
Super useful info... but I feel so tired after reading it
If anyone from Astral sees this: at this level of effort, how do you deal with the enormous dependence on Github itself? You maintain social connections with upstream, and with PyPA... what if Github is compromised/buggy and changes the effect of some setting you depend on?
Pinning github actions by commit SHA does not solve the supply chain problem if the pinned action itself is pulling in other dependencies which themselves could be compromised. An action can pull in a docker image as a dependency for example. It is effectively security theatre. The real fix is owning the code that runs in your CI pipelines. Or fork the action itself and maintain it as part of your infrastructure.
The entire paragraph about version pinning using hashes (and using a map lookup for in-workflow binary deps) reminds me that software engineers are forever doomed to reinvent worse versions of nixpkgs and flakes.
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.
With the recent incidents affecting Trivy and litellm, I find it extremely useful to have a guide on what to do to secure your release process.
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.
This is a really great overview; what a useful resource for other open-source projects.
Lengths people will go to rediscover Nix/Guix is beyond me
Earlier submission from author: https://news.ycombinator.com/item?id=47691466
[dead]
[dead]
[dead]
[dead]
Created an agent skill based on this blog. Assessing my own repos now.
I don't have much experience with GitHub's CI offering. But if this is an accurate description of the steps you need to take to use it securely ... then I don't think it can, in fact, ever be used securely.
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.