Open source security at Astral
astral.sh
astral.sh
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.
Update: now I've finished reading the article, my impression is that complexity is mostly inherent to this problem space. I'd be glad to be proven wrong, though!
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.
You build it, I build it, we get the same hash. It allows anyone to prove a published binary is a faithful compilation of given input source code.
Now, as other commenter pointed out, maybe this is just inherent complexity in this space. But more secure defaults could go a long way making this more secure in practice.
Not many of them allow for immutable relases. And if they do, nothing blocks you from releasing a patch version that will most likely be automatically pulled in by many many projects during build.
The whole dependencies ecosystem is currently broken. Thats why its so easy (relatively) to attack via supply-chain.
Only way to be really secured is to have own registry of vetted dependencies pinned to exact version and maintain own upgrade pipeline.
NOONE (beside google) is going to do that. Its too costly, you need two big teams just to handle that one part.
And yet my team and I at stagex are building a decentralized code review system to handle this anyway. Not waiting around with our fingers crossed for the corpos to solve supply chain security for us. Has to be a community led effort.
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.
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?
Like anything good you do an evil person could benefit from - is the solution to never do any good?
Internal users are still users tho. They are entitled to see source code and license allows them to share it with the rest if of the world.
Our stuff is AGPL3 licenced and if this present trend continues we might just switch to MIT so at least the little guys can take advantage of it the way the big guys can.
Also they are even getting quite good at reverse engineering binaries.
Anything not released as FOSS, will have a FOSS copy made.
There is no moat and the reign of restrictive licenses on software is effectively over.
To my non-lawyer eyes it looks like MIT or Apache2 but modifications need to be made public as well.
If you don’t make any modifications then it should be fine? Or do most $Evilcorp aim to make modifications? Or is AGPLv3 something like garlic against vampires (doesn’t make sense but seems to work)?
So basically they are worried that they have no way of avoiding one or more of their tens of thousands of engineers “distributing” it to customers by including it in some sort of publicly accessible service. AFAIK there’s no settled case regarding what level of network communication qualifies - like if I run a CRUD app on Postgres and Postgres was AGPL, am I distributing Postgres?
Now the second part is that you only have to give out your changes to the AGPL software to those that it was “distributed” to. Most people aren’t changing it! If anything they’re just running a control plane in front of it…
but it goes back to the corporate legal perspective of “better safe than sorry” - we can’t guarantee that one of our engineers, isn’t changing it in some way that would expose company internals, then triggering a condition where they have to distribute those private changes publicly.
Also they don't sign commits or reviews themselves because they think crev eliminates the need for such things, which I consider ridiculous.
I really like dpc and worked next to him when he was designing crev and tried to explain these exact problems, but in the end he wanted to ship something that only solved the limited set of problems he cared about at the time which was blessing rust packages on github, which he is of course entitled to do.
We will still certainly cite crev and we are incorporating some of what we feel are the good ideas such as the actual general shape of the reviews, confidence, etc.
Points taken on the rest of what you mentioned, might be worth evolving crev rather than starting from scratch though.
e.g for curl it would look something like this: (wip) https://codeberg.org/stagex/sources/src/branch/main/curl.jso...
Once we have finished compiling that database of swhids for at least the sources live-bootstrap and stagex rely on, we then are all set for anyone to publish a signed review in basically any format they want bound to that swhid.
We will likely have our own PGP signed review tools that are a superset of the review fields of crev and validate web of trust etc, however nothing at all would stop people from publishing crev reviews signed with software exposed ssh keys or w/e as well which are still of much more value than nothing.
Anyone would be free to host their own signature servers as well with signed reproducible build proofs or code reviews.
Naturally spam will be a thing in a distributed system, so we would likely choose to only mirror and make discoverable signatures from an extended web of trust of linux distro maintainers, security researchers, etc, but anyone could publish subsets of signatures on their own servers under their own criteria. E.g every distro could host their own but if the stagex team has not reviewed a source yet but Debian has on their mirrors we will still assign limited trust to it.
Anyway that is the 50 floor elevator pitch. Absolutely looking to collaborate with anyone interested.
Using SWHID seems like a good choice, although maybe something not based on SHA-1 would be a good idea, hopefully SWHID v2 will do this.
The entire bootstrap process is a huge amount of code for a single person to review, so presumably individual people will review smaller subsets of the code and sign different subset SWHIDs instead of the main one?
Outside of old-school FOSS folks, OpenPGP is dead and even toxic waste. So StageX folks might want to also publish alternative reviews with other cryptography based on what is popular amongst modern devs; IIRC OpenSSH keys, age and so on. So different sets of folks can trust differently-signed reviews. Or figure out a how to make the crypto stuff be interoperable between cryptosystems (like the Monkeysphere folks were doing for OpenPGP and the web PKI). I'm thinking a starting point would be to make the reviews unsigned and then add multiple detached signature types alongside the reviews.
I feel like conflating OpenPGP web of trust and source code review trust would be a mistake; you can trust me to sign OpenPGP keys relatively well, but you definitely should not trust me to review machine code, assembly or Haskell and I feel like my reviews of POSIX shell would be trustworthy to some, but definitely not everyone.
SWH will never contain all source code, because forge admins keep objecting to having their code archived, and there are hundreds of different unsupported forge types and many different unsupported code sources (VCS/etc) types. Hopefully that won't be an issue for your bootstrap processes, but you may want to consider it in your design anyway. As an example; the canonical SQLite repository is in Fossil, which is an unsupported VCS (but of course there are tarball exports). Or codeberg.org archiving has problems due to rate limiting, so the latest versions of some repos might not be archived.
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.
My point is that at least from the standpoint of "Why does this process exist in the way it does?", OpenAI is not their "new name" in any logical sense. If you aren't happy with the process used a year from now, it would be reasonable in my opinion to criticize OpenAI for not making it different somehow. I'd argue that a parent company trying to make substantive process changes in such a short window would be strictly a bad thing though, because it would mean they didn't take the time to fully understand the context of what it's trying to solve and why it's the way it is currently.
I don't really disagree with anything else you're saying about OpenAI here, but I still think it's somewhat disingenuous to name-check them in this context.
To be frank. Because more effort doesn't actually mean that something is more secure. Just because you check extra things or take extra steps that doesn't mean it actually results in tangibly better security.
The blog is mostly focused on hardening the CI/CD pipeline.
> All keys on geodistributed smartcards held by maintainers tied to a web of trust going back 25 years with over 5000 keys.
Neither the age nor the cardinality of the key graph tells me anything if I don’t trust the maintainers themselves; given that you’re fundamentally providing third-party builds, what’s the threat model you’re addressing?
It’s worth nothing that all builds of uv come from a locked resolution and, as mentioned in TFA, you can get signed artifacts from us. So I’m very murky on the value of signed package commits that come from a different set of identities than the ones actually building the software.
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.
I don't think we do; there are places we trust distribution signers, but we don't do so in a "web" topology; we trust them because a small set of keys is pre-baked into VMs, Docker images, etc. The web of trust, as it existed 20 years ago, is dead[1].
Topologically this is a lot like a CA ecosystem, except worse in material ways: even distros (full of talented, motivated people!) struggle to operationalize PGP, so we end up with a bunch of de facto unexpirable and irrevocable keys[2] that nobody is really tracking. Consequently, nobody is really factoring these into their security story, whether or not they're a web.
[1]: https://inversegravity.net/2019/web-of-trust-dead/
[2]: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
PGP Web of Trust for all its faults and early design facepalms (of which there are many) is the only proof-of-human system where humans meet humans and sign each others keys that we ever built before AI. No one can reasonably expect any recently created keys were not created by made up LLM identities unless signed into the web of trust by well published existing keys held by well known and trusted humans.
But even if you don't want to look at the Web of Trust you can prove the key I sign stagex releases with is mine via all sorts of other ways thanks to keyoxide: https://keyoxide.org/E90A401336C8AAA9
Also PGP specs supports modern crypto now, attestation via dns, and even hackernews. You can attest my PGP key is tied to my HN profile right now. I would agree -gpg- is dead, with no real reason to use it anymore now that we have modern rust tooling with modern crypto.
But! If someone wants to generate an ssh key on a smartcard or something and sign with that instead, we would absolutely consider it. Not married to supporting only a single spec, but we absolutely need human beings to hold their own private keys on smartcards which are themselves attested by other human held private keys and the online services shared by the same identities.
(And this is before a more brute statistical argument: even at its greatest extent, the PGP ecosystem was minuscule[1].)
But regardless of tooling, it is about the keys and who holds them and who they endorse. It does not really matter how keys are distributed. It matters that keys signed other keys and that we have a way of downloading them and verifying that.
We cache a copy of all 5444 keys in the web of trust of stagex maintainers in our keys repo and you can draw a line from our keys to the keys that signed commits to the linux kernel today. These also sync and update from a dozen SKS keyservers that are still online for anyone that wants to build a key directory as we did.
Though SKS is being rapidly replaced with WKD where every domain hosts their own keys and they are automatically discovered.
Are you really going to say this has no trust or security value?
We should all just stop and let Github sign everything for us even though they don't full source bootstrap anything or sign commits or use deterministic builds?
What is the outcome you are actually arguing for here.
I think it matters if you want to call it a WoT. But also, I don't think any signatures originating from these keys are being verified usefully at any meaningful scale.
> Are you really going to say this has no trust or security value?
I think it has marginal security value, maybe net-negative if you balance it with the fact that cryptographers and cryptographic engineers have to waste time arguing against using PGP.
> What is the outcome you are actually arguing for here.
I like binary transparency. I also think identity-based signing is significantly more ergonomic, and has seen more adoption in the last 4 years than PGP has in the last 35. And I think this is actually a stunning indictment, because I'd say that identity-based signing schemes like Sigstore are still running behind my expectations.
Web of trust is a web of mutually trusting keys, not a network of servers. That web can be verified on any computer as in the blog post by kron I linked earlier, and it is verified for every package install in our soon-to-be published sxctl tool we will be presenting at some conferences next month.
> I think it has marginal security value, maybe net-negative if you balance it with the fact that cryptographers and cryptographic engineers have to waste time arguing against using PGP.
So again, are you really saying all the maintainers of most services running the internet should stop using the only IETF standard built for human-identity-bound signing with keys held by those humans?
The alternative everyone seems to be suggesting with a straight face is login with github or google and let them sign for you with "keyless signing"? That is the only alternative that is gaining adoption, and it is a ridiculous downgrade. I consider it mostly security theater.
The whole point of humans holding their own signing keys locally is to be able to make it not matter if your centralized online accounts are taken over. Something that is usually easy to do because no one uses hardware 2FA or renews their personal email domains.
But, if they did use hardware 2FA, hey look they have a local signing key... why not just... sign the binaries with that hardware directly instead of using that to login and let someone else sign for you. And then if you are going to do that, you don't want to be impersonated, so why not publish those public keys, and have other maintainers sign them. And now we have re-invented the web of trust.
I wouldn't find this annoying at all - I would expect to have to do this for hundreds of packages.
Without unpaid volunteers things like Debian do not exist. Don't malign the situation and circumstances of other projects, especially if they are your competitors.
Compete by being better, not by complaining louder.
Stagex is and will forever be a community owned project.
OpenClaw has been an outstanding success, it is providing people the ability to leak their keys, secrets, and personal data, and allowing people to be subject to an incredible number of supply chain attacks when its users have felt their attack surface was just too low.
Your efforts have been on increasing security and reducing supply chain attacks, when the market is strongly signaling to you that people want reduced security and more supply chain attacks!
What if? GitHub has is extremely buggy! I'm getting increasingly frustrated with the paper cuts that have become endemic across the entire platform. For example its not uncommon for one of our workflows to fail when cloning a branches of the repo they are running in.
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 :)
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
To be clear though, we only use uv in the builder stage of our docker builds, there is no uv in the final image.
[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.
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 !
SPOF. I'd suggest use automatic tools to audit every line of code no matter who the author is.
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.
We audit all of our actions, check if they pull in mutable dependencies, contribute upstream fixes, and migrate off using any action when we can.
(I work at Astral)
If not you cant be sure of anything. Its just a security theater.
I disagree. Security is always a trade-off.
Owning, auditing, and maintaining your entire supply chain stack is more secure than pinning hashes, but it is not practical for most projects.
Pinning your hashes is more secure than not pinning, and is close to free.
At the end of the day, the line of trust is drawn somewhere (do you audit the actions provided by GitHub?). It is not possible to write and release software without trusting some third party at some stage.
The important part is recognizing where your "points of trust" are, and making a conscious decision about what is worth doing yourself.
But thanks to the article I added a new check for the fork PR workflow approval policy.
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.
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 :-)