Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open source security at Astral

astral.sh

Post reply on HN
Print view View original

91–100 of 120 posts

Re: Open source security at Astral

#91

Post by RyanSquared »

kaathewise wrote: post #64
woodruffw wrote: post #62

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…

StageX does reproducible builds, so they are signed independently and can also be verified locally. I don't think it applies to Astral, but it's useful for packages with a single maintainer or a vulnerable CI, where there is only one point of failure. 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.

Once we have better support for multiarch in stagex, since StageX is distributed as OCI images, you could just replace your existing Dockerfile bases with stagex.

Re: Open source security at Astral

#92

Post by lrvick »

abigail95 wrote: post #67
lrvick wrote: 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 don't think you are annoyed. You have done this to produce a reproducible linux distribution which your partners sell support for. 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,…

Sure, individual maintainers offer general purpose consulting services, but if we all did that for the next 20 years to keep the lights on we will never make a tiny fraction of the money we could have made by paywalling the binary artifacts like Chainguard and others do.

Stagex is and will forever be a community owned project.

Re: Open source security at Astral

#93

Post by RyanSquared »

pabs3 wrote: post #71
lrvick wrote: post #43

Earlier quoted context omitted.

I promise we are actively working on a much better solution we hope any distro can use, but... for now we just enforce signed merge commits by a different maintainer other than the author as something they only do for code they personally reviewed.

Are you looking at crev at all? https://github.com/crev-dev/

crev is on the StageX team's radar, and is rather close to ideal, but falls short in some aspects I don't recall at this point.

Re: Open source security at Astral

#94

Post by lrvick »

pabs3 wrote: post #71
lrvick wrote: post #43

Earlier quoted context omitted.

I promise we are actively working on a much better solution we hope any distro can use, but... for now we just enforce signed merge commits by a different maintainer other than the author as something they only do for code they personally reviewed.

Are you looking at crev at all? https://github.com/crev-dev/

The biggest problem with crev is it is (last I checked) entirely centralized on git/github making it not all that useful for early supply chain dependencies that often just live on random tar files on servers, or svn, or cvs, or mercurial. Crev also lacks support for public identity bound keys which would make us give up the highly valuable 25+ year web of trust we have built in identity bound keys that predate AI and cannot be easily impersonated.

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.

Re: Open source security at Astral

#95

Post by lrvick »

woodruffw wrote: post #89
lrvick wrote: post #88

Earlier quoted context omitted.

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

You can call it dead, and yet, it is the only system signing internet infrastructure at scale right now because of Debian, Suse, Fedora, Arch, Gentoo, Ubuntu, Redhat, etc. It is very much alive for those use cases that need it most. If one of those keys was compromised or the people that hold them, most of the internet is backdoored. Except for things built on stagex, in which case you would have to compromise several. Still not good enough, but better.

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.

Re: Open source security at Astral

#96

Post by pojzon »

12_throw_away wrote: post #34

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…

This is no different from any package registry getting some packages compromised.

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.

Re: Open source security at Astral

#97

Post by woodruffw »

lrvick wrote: post #95
woodruffw wrote: post #89

Earlier quoted context omitted.

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

You can call it dead, and yet, it is the only system signing internet infrastructure at scale right now because of Debian, Suse, Fedora, Arch, Gentoo, Ubuntu, Redhat, etc. It is very much alive for those use cases that need it most. If one of those keys was compromised or the people that hold them, most of the internet is backdoored. Except for things built on stagex, in which case you would have to compromise severa…

No, I call it dead because it's dead. The SKS network is dead, the strong set is moribund, and the remaining real users of PGP are instead slinging key bundles around by baking them into pre-trusted artifacts (like ISOs). But that's not a "web of trust," it's just bespoke centralized key distribution with a certification format that every single serious cryptographer agrees is terrible.

(And this is before a more brute statistical argument: even at its greatest extent, the PGP ecosystem was minuscule[1].)

[1]: https://moxie.org/2015/02/24/gpg-and-me.html

Re: Open source security at Astral

#98

Post by pojzon »

zanie wrote: post #54
s_ting765 wrote: post #47

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.

We do address this in the article! It's defense in depth, not theater. 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)

Do you fork them and have a team maintaining forks ?

If not you cant be sure of anything. Its just a security theater.

Re: Open source security at Astral

#99

Post by lrvick »

pojzon wrote: post #96
12_throw_away wrote: post #34

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…

This is no different from any package registry getting some packages compromised. 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 se…

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

Re: Open source security at Astral

#100

Post by lrvick »

wofo wrote: post #63
12_throw_away wrote: post #34

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!

If you have deterministic full source bootstrapped builds, it gets pretty simple and all of the third party trust can go away.

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.

Post reply on HN