- 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.

1:https://docs.sigstore.dev/about/security/

2: https://docs.sigstore.dev/cosign/verifying/verify/

All the axios releases had attestations except for the compromised one. npm installed it anyway.

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 !

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.

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.

ps. I feel like I've been doing python so long that my workflows have routed around a lot of legit problems :)

The blog is mostly focused on hardening the CI/CD pipeline.

But I also think it'd be nice if projects provided a first-party StageX build, like many do with a Dockerfile or a Nix flake.

That web of trust is the trust foundation of the entire internet and likely every server that powers Github, Astral, and OpenAI including every CI system you described.

https://kron.fi/en/posts/stagex-web-of-trust/

One node in that graph is also nowhere near good enough to stop supply chain attacks, which is why we use -multiple- points thanks to full source bootstrapped deterministic builds.

Let me flip it and ask why anyone should trust that an Astral/OpenAI employee that does not sign their commits and does not sign their reviews, has not been impersonated or had an account takeover due to the phishable 2FA that is allowed, and won't just make a commit to CI stack for uv (or uv itself!) under a pseudonym then merge their pseudonym's code.

One person can burn it all down in spite of the practices in this blog post. Letting machines blindly sign whatever non-deterministic outputs come out of an automated process does not actually buy you much in practice against many of the supply chain attack tactics actually used in the wild. Also of course the same applies to the third party build systems you trust. Github themselves also don't use any of these basic supply chain security practices either so many many points of failure here.

Astral/OpenAI are actually giving -thousands- of randos other than the authors the ability to backdoor the uv binaries you produce, and without a reproducible full source bootstrapped build process, no one would be able to quickly or easily prove it.

To package or change uv in stagex one maintainer must sign the commit, and another must sign the review/merge commit. Then -multiple- maintainers must compile 180 bytes of human readable machine code, build up to tinycc, then gcc, then llvm, and eventually to a rust compiler, that we then use to build uv, all deterministically.

So, we actually don't trust any third parties other than the actual authors of the source code to a limited extent in our process. That said we are working on a solution for decentralized review of upstream code as well right now because we largely don't trust upstreams to not let their identities get stolen because most teams for whatever reason refuse to sign their commits and reviews, so we will have to do that for them too. Regardless, we can prove we faithfully deliver honest compilations of whatever upstream code is published without any single points of failure.

We ask users downloading binaries to trust that a bunch of maintainers are putting their personal reputations and keys (which long predate AI and are hard to impersonate) on the line to sign their bit for bit identical builds of uv, and the entire toolchain underneath it, and provide faithful compilations of upstream source code.

It would make everyone a lot safer if upstreams, especially well funded ones, could meet or exceed the threat model we must support downstream.

Stagex is and will forever be a community owned project.

Releases go to the release webhook, which should output nothing and ideally should be a separate machine/VM with firewall rules and DNS blocks that prevent traffic to anywhere not strictly required.

Things are a lot harder to secure with modern dynamic infrastructure, though. Makes me feel old, but things were simpler when you could say service X has IP Y and add firewall rules around it. Nowadays that service probably has 15 IP addresses that change once a week.

There’s no single repository or curated packages as is typical in any distribution: instead actions pull other actions, and they’re basically very complex wrapper around scripts which downloads binaries from all over the place.

For lots of very simple actions, instead of installing a distribution package and running a single command, a whole “action” is used which creates and entire layer of abstraction over that command.

It’s all massive complexity on top of huge abstractions, none of which were designed with security in mind: it was just gradually bolted on top over the years.

As a practical step, one could try using webhooks to integrate their github repo with literally any other CI provider. This would at least give you a single, low-coupling primitive to build your workflows on. It would not, in any way, eliminate the domain's inherent complexity (secrets, 3rd party contributions, trusted publishing, etc.), but it starts out safe because by default it doesn't do anything - it's just an HTTP call that gets fired under certain conditions.