Live data from Hacker News

Open source security at Astral

astral.sh

71–80 of 120 posts

Re: Open source security at Astral

#71
post #43
post #41

Earlier quoted context omitted.

What are you using for signed reviews?

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/

Re: Open source security at Astral

#72
post #44
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. 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 outla…

Yeah, I'll just establish for the record that we've been thinking about this for a long time, and that it has nothing to do with anybody except our own interests in keeping our development and release processes secure.

Re: Open source security at Astral

#73

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?

We talk to GitHub as well! You're right that they are an enormous and critical dependency, and we pay close attention to the changes they make to their platform.

Re: Open source security at Astral

#76

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 more secure in practice.

[1] https://github.com/airutorg/sandbox-action

Re: Open source security at Astral

#77
post #44

Earlier quoted context omitted.

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

Yeah, I'll just establish for the record that we've been thinking about this for a long time, and that it has nothing to do with anybody except our own interests in keeping our development and release processes secure.

That fits what I had assumed (and would expect), but it definitely doesn't hurt to have that confirmed, so thank you!

Re: Open source security at Astral

#78
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…

This is the market telling you what matters.

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!

Re: Open source security at Astral

#79
I maintain `repomatic`, a Python CLI + reusable workflows. It bakes most of the practices from this post into a drop-in setup for Python projects (uv-based, but works for others too). The goal is to make the secure default the easy default for maintainers who just want to ship packages. Also addresses a lot of GitHub Actions own shortcomings.

But thanks to the article I added a new check for the fork PR workflow approval policy.

More at: https://github.com/kdeldycke/repomatic

Re: Open source security at Astral

#80

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?

This is the point. They can use and modify it, but they also have to share their modifications, i.e., help its development. Yet most megacorps never even touch this license.
Post reply on HN