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

51–60 of 120 posts

Re: Open source security at Astral

#51

Post by tclancy »

nDRDY wrote: post #36
Zopieux wrote: post #32

The entire paragraph about version pinning using hashes (and using a map lookup for in-workflow binary deps) reminds me that software engineers are forever doomed to reinvent worse versions of nixpkgs and flakes. 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 p…

>worse versions of nixpkgs and flakes You mean statically-compiled binaries and hash pinning? Those have been around a bit longer than Nix :-)

Every generation thinks they invented sex. And hash pinning, which now sounds dirty.

Re: Open source security at Astral

#52

Post by s_ting765 »

codethief wrote: post #48
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.

Shouldn't you always read & double-check the 3rd-party GitHub actions you use, anyway? (Forking or copying their code alone doesn't solve the issue you mention any more than pinning a SHA does.)

Double checking Github actions does not mitigate threats from supply chain vulnerabilities. Forking an action moves the trust from a random developer to yourself. You still have to make sure the action is pulling in dependencies from trusted sources which can also be yourself depending on how far you want to go.

Re: Open source security at Astral

#54

Post by zanie »

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)

Re: Open source security at Astral

#55

Post by charcircuit »

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…

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI.

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.

Re: Open source security at Astral

#56

Post by MidnightRider39 »

hootz wrote: post #39
duskdozer wrote: post #35

Earlier quoted context omitted.

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI. 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?

Yep. Permissive licenses, "open source", it's all just free work for the worst corporations you can think.

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?

Re: Open source security at Astral

#57

Post by bognition »

carderne wrote: post #21

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.

Re: Open source security at Astral

#58

Post by fsflover »

MidnightRider39 wrote: post #56
hootz wrote: post #39

Earlier quoted context omitted.

Yep. Permissive licenses, "open source", it's all just free work for the worst corporations you can think.

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.

Re: Open source security at Astral

#59

Post by MeetingsBrowser »

charcircuit wrote: post #55
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…

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI. 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.

Exactly. Deterministic artifacts alone are not necessarily more secure and are tangential to a lot of what is being described in the blog post.

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

Post reply on HN