Live data from Hacker News

Open source security at Astral

astral.sh

111–120 of 120 posts

Re: Open source security at Astral

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

Nix is a nightmare and so it usually gets paired with Rust for people who have a complexity fetish.

Re: Open source security at Astral

#112
post #94
post #71

Earlier quoted context omitted.

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

There are definitely crev reviews hosted outside GitHub, for eg https://git.alpaga.dev/koalp/crev-proofs/

Points taken on the rest of what you mentioned, might be worth evolving crev rather than starting from scratch though.

Re: Open source security at Astral

#114
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 stro…

The breaches will continue until morale improves.

Re: Open source security at Astral

#115

Earlier quoted context omitted.

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.

I think the whitewashing of code through LLMs is still unproven if it actually works for a reasonably complex project and also it’s still kind of legal Wild West - I think no one knows for sure how it will work out.

There are piles of examples of it working for complex projects and libraries now especially if they have good test suites your clone can pass.

Also they are even getting quite good at reverse engineering binaries.

Anything not released as FOSS, will have a FOSS copy made.

There is no moat and the reign of restrictive licenses on software is effectively over.

Re: Open source security at Astral

#116
post #112
post #94

Earlier quoted context omitted.

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

There are definitely crev reviews hosted outside GitHub, for eg https://git.alpaga.dev/koalp/crev-proofs/ Points taken on the rest of what you mentioned, might be worth evolving crev rather than starting from scratch though.

We are seeking a design that works across every VCS, mirror, or vendored copy of code by generating a universally stable SWHID across all distribution methods of a given version of software source code. The goal being you can just request software by the swhid or version and a copy on the internet will be discovered and a normalized folder of extracted code that matches the SWHID will appear, regardless of git, cvs, svn, tar, tar.gz, and even from slightly different mirrors as long as it is a superset of expected files, etc. All resolve to a single SWHID.

e.g for curl it would look something like this: (wip) https://codeberg.org/stagex/sources/src/branch/main/curl.jso...

Once we have finished compiling that database of swhids for at least the sources live-bootstrap and stagex rely on, we then are all set for anyone to publish a signed review in basically any format they want bound to that swhid.

We will likely have our own PGP signed review tools that are a superset of the review fields of crev and validate web of trust etc, however nothing at all would stop people from publishing crev reviews signed with software exposed ssh keys or w/e as well which are still of much more value than nothing.

Anyone would be free to host their own signature servers as well with signed reproducible build proofs or code reviews.

Naturally spam will be a thing in a distributed system, so we would likely choose to only mirror and make discoverable signatures from an extended web of trust of linux distro maintainers, security researchers, etc, but anyone could publish subsets of signatures on their own servers under their own criteria. E.g every distro could host their own but if the stagex team has not reviewed a source yet but Debian has on their mirrors we will still assign limited trust to it.

Anyway that is the 50 floor elevator pitch. Absolutely looking to collaborate with anyone interested.

Re: Open source security at Astral

#117
post #115

Earlier quoted context omitted.

I think the whitewashing of code through LLMs is still unproven if it actually works for a reasonably complex project and also it’s still kind of legal Wild West - I think no one knows for sure how it will work out.

There are piles of examples of it working for complex projects and libraries now especially if they have good test suites your clone can pass. Also they are even getting quite good at reverse engineering binaries. Anything not released as FOSS, will have a FOSS copy made. There is no moat and the reign of restrictive licenses on software is effectively over.

Can you share any of these examples? I haven’t been able to find any…

Re: Open source security at Astral

#118

Earlier quoted context omitted.

I often hear this but I don’t really understand it. Not saying you need to explain it to me but what is the issue with AGPLv3 that turns those corporations away? To my non-lawyer eyes it looks like MIT or Apache2 but modifications need to be made public as well. If you don’t make any modifications then it should be fine? Or do most $Evilcorp aim to make modifications? Or is AGPLv3 something like garlic against vampir…

AGPLv3 includes that “distribution” includes essentially communicating with the service over the network, as opposed to the GPL concept of like, sending a shrink wrapped binary that someone downloads and runs themselves. So basically they are worried that they have no way of avoiding one or more of their tens of thousands of engineers “distributing” it to customers by including it in some sort of publicly accessible…

Oh I see that makes sense, thanks for the explanation!

Re: Open source security at Astral

#119
post #102
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…

I was just calling them by their new name, but yes clearly I am not the biggest fan of OpenAI and me invoking their name so soon betrays that. Sam altmans vision for handling the "proof of human" problem WoT solves is having everyone scan their eyes into magic orbs you can't audit at runtime and letting them sign stuff for us. Cool. I will take WoT over that every time.

> I was just calling them by their new name, but yes clearly I am not the biggest fan of OpenAI and me invoking their name so soon betrays that.

My point is that at least from the standpoint of "Why does this process exist in the way it does?", OpenAI is not their "new name" in any logical sense. If you aren't happy with the process used a year from now, it would be reasonable in my opinion to criticize OpenAI for not making it different somehow. I'd argue that a parent company trying to make substantive process changes in such a short window would be strictly a bad thing though, because it would mean they didn't take the time to fully understand the context of what it's trying to solve and why it's the way it is currently.

I don't really disagree with anything else you're saying about OpenAI here, but I still think it's somewhat disingenuous to name-check them in this context.

Re: Open source security at Astral

#120
post #116
post #112

Earlier quoted context omitted.

There are definitely crev reviews hosted outside GitHub, for eg https://git.alpaga.dev/koalp/crev-proofs/ Points taken on the rest of what you mentioned, might be worth evolving crev rather than starting from scratch though.

We are seeking a design that works across every VCS, mirror, or vendored copy of code by generating a universally stable SWHID across all distribution methods of a given version of software source code. The goal being you can just request software by the swhid or version and a copy on the internet will be discovered and a normalized folder of extracted code that matches the SWHID will appear, regardless of git, cvs,…

Sounds interesting, some thoughts:

Using SWHID seems like a good choice, although maybe something not based on SHA-1 would be a good idea, hopefully SWHID v2 will do this.

The entire bootstrap process is a huge amount of code for a single person to review, so presumably individual people will review smaller subsets of the code and sign different subset SWHIDs instead of the main one?

Outside of old-school FOSS folks, OpenPGP is dead and even toxic waste. So StageX folks might want to also publish alternative reviews with other cryptography based on what is popular amongst modern devs; IIRC OpenSSH keys, age and so on. So different sets of folks can trust differently-signed reviews. Or figure out a how to make the crypto stuff be interoperable between cryptosystems (like the Monkeysphere folks were doing for OpenPGP and the web PKI). I'm thinking a starting point would be to make the reviews unsigned and then add multiple detached signature types alongside the reviews.

I feel like conflating OpenPGP web of trust and source code review trust would be a mistake; you can trust me to sign OpenPGP keys relatively well, but you definitely should not trust me to review machine code, assembly or Haskell and I feel like my reviews of POSIX shell would be trustworthy to some, but definitely not everyone.

SWH will never contain all source code, because forge admins keep objecting to having their code archived, and there are hundreds of different unsupported forge types and many different unsupported code sources (VCS/etc) types. Hopefully that won't be an issue for your bootstrap processes, but you may want to consider it in your design anyway. As an example; the canonical SQLite repository is in Fossil, which is an unsupported VCS (but of course there are tarball exports). Or codeberg.org archiving has problems due to rate limiting, so the latest versions of some repos might not be archived.

Post reply on HN