OSS Rebuild: open-source, rebuilt to last
47 comments
·July 22, 2025lrvick
tomcam
Love this project; thanks for letting us know about it. I have been voted "Least likely to succeed in Web Hosting Security" by HN for 13 years in a row, so apologies if this is irrelevant. But being able to know precisely what software you're running would be a great way to run a web server, no? Or is it not efficient enough running in a container or what?
lrvick
That is why we made StageX, which allows you to generate bootable web server images or containers bit for bit identical every time so prod is predictable and accountable.
0cf8612b2e1e
This is a great idea. Less boil the ocean than getting everything into Nix. Are any notable projects using this?
lrvick
Not yet, although Turnkey and Stagex are in the process of integrating it for automated reproductions as part of their CI for everything.
It will no doubt mature a fair bit more through this process
WhatIsDukkha
So this seems like a bit of a half measure in the sense that it doesn't provide client side build?
With guix I can bit for bit reproduce with my client machine the upstream binaries.
This seems flawed to assume that google's servers are uncompromised, its vastly better to have distributed ability to reproduce.
https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
akdor1154
It does provide client side build, see the bottom shell snippets.
simonw
I'm very excited about this project, but it could really do with a web UI of some sort! Having to build a Go CLI tool in order to access it is a massive amount of friction.
I reverse-engineered it a tiny bit, looks like you can get a list of all builds so far like this:
gsutil ls -r 'gs://google-rebuild-attestations/**'
msuozzo
Author here!
> I'm very excited about this project
Thank you!
> but it could really do with a web UI of some sort!
Couldn't agree more! The terminal UI exists (`./tools/ctl tui`) but is oriented towards developers on the project or to those who wish to run their own instance. Making the system and data more accessible to general users is a big priority.
simonw
I got a basic web UI working here: https://storage.googleapis.com/rebuild-ui/index.html
It's using that fixed list from the Gist though, I haven't set it up to update and reflect new listed projects.
BrentBrewington
nice! bit of UI feedback: when I type "pypi/requests" into the search bar, I expected to see versions sorted descending, so newer ones show up higher
Flux159
So this seems to be a build definition and some form of attestation system? Does this require builds are done via CI systems instead of on adhoc developer machines?
I find that for many npm packages, I don't know how builds were actually published to the registry and for some projects that I rebuilt myself in docker, I got vastly different sizes of distribution artifacts.
Also, it seems like this is targeting pypi, npm, and crates at first - what about packages in linux distro repositories (debian, etc.)?
msuozzo
Author here!
> Does this require builds are done via CI
Nope! One use for OSS Rebuild would be providing maintainers that have idiosyncratic release processes with an option for providing strong build integrity assurances to their downstream users. This wouldn't force them into any particular workflow, just require their process be reproducible in a container.
> for some projects that I rebuilt myself in docker, I got vastly different sizes of distribution artifacts.
Absolutely. OSS Rebuild can serve to identify cases where there may be discrepancies (e.g. accidentally included test or development files) and publicize that information so end-users can confidently understand, reproduce, and customize their dependencies.
> what about packages in linux distro repositories (debian, etc.)
OSS Rebuild actually does have experimental support for Debian rebuilds, not to mention work towards JVM and Ruby support, although no attestations have been published yet. There is also no practical impediment to supporting additional ecosystems. The existing support is more reflective of the size of the current team rather than the scope of the project.
candiddevmike
The industry has been coalescing around third-party attestation for open source packages since COVID. The repercussions of this will be interesting to watch, but I don't see any benefits (monetary or otherwise) for the poor maintainers dealing with them.
There's probably a lot of people that see GenAI as the solution to Not Invented Here: just have it rewrite your third party dependencies! What could go wrong. There will also be some irony of this situation with third party dependencies being more audited/reviewed than the internal code they get integrated into.
Y_Y
I don't mind if the "third parties" are other trusted developers of the same project, for example. But please let's not centralise it. We're just going to get Robespierre again.
jpalomaki
Two fold: AI makes it easier to find "issues" in existing software and automate the CVE process. This means more "critical" vulnerabilities that require attention from developers using these packages.
At the same time rolling your own implementation with GenAI will be quick and easy. Outsiders are checking these, so no CVEs for these. Just sit back and relax.
Weethet
nixpkgs already has 107158 packaged libraries/executables. Nix has infrastructure to support arbitrary build systems and can create docker images. I fail to see any advantages of creating a more narrow version of it that has fewer uses and has to start from scratch
msuozzo
Author here!
Both nix and guix are exciting projects with a lot of enviable security properties. Many here can attest that using them feels like, and perhaps is, the future. I see OSS Rebuild as serving more immediate needs.
By rebuilding packages from the registries people already use, we can bring some of those security properties to users without them needing to change the way they get their software.
kam
Nixpkgs pulls source code from places like pypi and crates.io, so verifying the integrity of those packages does help the Nix ecosystem along with everyone else.
Y_Y
Why not help them help bring their packages to users, rather than borrowing and circumventing the existing effort?
null
hollerith
The Nix community has a poor record on security and supply-chain integrity in particular [1] whereas Google has a great record on security, and this announcement (of OSS Rebuild) was written by a member of the "Google Open Source Security Team".
[1]: "it means effectively a decision was made for NixOS to be a hobby distro not suitable for any targeted applications or individuals. It really sucks, because I love everything else about nix design. Instead I am forced to bootstrap high security applications using arch and debian toolchains which are worse than nix in every way but supply chain integrity given that all authors directly sign package sources with their personal well verified keys."
arianvanp
They could've contributed SLSA attestations support to nix instead. There's a few people working on bringing SLSA build provenance to nix(pkgs) including me. But limited time and resources unfortunately. Would love to see Google contribute to nix in this space :)
E.g.:
msuozzo
Author here!
> could've contributed SLSA attestations support to nix
That sounds like a great idea! However one important consideration is that while an artifact on nixpkgs may aim to replicate the function of the upstream package, it must adhere to and interoperate with the rest of the distribution. Ultimately, its 'ecosystem' is nix. Work that goes into writing and maintaining the nix build does not generally filter back upstream to impact the build integrity of, say, its associated PyPI package. So if users continue to consume from PyPI, improving nix won't serve them.
This is not to say that the long-term source of truth for packaging will remain the language registries. Just that today's reality demands we meet users where they are.
> Would love to see Google contribute to nix in this space :)
Same :)
lrvick
Since writing the post you link, I finally threw my hands up and made a new distro with some security engineer peers that prioritizes supply chain security and mandates 100% full source bootstrapping and determinism: https://stagex.tools
It does not even try to be a workstation distro so we can get away with a small number of packages, focusing on building software with high accountability.
Thankfully OCI build tooling is mature enough now that we can build using standards and do not need a custom build framework and custom languages like nix/guix does anymore.
Weethet
This is an issue with nixpkgs not nix. Google could've just bootstrapped their own nixpkgs from scratch if they wanted to, see Guix (not a perfect example but still). Creating a whole new tool is still completely unnecessary
carlhjerpe
One could argue that creating Nix from scratch would be beneficial at some point. There's a lot of legacy hardcoded weirdness, Nix doesn't setup the containers with standard state of the art tools, the language is evaluated in a single thread and using values from derivations means a build blocks evaluation so it doesn't properly parallelise (nixpkgs bans "IFD" but it is useful for meta packaging).
Nixpkgs is more valuable than Nix at this point, but also quite vulnerable. In practice it has worked out reasonably well so far, I don't know of anyone who got "owned" because of Nix.
null
woile
Well, Google is using nix and nixpkgs...
lrvick
Encouraging the use of Nix in production is wildly irresponsible. I am really surprised to see Google do this given their generally high security bar. Maybe this team operates in a bubble and gets to prioritize developer experience above all else.
ChocolateGod
Nix/NixOS files often break due to Nix pkg maintainers not caring about keeping support for existing configuration formats. I experience a breakage roughly every 2 weeks when a variable/package gets renamed or changed.
0x457
At least it breaks during evaluation most of the time, and rolling back is super easy if it broke after activation.
Also, it seems like you're using unstable if you're having that many breakages, sooo kinda asking for it?
nicce
Corporation with the size of Google must be in control by themselves.
null
bgwalter
Thanks that the OSS value is $12 trillion, but only packagers, security experts and SaaS companies get any of that.
Rebuilt to Last? It is a Google project, so I give it two years.
chubot
At first I thought this might be promising, given
without burden on upstream maintainers
Then I see
This is not an officially supported Google product
on https://github.com/google/oss-rebuild
And then I also see
oss-rebuild uses a public Cloud KMS key to validate attestation signatures. Anonymous authentication is not supported so an ADC credential must be present.
$ gcloud init
$ gcloud auth application-default login
Mainly because Google has horrible customer support.
It would be more interesting if they came up with something hosted on third party infrastructure. Last I heard, Google Cloud is run by Oracle executives
---
e.g. in particular the Unisuper incident led me to believe that a lot of operational stuff is being outsourced, and is of poor quality
UniSuper members go a week with no account access after Google Cloud misconfig
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Google accidentally deleted a $125 billion pension fund's account
https://qz.com/google-cloud-pension-fund-unisuper-1851472990
I would not say this is unrelated, because operations in the underlying cloud can be a weak link in security
Although I'd certainly be interested in an argument otherwise
esafak
1. That is two years better than nothing.
2. It will likely be well architected.
3. It is open source, so others can fork it when Google abandons it. https://github.com/google/oss-rebuild
gostsamo
> 1. That is two years better than nothing.
This means two migrations in two years.
ezekg
There are some initiatives to help change that: https://osspledge.com
blitzar
Once there are as many private jets available for open source devs as there are for google employees then we are making progress.
ezekg
I think that's the wrong way to frame it. OSS is not meant to make you rich, and expecting that is going to bring more pain than joy. However, I do think businesses should use their success to fund their dependencies in a way that makes sense for them.
ChrisArchitect
Obligatory xkcd: Dependency https://xkcd.com/2347/
This fit in somewhere here?
msuozzo
Author here!
OSS Rebuild should give that Nebraskan the peace of mind to continue their everyday heroism without being pulled away to set up security configs or debug release CI. The rest of the blocks on top can contribute the support to assure themselves and the community that those critical builds are trustworthy.
IMO you need an immutable appliance-like OS that is deterministic and full source bootstrapped to do reproductions with minimized trusting-trust attack risk.
We built ReprOS to solve this problem: https://codeberg.org/stagex/repros
"Git push" to it and it will do a build in a throw-away VM then have the host sign the artifact results and push signatures to the same or a different repo.