Source URL: https://simonwillison.net/2025/Jul/23/oss-rebuild/
Source: Simon Willison’s Weblog
Title: Introducing OSS Rebuild: Open Source, Rebuilt to Last
Feedly Summary: Introducing OSS Rebuild: Open Source, Rebuilt to Last
Major news on the Reproducible Builds front: the Google Security team have announced OSS Rebuild, their project to provide build attestations for open source packages released through the NPM, PyPI and Crates ecosystom (and more to come).
They currently run builds against the “most popular" packages from those ecosystems:
Through automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression). Once we reproduce the package, we publish the build definition and outcome via SLSA Provenance. This attestation allows consumers to reliably verify a package’s origin within the source history, understand and repeat its build process, and customize the build from a known-functional baseline
The only way to interact with the Rebuild data right now is through their Go CLI tool. I reverse-engineered it using Gemini 2.5 Pro and derived this command to get a list of all of their built packages:
gsutil ls -r ‘gs://google-rebuild-attestations/**’
There are 9,513 total lines, here’s a Gist. I used Claude Code to count them across the different ecosystems (discounting duplicates for different versions of the same package):
pypi: 5,028 packages
cratesio: 2,437 packages
npm: 2,048 packages
Then I got a bit ambitious… since the files themselves are hosted in a Google Cloud Bucket, could I run my own web app somewhere on storage.googleapis.com that could use fetch() to retrieve that data, working around the lack of open CORS headers?
I got Claude Code to try that for me (I didn’t want to have to figure out how to create a bucket and configure it for web access just for this one experiment) and it built and then deployed https://storage.googleapis.com/rebuild-ui/index.html, which did indeed work!
It lets you search against that list of packages from the Gist and then select one to view the pretty-printed newline-delimited JSON that was stored for that package.
The output isn’t as interesting as I was expecting, but it was fun demonstrating that it’s possible to build and deploy web apps to Google Cloud that can then make fetch() requests to other public buckets.
Hopefully the OSS Rebuild team will add a web UI to their project at some point in the future.
Via Hacker News
Tags: google, packaging, pypi, security, npm, ai, generative-ai, llms, ai-assisted-programming, supply-chain, vibe-coding, claude-code
AI Summary and Description: Yes
**Summary:** The text discusses the Google Security team’s initiative, OSS Rebuild, aimed at improving the reproducibility and security of open-source packages through build attestations. This project enhances confidence in software supply chains by ensuring that packages can be verified for their integrity and origin.
**Detailed Description:**
The OSS Rebuild project by Google addresses critical security and reproducibility challenges within open-source software ecosystems. Here are the key points of the initiative:
– **Objective:** Enhance the security of open-source packages by providing verifiable build attestations. This is particularly relevant in the context of recent supply chain attacks on package managers like NPM and PyPI.
– **Target Ecosystems:** The project currently focuses on automating builds for popular packages from multiple ecosystems:
– NPM (Node Package Manager)
– PyPI (Python Package Index)
– Crates.io (Rust community package registry)
– **Process Overview:**
– Builds are automated using heuristics to create a reproducible build definition for target packages.
– The build output is compared semantically against the upstream artifact, normalizing results to mitigate discrepancies from factors like archive compression.
– Successful builds and their definitions are published via SLSA (Supply chain Levels for Software Artifacts) Provenance, providing consumers with the ability to:
– Verify the origin of packages
– Understand their build processes
– Customize builds from known-functioning baselines
– **Accessing Rebuild Data:** Currently, the only interaction method is through a Go CLI tool, allowing users to list built packages stored in Google Cloud Buckets.
– **Experimentation and Future Work:** The author attempted to create a web app that could interact with the rebuild data, demonstrating flexibility in utilizing Google Cloud infrastructure. This serves as a proof of concept for future development, suggesting that a user-friendly web interface for OSS Rebuild would be beneficial.
– **Broader Impact:** This initiative is significant for software security as it contributes to mitigating risks associated with software supply chains and enhances transparency in package management. It also opens up new conversations about how organizations secure their software dependencies, particularly in alignment with Zero Trust and DevSecOps principles.
This initiative is especially valuable for security and compliance professionals who need to ensure the integrity and reliability of third-party software components used in applications. By implementing robust verification mechanisms, organizations can reduce the risks associated with dependency vulnerabilities and improve their overall security posture.