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

61–70 of 120 posts

Re: Open source security at Astral

#61

Post by MeetingsBrowser »

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.

> It is effectively security theatre.

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.

Re: Open source security at Astral

#62

Post by woodruffw »

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

Re: Open source security at Astral

#63

Post by wofo »

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!

Re: Open source security at Astral

#64

Post by kaathewise »

woodruffw wrote: post #62
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’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.

Re: Open source security at Astral

#65

Post by MidnightRider39 »

fsflover wrote: post #58
MidnightRider39 wrote: post #56

Earlier quoted context omitted.

Seems like the most cynical take on OSS possible. Like anything good you do an evil person could benefit from - is the solution to never do any good?

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?

Re: Open source security at Astral

#66

Post by 3form »

MidnightRider39 wrote: post #65
fsflover wrote: post #58

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?

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.

Re: Open source security at Astral

#67

Post by abigail95 »

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, not by complaining louder.

Re: Open source security at Astral

#68

Post by everforward »

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!

I think any of the webhook-based providers are better, because you can isolate your secrets. PRs go to a PR webhook that runs in an environment that just doesn’t have access to any secrets.

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.

Post reply on HN