oss-rebuild: rebuilding published packages and publishing attestations

Rebuilding what was published, rather than rebuilding what you build

OSS Rebuild is described as securing open-source package ecosystems by originating, validating and augmenting build attestations. The aim is to apply reproducible build concepts at low cost and at high scale for open-source package ecosystems.

The mechanism has two halves. Rebuilds are derived by analyzing the published metadata and artifacts, and are then evaluated against the upstream package versions. When that succeeds, build attestations are published for the upstream artifacts, verifying the integrity of the upstream artifact and eliminating many possible sources of compromise.

The direction of that is what makes the project different from a build system. This is not tooling that runs inside your CI to produce your package. It is tooling that takes something already published to a registry, works out what build system and what inputs would have produced it, runs that build, and compares. If the result matches the published artifact, you have evidence that the artifact is not a tampered version of what the sources claim to produce. If it does not match, that is a discrepancy worth investigating, and that is the detection mechanism the project describes as mitigating supply chain attacks.

The ecosystems currently supported are npm for JavaScript and TypeScript, PyPI for Python, and Crates.io for Rust. The scope caveat is stated in the same breath: while complete coverage is the aim, only the most popular packages within each ecosystem are currently rebuilt.

The project is Apache-2.0, written in Go, hosted at oss-rebuild.dev with documentation at docs.oss-rebuild.dev, and carries the disclaimer that it is not an officially supported Google product.

One CLI, four views of the same rebuild

The oss-rebuild CLI gives access to the data, and the design point is that the same rebuild can be rendered in several shapes depending on what you need.

Getting started is a go run or a go install:

$ go run github.com/google/oss-rebuild/cmd/oss-rebuild@latest --help
$ # Alternatively, install the binary locally.
$ # Just make sure it's on your PATH: https://go.dev/ref/mod#go-install
$ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest
$ oss-rebuild --help

The get command takes an ecosystem, a package and a version. By default it gives a summarized view:

$ oss-rebuild get pypi absl-py 2.0.0

For more granular access there are the --output formats. The payload option reaches the entire attestation payload:

$ oss-rebuild get pypi absl-py 2.0.0 --output=payload

The dockerfile option is the interesting one, because it produces a Dockerfile for the rebuild, and the documentation shows it chained straight into a container run:

$ oss-rebuild get pypi absl-py 2.0.0 --output=dockerfile | docker run $(docker buildx build -q -)

That pipeline is the whole idea in one line: pull the rebuild recipe out of the service, build it locally, and you can inspect or run what the rebuild produced without trusting the service's own hosting. The raw attestation bundle is available too:

$ oss-rebuild get pypi absl-py 2.0.0 --output=bundle

The list command answers a different question, which versions of a package have been rebuilt at all:

$ oss-rebuild list pypi absl-py

That distinction matters in practice. A package with no rebuild simply has no attestation, and the list command is how you find out which of your releases are covered.

Signature verification needs Google Cloud credentials, or --verify=false

The usage requirements section is where the operational cost of the project becomes concrete. oss-rebuild uses a public Cloud KMS key to validate attestation signatures, and anonymous authentication is not supported, so an ADC credential must be present.

The commands for that are:

$ gcloud init
$ gcloud auth application-default login

To disable signature verification and skip the requirement for KMS access, use --verify=false. So there are two modes, and the difference matters: with verification on, the CLI is checking signatures that bind an attestation to the key that produced it, and it needs a Google Cloud identity to do it; with verification off, the CLI hands you the data without that check.

For a tool whose entire value proposition is verification, defaulting the verification on is the right call, and requiring a credential rather than an API key is consistent with a design that assumes the reader has a Google Cloud project. It also means the CLI is not usable in a fully air-gapped or keyless context, which is a real constraint for a security tool in some environments.

The go.mod tells you how heavy the dependency set is. Alongside the standard Google Cloud clients for KMS, Cloud Storage, Firestore and BigQuery, and cloudtasks, there is in-toto-golang for the attestation format, go-securesystemslib for the signing side, keystore-go for key handling, cobra for the command line, go-git and go-billy for working with the source repositories, and a set of terminal libraries: tview, tcell and fatih/color, plus cheggaaa/pb for progress bars. The presence of a terminal UI framework is a small clue that this is meant to be run and read by a person, not only called from a script.

The repository layout mirrors the pipeline stages

The top-level entries describe the stages of the work rather than a simple library layout. There is build/ for the build execution machinery, definitions/ for the definitions of what a rebuild is for each ecosystem, an analyzer/ directory, pkg/ for the public packages, cmd/ for the command line entry points, internal/ for the internals, and deployments/, ci/, e2e/, tools/, site/ and docs/.

The definitions directory is the part worth understanding first, because it is where the per-ecosystem knowledge lives. A rebuild is only possible because the build system and its inputs are known for a given package, and that is per-ecosystem knowledge: how npm packages are built, how a Python wheel is assembled, what a crate's Cargo build looks like. Encoding that as definitions is what lets the rest of the system stay generic.

The go.mod also shows the AI angle explicitly, with google.golang.org/genai and the genproto/genai packages as direct dependencies. The project's own purpose list mentions deriving data for AI-driven rebuilds as the fourth point, under the heading of enabling future innovation, and the dependency set is consistent with that being more than a slogan in the roadmap.

The bonsai dependency, both the base module and bonsai-python, points at a related line of work in the same ecosystem of supply chain tooling, and the presence of cel.dev/expr as an indirect dependency suggests a rule or policy language is used somewhere in the evaluation path. The docs directory carries a trust document, docs/trust.md, which the security section points at for understanding the security properties of rebuilds, and that is the file to read before drawing conclusions about what an attestation does and does not prove.

The purpose section names the attacks it is aimed at

The stated purposes are worth quoting because they are specific about what the project believes it is for.

Mitigating supply chain attacks comes first: detect discrepancies in open-source packages, helping to prevent compromises like those of Solarwinds and Codecov. Those two cases are named, and they are a deliberate contrast. Solarwinds was a compromised distribution channel, Codecov was a compromised build pipeline, and the pair covers the two ways a package ecosystem gets attacked from the inside.

Scaling security standards is the second point, and the named technologies are SLSA, Sigstore and containerized builds. The point here is that a rebuild is a verification of a specific artifact against a specific upstream version, and the attestation is the output that other systems consume. This is why the format matters: an attestation that only a service understands is a report, while one expressed in in-toto and signed with a Sigstore-style key is something a policy engine can check.

Community participation is the third, and the project says it is creating a venue to collectivize effort towards securing the open-source supply chain. That is the funding and coverage argument: rebuilding every package in every ecosystem is expensive, and a shared catalogue of rebuild definitions is the thing that makes the scale claim plausible.

The related projects list points at the same effort from other angles: reproducible-central for Java and Kotlin reproducibility, and kpcyrd/rebuilderd, a rebuild scheduler with support for several distros. The difference in approach is instructive. OSS Rebuild is a Google Cloud project with Firestore, BigQuery and Cloud KMS in its dependency list, doing analysis at scale on the most popular packages. rebuilderd is a scheduler for distributing rebuild work across machines and distros. The first is a service producing a public dataset, the second is a tool for running rebuilds on your own infrastructure.

Where oss-rebuild is the wrong tool

The first limit is coverage, and the documentation does not hide it. Only the most popular packages within each ecosystem are currently rebuilt, and the three ecosystems are npm, PyPI and Crates.io. A package in Go, Java, Ruby, PHP or Rust crates that is not popular enough to have been covered simply has no attestation, and a missing attestation is a statement about the project's priorities rather than about the package.

The second limit is that it observes rather than participates. The model is to analyze what somebody else published and compare a rebuild against it. If you want your own release to carry a provenance statement, this project is the wrong shape for that, because the provenance you want has to be created inside your build, where you know the inputs, not reconstructed afterwards from a registry.

The third is the credential requirement. Signature validation needs an ADC credential and Cloud KMS access, and the escape hatch is --verify=false, which of course means you are reading a payload without checking the signature on it. For a tool whose subject is verification, a CI pipeline that turns verification off has not gained much.

The fourth is the rebuild fidelity problem, which is inherent to the approach rather than to this implementation. A rebuild succeeds only if the rebuild definition captures everything the original build did, including the network state, the toolchain version and any non-deterministic step. Where the upstream build is not reproducible, no amount of analysis recovers the original artifact, and the project then has no attestation to publish for that version.

The fifth is that this is a research and data project, not a production service you can sign a contract on. The disclaimer says it is not an officially supported Google product, the repository has no GitHub releases, and the last push was on 2026-10-19. The artefacts it produces are meant to be used as evidence, and the evidence is only as good as the trust model in docs/trust.md.

Editorial conclusion

oss-rebuild is worth watching and worth using for its data if you publish packages, because it turns the abstract question of whether an upstream artifact is reproducible into a concrete attestation you can check with one command, and because the CLI gives you the payload, the raw bundle and even a Dockerfile for the rebuild. It is not a drop-in CI step for your own releases, since the model is to observe what was published rather than to rebuild in your pipeline. Before you rely on it, check the three things the documentation states plainly: which ecosystems and which packages are actually covered, since complete coverage is the aim and only the most popular packages within each ecosystem are currently rebuilt; that you have Google Cloud credentials and KMS access, since signature validation uses a public Cloud KMS key and anonymous authentication is not supported, with --verify=false as the escape hatch; and how the trust model in docs/trust.md treats a rebuild that succeeded against a specific upstream version, since the security properties of the whole scheme rest on that document.

Frequently asked questions

Official sources

1. google/oss-rebuild on GitHub
2. Issues
3. License: Apache-2.0
4. README