[HN Gopher] OSS Rebuild: open-source, rebuilt to last
___________________________________________________________________
OSS Rebuild: open-source, rebuilt to last
Author : tasn
Score : 121 points
Date : 2025-07-22 13:53 UTC (9 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| bgwalter wrote:
| 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.
| esafak wrote:
| 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 wrote:
| > 1. That is two years better than nothing.
|
| This means two migrations in two years.
| ezekg wrote:
| There are some initiatives to help change that:
| https://osspledge.com
| blitzar wrote:
| Once there are as many private jets available for open source
| devs as there are for google employees then we are making
| progress.
| ezekg wrote:
| 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.
| pessimizer wrote:
| > businesses should use their success to fund their
| dependencies in a way that makes sense for them.
|
| They already do, and always have. It doesn't make any
| sense to most of them to fund their OSS dependencies at
| all, because they're available for free. They should do
| _more_ than what makes sense for them, and they should
| have to pay professional consequences if they don 't.
|
| Programmers should have enough unity to bring pressure
| against companies that make a lot of money from software
| they don't pay for. Or rather, should have had, because
| LLMs have changed anything.
| chubot wrote:
| 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
|
| I would not use this with a dependency on Google Cloud, or the
| gcloud command line tool.
|
| 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
| Weethet wrote:
| 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
| hollerith wrote:
| 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."
|
| https://news.ycombinator.com/item?id=36268776
| Weethet wrote:
| 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 wrote:
| 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.
| woile wrote:
| Well, Google is using nix and nixpkgs...
|
| https://firebase.google.com/docs/studio#how-does-it-work
| lrvick wrote:
| 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 wrote:
| 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 wrote:
| 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?
| lrvick wrote:
| 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.
| arianvanp wrote:
| 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.:
|
| https://talks.nixcon.org/nixcon-2024/talk/AS373H/
|
| https://GitHub.com/arianvp/nix-attest
| msuozzo wrote:
| 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 :)
| ramses0 wrote:
| Are all your comments being run through an "AI
| appropriateness and enthusiasm" filter?
| hollerith wrote:
| I think he's just young and not-yet-disillusioned.
| msuozzo wrote:
| 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.
| Y_Y wrote:
| Why not help them help bring their packages to users, rather
| than borrowing and circumventing the existing effort?
| kam wrote:
| 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.
| nicce wrote:
| Corporation with the size of Google must be in control by
| themselves.
| ChrisArchitect wrote:
| Obligatory xkcd: Dependency https://xkcd.com/2347/
|
| This fit in somewhere here?
| msuozzo wrote:
| 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.
| Flux159 wrote:
| 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.)?
| candiddevmike wrote:
| 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.
| jpalomaki wrote:
| 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.
| Y_Y wrote:
| 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.
| msuozzo wrote:
| 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.
| lrvick wrote:
| 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.
| 0cf8612b2e1e wrote:
| This is a great idea. Less boil the ocean than getting
| everything into Nix. Are any notable projects using this?
| lrvick wrote:
| 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
| tomcam wrote:
| 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 wrote:
| 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.
|
| https://stagex.tools
| conradev wrote:
| Or Debian or NixOS? Both of which are pretty reproducible:
| https://reproducible-builds.org/success-stories/
|
| You just need a read-only _system_ partition, like macOS or
| NixOS or Silverblue.
| simonw wrote:
| 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/**'
|
| I ran that and got back 9,507 - here's that list as a Gist:
| https://gist.github.com/simonw/9287de5900d5b76969e331d9b4ad9...
| msuozzo wrote:
| 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 wrote:
| 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 wrote:
| 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
| WhatIsDukkha wrote:
| 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 wrote:
| It does provide client side build, see the bottom shell
| snippets.
___________________________________________________________________
(page generated 2025-07-22 23:00 UTC)