Live data from Hacker News

Open source security at Astral

astral.sh

81–90 of 120 posts

Re: Open source security at Astral

#81

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 bu…

I would agree with this. I recently tried to figure out how to properly secure agent-authored code in GitHub Actions. I believe I succeeded in doing this[1] but the secure configuration ended up being so delicate that I don’t have high hopes of this being a scalable path. 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…

Yeah, this is usually where things break in practice

Re: Open source security at Astral

#82
post #63

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 bu…

Out of curiosity, is there a build setup you have seen in the past that you think could be a good replacement for this complex GitHub CI setup? Asking for a friend ;) 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!

The complexity comes from how the whole system is designed.

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.

Re: Open source security at Astral

#83
post #66

Earlier quoted context omitted.

I’m maybe daft but AGPLv3 doesnt prevent $Evilcorp from using it, they just need to share any modifications or forks they made?

Only if they provide the software or software as a service. Then I suspect it's good enough if the modifications or forks made are shared internally if software is used only internally, but on the other hand I'm not a lawyer.

> if software is used only internally

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.

Re: Open source security at Astral

#84
post #83
post #66

Earlier quoted context omitted.

Only if they provide the software or software as a service. Then I suspect it's good enough if the modifications or forks made are shared internally if software is used only internally, but on the other hand I'm not a lawyer.

> if software is used only internally 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.

Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.

Re: Open source security at Astral

#85

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?

> what if Github is compromised/buggy 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.

I deliberately didn't mention this because I think most of the pain with Github over the last year is probably caused to some degree by their scale, which seems like an unrelated issue. (But maybe not.)

Re: Open source security at Astral

#86

Earlier quoted context omitted.

The solution is to use AGPLv3.

I’m maybe daft but AGPLv3 doesnt prevent $Evilcorp from using it, they just need to share any modifications or forks they made?

And at this point, it appears running code through an LLM to translate it eliminates copyright (and thus the licence), so $Anycorp can use it.

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.

Re: Open source security at Astral

#87
post #84
post #83

Earlier quoted context omitted.

> if software is used only internally 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.

Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.

Oh, I guess it would. Ignore me.

Re: Open source security at Astral

#88
post #28

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 indi…

(I’m the author of TFA.) > 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…

You definitely trust the same web of trust key graph already in every single layer of your current CI solution. Everything at Astral and by all indications also OpenAI is built with third party services, third party (blind) signing, using third party binaries signed by those 5000 keys directly or indirectly.

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.

Re: Open source security at Astral

#89
post #88

Earlier quoted context omitted.

(I’m the author of TFA.) > 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…

You definitely trust the same web of trust key graph already in every single layer of your current CI solution. Everything at Astral and by all indications also OpenAI is built with third party services, third party (blind) signing, using third party binaries signed by those 5000 keys directly or indirectly. That web of trust is the trust foundation of the entire internet and likely every server that powers Github, A…

> You definitely trust the same web of trust key graph already in every single layer of your current CI solution. Everything at Astral and by all indications also OpenAI is built with third party services, third party (blind) signing, using third party binaries signed by those 5000 keys directly or indirectly.

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

Re: Open source security at Astral

#90
post #63

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 bu…

Out of curiosity, is there a build setup you have seen in the past that you think could be a good replacement for this complex GitHub CI setup? Asking for a friend ;) 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!

Yes, this problem space has inherent complexity, but no, this inherent complexity does not require Github's insanely insecure defaults and incoherent security model.

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.

Post reply on HN