5 ms·

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

• duskdozer 6mo ago
  >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?
  • ra 6mo ago
    Not sure if you're fully over the context that openAI bought Astral - who "own" uv.
  • hootz 6mo ago
    Yep. Permissive licenses, "open source", it's all just free work for the worst corporations you can think.
    • philipallstar 6mo ago
      It's free work for anyone.
    • tclancy 6mo ago
      Never let the left hand know what the right hand is doing. I suppose it works both ways here, but the specific end user is not why people make code available, it’s in the hope of improving things, even just the tiniest bit.
    • MidnightRider39 6mo ago
      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?
      • fsflover 6mo ago
        The solution is to use AGPLv3.
        • MidnightRider39 6mo ago
          I’m maybe daft but AGPLv3 doesnt prevent $Evilcorp from using it, they just need to share any modifications or forks they made?
          • 3form 6mo ago
            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.
            • 0x457 6mo ago
              > if software is used only internally Internal users are still users tho. They are entitled to see source code and license allows them to share it with the rest if of the world.
              • fweimer 6mo ago
                Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.
                • 0x457 6mo ago
                  Oh, I guess it would. Ignore me.
• pabs3 6mo ago
  What are you using for signed reviews?
  • lrvick 6mo ago
    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.
    • pabs3 6mo ago
      Are you looking at crev at all? https://github.com/crev-dev/ https://github.com/crev-dev/
      • RyanSquared 6mo ago
        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.
      • lrvick 6mo ago
        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.
• saghm 6mo ago
  > 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 outlandish without more evidence), it's not clear to me why you're attributing this process to the parent company. Don't get me wrong; there's plenty you can criticize OpenAI over, and I'm not taking a stance on your technical claims, but it seems somewhat disingenuous to phrase it like this.
  • woodruffw 6mo ago
    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.
    • saghm 6mo ago
      That fits what I had assumed (and would expect), but it definitely doesn't hurt to have that confirmed, so thank you!
  • lrvick 6mo ago
    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.
    • saghm 6mo ago
      > 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.
• blitzar 6mo ago
  The private jet wont fuel itself now will it.
• charcircuit 6mo ago
  >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.
  • MeetingsBrowser 6mo ago
    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.
• woodruffw 6mo ago
  (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.
  • kaathewise 6mo ago
    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.
    • RyanSquared 6mo ago
      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.
  • lrvick 6mo ago
    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, Astral, and OpenAI including every CI system you described. https://kron.fi/en/posts/stagex-web-of-trust/ https://kron.fi/en/posts/stagex-web-of-trust/ One node in that graph is also nowhere near good enough to stop supply chain attacks, which is why we use -multiple- points thanks to full source bootstrapped deterministic builds. Let me flip it and ask why anyone should trust that an Astral/OpenAI employee that does not sign their commits and does not sign their reviews, has not been impersonated or had an account takeover due to the phishable 2FA that is allowed, and won't just make a commit to CI stack for uv (or uv itself!) under a pseudonym then merge their pseudonym's code. One person can burn it all down in spite of the practices in this blog post. Letting machines blindly sign whatever non-deterministic outputs come out of an automated process does not actually buy you much in practice against many of the supply chain attack tactics actually used in the wild. Also of course the same applies to the third party build systems you trust. Github themselves also don't use any of these basic supply chain security practices either so many many points of failure here. Astral/OpenAI are actually giving -thousands- of randos other than the authors the ability to backdoor the uv binaries you produce, and without a reproducible full source bootstrapped build process, no one would be able to quickly or easily prove it. To package or change uv in stagex one maintainer must sign the commit, and another must sign the review/merge commit. Then -multiple- maintainers must compile 180 bytes of human readable machine code, build up to tinycc, then gcc, then llvm, and eventually to a rust compiler, that we then use to build uv, all deterministically. So, we actually don't trust any third parties other than the actual authors of the source code to a limited extent in our process. That said we are working on a solution for decentralized review of upstream code as well right now because we largely don't trust upstreams to not let their identities get stolen because most teams for whatever reason refuse to sign their commits and reviews, so we will have to do that for them too. Regardless, we can prove we faithfully deliver honest compilations of whatever upstream code is published without any single points of failure. We ask users downloading binaries to trust that a bunch of maintainers are putting their personal reputations and keys (which long predate AI and are hard to impersonate) on the line to sign their bit for bit identical builds of uv, and the entire toolchain underneath it, and provide faithful compilations of upstream source code. It would make everyone a lot safer if upstreams, especially well funded ones, could meet or exceed the threat model we must support downstream.
• abigail95 6mo ago
  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.
  • lrvick 6mo ago
    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.
• jmalicki 6mo ago
  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!
  • baobun 6mo ago
    The breaches will continue until morale improves.